http://opalkelly.com/

Author Topic: Looking for set of MCU devkits representative of industry and hobbyists  (Read 1515 times)

0 Members and 3 Guests are viewing this topic.

Offline teijo

  • Contributor
  • Posts: 5
  • Country: fi
Hello EEVblog forum, my first post here! :)

Having had background in software only, I've been lucky to have a chance to work closer to hardware for the past year and a half. It has also sparked my interest in electronics again which I haven't really visited since elementary school (loved to tinker some electronics by the book, literally).

I have so far seen only a slice of the embedded ecosystem and I'd be now very interested to get a better general understanding of the full diversity of MCUs. There are many vendors with multiple MCU families and architectures, so I'd be interested to hear what you see as the most popular and trusted models from different vendors that are in active use today (when starting to develop something new).

I feel I have a reasonable understanding of the TI MSP430 series and their tool chain, having worked with 4 MCU variants from them, but that's about it. I've also touched Atmel and their tool chain with the SAM series, and Xilinx ZYNQ SoC, but I'm not really interested in anything running over ten(s) of MHz at this time.

From my experience so far, I feel that TI and Atmel provide some basic code samples, but not something to seriously build on top of (except for the device headers). The goal of this project is for me to better understand the differences between vendors, their tool chains, and their approach on supporting the software development for their chips. As the side effect of learning, I'm hoping to have some good open source abstractions and drivers for the most common use cases that could then be used as a baseline for developing business logic on top of. If that ever gets realized on some level, having focused on the most common MCU devkits would probably benefit the largest number of people.

If you happen to know similar projects / frameworks, open source or commercial, I'd be interested to hear of them too.

Specs:

  • Models that have cheapish (under $50) devkits à la TI's LaunchPad series (preferably integrated programming) so that getting a set of, say, 6 kits, doesn't empty my pockets too much to start with
  • Variety of brands
  • MCU should have proper development support from the vendor, e.g. I worked a while with TI MSP430 FR5739 which you basically had to use mspdebug to program since TIs own tools didn't properly support the old LaunchPad. Switch to FR5969 was a blessing, especially from workflow POV
  • Variety of architectures and capabilities
  • Weight on how common the MCU is

What do you think? Especially do you see inherent problems in trying to provide common abstraction in embedded environment, regardless of how lightweight it might be?
 

Offline colorado.rob

  • Regular Contributor
  • *
  • Posts: 104
  • Country: us
 :popcorn:
 
The following users thanked this post: Jeroen3

Offline NorthGuy

  • Frequent Contributor
  • **
  • Posts: 270
  • Country: ca
Especially do you see inherent problems in trying to provide common abstraction in embedded environment, regardless of how lightweight it might be?

I certainly don't know of all MCUs. I know more about Microchip PICs than the others. There are over 1500 different PICs, all with their own idiosyncrasies, and providing common abstractions would be really hard.

Abstractions are very good for software. You write a program for Windows and you cannot rely on particular hardware because you want it to run on any hardware where Windows can run. So, the OS abstracts the hardware and you then work with OS, not with hardware.

The situation is quite different in embedded development (at least in small-ish embedded). The very reason the MCU and its software exists is because it is attached to particular hardware you're designing. Abstracting the hardware engineer from his hardware might not be such a good idea.

 

Offline evb149

  • Super Contributor
  • ***
  • Posts: 1459
  • Country: us
Hello,

It would be hard not to recommend STM32 based kits like their "NUCLEO" or "DISCOVERY" kits.  They are inexpensive and representative of a very widely used line of 32 bit MCUs from ST.  So for "Mainstream" MCU coverage I think you sort of have to pay some attention to ST.  Also they have a nice ST specific version of Keil you can get from ST/Keil for the L0 and F0 series.  So I would get the best / biggest L0 and F0 STM32 Nucleo or Discovery boards you can.

For TI you know MSP430 and that also probably covers Code Composer unless you used something else unusually.
I really wouldn't call any other TI MCUs "dominant" in the industry now as far as I know though they're well represented AFAIK for certain "niche" sectors like the C2000 MCUs for digital power / motor control types of uses.  I guess you could just be content with what you know about TI's ecosystem unless you want to really reach into more corners like TIVA, MSP432, C2000, DSP, ARM-A series, ARM-R series (pretty specialized), or open the "very unique" world of their wireless SOCs.
For their wireless I'd go for the CC2640R2F kit they recommend whatever that is I forget the name.  I guess it may be a launchpad also?  That'll handle the latest and greatest they have for Bluetooth Low Energy v4 / v5 (still evolving a bit here).
And then they have 802.11 WiFi kits / devices / modules like WiLink  (802.11 and BLE) or CC3220 etc.  Not really that widespread / dominant in industry but a new launchpad / whatever is always nice.  Very "unique" development tools though between CCS and their debuggers and sometimes TI-RTOS etc.

For NXP (now owning Freescale) they're still kind of new with their tools since they bought Freescale and pretty much ended using Freescale Code Warrior for entry level development.  That was then switched to "Kinetis Design Studio" for a while.  Then it became MCUXPRESSO which is their current "almost all current NXP MCU IDE" offering.  I like the Kinetis MCUs and MCUEXPRESSO is sort of OK except being new and evolving and not covering all the legacy / whatever devices now / yet... So I guess I'd say pick up the current Kinetis KL2x / 3x/ 4x / 5x /6x / whatever is the flavor of the week dev kit with a built in or add-on module to include your basic accelerometer / gyroscope / whatever sensor devices and try MCUEXPRESSO.  You can look at a LPCxxx kit / device too if you want to see that variety of NXP original vs Freescale Original.

For a / another Bluetooth oriented MCU I recommend the Nordic NRF52840 development kit.  Pretty low cost.  You can use their SDK with either GCC or Keill or even IAR (limited free or expensive paid) or other IDEs.  I guess I'd suggest going GCC / Eclipse for free and without limitations.

For Renesas which is quite a different tool / device ecosystem than most others you may be interested in their "Synergy" platform and relevant newer devices.  I haven't tried them yet but after learning about it it is on my to do list to look for a kit and try the tools.  I would not say it is widely market dominant but it is widely used in certain industries / regions / applications I guess is the way to put it.  You could choose to ignore it or you could broaden your horizon and pick it up as somewhat of a "specialty" skill / ecosystem.
https://www.renesas.com/en-us/products/synergy/features.html

For ARM-A SOC development you probably already know it from working with ZynQ etc.  But if you want some "cheap" and "good" devkits, how could you not want to pick up some of the $10 or $35 Raspberry Pi versions?  Silly easy to use if you just load up Raspbian and SSH in or plug in a HDMI monitor and keyboard and mouse.  "aptitude install" anything from QT5 to Python3 to G++ and you're off and running.   No huge "benefit" vs. doing the same development on X86 / Mac / whatever desktop under LINUX or whatever but you can use it as an good example target platform of doing multi-platform cross development with linaro or even get into using it as a test bed for drivers and kernel experiments and embedded system development stuff because it is cheap and works for that.

For a change of pace from ZynQ / Xilinx, my favorite latest Altera devkits are DE10-NANO from Terasic which is a Cyclone-V SOC (ARM-A application processor + FPGA) and also the MAX10 FPGA based DECA kit from ARROW the electronics distributor.  DECA is a pure FPGA, no ARM hard SOC in there, but it uses the NIOS II soft-core CPU and so you can experiment with the whole Altera Quartus Lite / SOC-EDS free development ecosystem with the DECA (and the DE10-NANO).   You an also as usual work with FPGA HW development on either of course though I think the interfacing is easier (headers and such) with the DECA.

You might be interested in trying RISC-V as a platform.  On the software side not a lot to learn as a programmer since it runs the standard compiler tool chains just with a new target architecture.  But if you are interested in say learning the assembly or anything about the platform or delving into soft-core SOC customization it is a good thing to look at besides what you can do with Altera/SOC/NIOS-II and Xilinx/SOC/Microblaze.  SIFIVE and maybe others (??) has some RISCV "hard CPU" devkits.  Seems like I heard something about an Arduino Cinque or something and others.  And you can run the FPGA soft CPU on some Xilinx / Altera devkits which are supported or others if you want to "port" it.

ESP32 from Espressif is interesting in that it is a Bluetooth Low Energy v4 and 802.11 WiFi SOC with a Tensilica CPU core, a fast one.  Really cheap devkits.  Unique IDE.  Not at all "market dominant" (it is pretty new) but very different / interesting.

Microchip / PIC?  I'll let others suggest options.  PIC32 kits of some kind might be contemporary / interesting.  PIC18 or PIC24 for more "legacy" low end MCU stuff I guess.

Cypress PSOC5LP is pretty nifty at the hardware architecture level and has an absolutely unique toolchain (PSOC CREATOR). You an do lots of interesting "rapid application development" with their configurable / programmable analog & digital hardware peripherals and auto-generated SW peripheral APIs and stuff.   CY8CKIT-059 the PSOC5LP devkit that is low end for price is about the best $10 I've spent on a devkit in a while considering the very interesting / powerful MCU and IDE toolchain.  Nice if you like to play with external analog / digital signal interfacing and stuff but not "high end" like at the FPGA or "precision analog" level.  Just a better general purpose analog / digital peripheral set MCU than anything you'll commonly see in say MSP430 / STM32F0-2 etc.  Not really "market dominating" but well represented in some industries / areas.

SiLabs?  Eh.  Maybe.  Nice MCU hardware capabilities and offerings with some unique features.  Devkits tend to be more expensive, and I'm not a fan of aspects of the IDE.  They have some nice "ultra low power" stuff but then so does TI, Nordic, ST, Microchip, ..... so not a high priority I think but an option.

In the "very unusual but also market relevant in niche areas" are the Analog Devices processors like Blackfin and some of their DSPs and Analog oriented MCUs (like ADUCM3...).  Unusual tool chain.  Often expensive tools / kits, sometimes not.  But very unique.  Some interesting performance / architecture and analog capabilities depending on device.

For learning general ARM-Cortex-M based development cross platform I suggest looking at:
* GNU ARM ECLIPSE combination.  Not very different in core tech than Code Composer or MCUEXPRESSO or others that are also GCC / ECLIPSE based.  But none of the "OEM specific" IDE enhancements are present of course.  So you are more encouraged to get "low level" with how you customize and utilize eclipse, the compiler toolchain, etc.  Recommended for that reason and just vast portabilty and applicability from 32bit MCUs to doing PC / Android / whatever development.

* Atollic (TrueStudio) and SEGGER (Embedded Studio) also have some free IDEs that may be woth looking at.  Useful for many ARM Cortex-M targets.

* Keil of course because very portable across almost any Cortex-M MCU and with a unique IDE and middleware.  As I said at least using it for STM32F0/L0 development is recommended.  No reason not to use it for other low end ARM C-M MCUs except for ultimately the code size and other limitations in their free version.



Hello EEVblog forum, my first post here! :)

Having had background in software only, I've been lucky to have a chance to work closer to hardware for the past year and a half. It has also sparked my interest in electronics again which I haven't really visited since elementary school (loved to tinker some electronics by the book, literally).

I have so far seen only a slice of the embedded ecosystem and I'd be now very interested to get a better general understanding of the full diversity of MCUs. There are many vendors with multiple MCU families and architectures, so I'd be interested to hear what you see as the most popular and trusted models from different vendors that are in active use today (when starting to develop something new).

I feel I have a reasonable understanding of the TI MSP430 series and their tool chain, having worked with 4 MCU variants from them, but that's about it. I've also touched Atmel and their tool chain with the SAM series, and Xilinx ZYNQ SoC, but I'm not really interested in anything running over ten(s) of MHz at this time.

From my experience so far, I feel that TI and Atmel provide some basic code samples, but not something to seriously build on top of (except for the device headers). The goal of this project is for me to better understand the differences between vendors, their tool chains, and their approach on supporting the software development for their chips. As the side effect of learning, I'm hoping to have some good open source abstractions and drivers for the most common use cases that could then be used as a baseline for developing business logic on top of. If that ever gets realized on some level, having focused on the most common MCU devkits would probably benefit the largest number of people.

If you happen to know similar projects / frameworks, open source or commercial, I'd be interested to hear of them too.

Specs:

  • Models that have cheapish (under $50) devkits à la TI's LaunchPad series (preferably integrated programming) so that getting a set of, say, 6 kits, doesn't empty my pockets too much to start with
  • Variety of brands
  • MCU should have proper development support from the vendor, e.g. I worked a while with TI MSP430 FR5739 which you basically had to use mspdebug to program since TIs own tools didn't properly support the old LaunchPad. Switch to FR5969 was a blessing, especially from workflow POV
  • Variety of architectures and capabilities
  • Weight on how common the MCU is

What do you think? Especially do you see inherent problems in trying to provide common abstraction in embedded environment, regardless of how lightweight it might be?
 
The following users thanked this post: hans, The_Paya, teijo

Offline evb149

  • Super Contributor
  • ***
  • Posts: 1459
  • Country: us
Abstractiions and HALs are interesting areas.
On the one hand you are interested in "low end" MCUs relatively speaking (compared to Cortex-A or even M4F / M7 which all are sometimes / often 50-100MHz+ devices then again many CM3s are also these days...) .

But anyway at the "low end" of the C-M market you have C-M0s or whatever with just XX kilobytes of RAM or FLASH and maybe N MHz to low NN MHz speeds.  So pretty limited.  Too limited to generally want to to run a "VM" like CLR .NET micro / Java micro / Python / eLUA etc.  Yeah maybe you COULD run some of that on some of the low-mid-range MCUs but a lot of overhead.

At the mid range and upper end of the space you have 80Mhz - N * 100 MHz CPUs with 100s of KBytes or MBytes of FLASH, 100s kBy RAM.  Sometimes even DRAM capable witth XXX MBy DRAM possible.  They are even talking about LINUX support for some of the PIC32s so I hear.

So huge range. For the most powerful CM4, CM7 devices it would not be so silly to run abstractions like eLUA or one of the embedded ADA variants or .NET micro or whatever is out there for JAVA embedded these days I guess or whatever. 
Certainly without a doubt on anything better than the couple lowest end Cortex-M0 variants you can already run FreeRTOS and similar light weight RTOSs.

TI has a lot of middleware in their TI-RTOS related ecosystem that does a lot of platform abstraction depending on what you use.

There's still eCOS and RTEMS and various other offerings.

And there are newer things like:
http://www.contiki-os.org/
https://genode.org/index
https://github.com/RIOT-OS/RIOT/wiki
https://mongoose-os.com/
etc. etc.

So I guess once you have a FEW platform abstractions you can get a very basic RTOS running.   After that there is just middle ware layers and device drivers with whatever APIs that can expose whatever functionality you want abstracted.  It is very viable in theory and in practice.  I guess a lot of developers are not familiar / comfortable with such middleware and approaches so they don't see it as "better / easier" and there's the undeniable "overhead / bloat" though in reality it can reduce complexity / risk and promote reuse and abstraction and best coding practices to do so.

There's also a lot of untapped potential to use model driven design and CASE to create embedded systems implementations from business logic level models and there are some interesting code generation tools and such out there that could be coupled with a nice portable RTOS / HAL / device driver abstraction API set to make it platform neutral.

I guess you have to consider the actual RAM / FLASH / MFLOPS processing power of a midrange CM4F or CM7 or such device.  If you look at it quantitatively it is probably more powerful in those metrics than some minicomputers (PDP-11 / VAX level), Mainframes maybe (IBM360?), and early decent microcomputer desktops (maybe early Apple Macs?  Amiga?).

The LEON SPARC FPGA soft-CPU core runs in something like the 2nd smallest $49 level FPGA devkit I have here and I could probably run a couple / few in a DECA.  And that's a SPARC processor probably not unlike the power of some of the older Sun Solaris / SPARCstation machines.  Certainly add on a 32 GBy SD card and give it 256MBy DRAM and it certainly would be in the league.

So no reason we can't have total platform abstraction for embedded systems soon.  RISC-V is a brand new ISA and already it supports GCC / LLVM and LINUX. 

I think mostly people have to show an interest in developing RAD / CASE tools that take abstracted APIs and then can cross-target those to whatever toolchain you have for your ISA and then some "lightweight" RTOS / driver level stuff that is a little platform specific but mostly everything is platform independent, like LINUX, really.

uCLINUX is another such portable OS come to think of it.



 
The following users thanked this post: teijo

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2305
I would suggest Hitachi SH1-3, but ... since those chips are very rare, it's more an hack proposal like ... finding a 1998-GPS with an Hitachi chip aboard, hack it, and take the control.

It costs 5-10 euro from surplus sellers (usually on ebay) and it offers a lot weeks of fun. Well, gcc is .... not exactly well supported, therefore it also offers several weeks of fighting against the GNU toolchain.

Not so bad, aint'it?  :D
 

Offline teijo

  • Contributor
  • Posts: 5
  • Country: fi
Thanks for the great responses so far, I'll dig deeper into them a bit later.

Regarding the level of abstraction, I'm mostly interested to understand the HW interfacing differences among different MCUs and see how well more declarative and functional programming approaches would fit into bare metal and driver development.

Will definitely check out the available operating system level abstractions to see where they draw the line and what kind of device driver interfaces they use. Out of lightweight operating systems I've only had experience with FreeRTOS, and building anything on top of that I'd consider too high level in the scope of this project.
 


Online wraper

  • Supporter
  • ****
  • Posts: 5590
  • Country: lv
You could get some silicon labs dev board (very fast 8051 core). For example https://www.element14.com/community/docs/DOC-75767/l/efm8ub1-universal-bee-8-bit-mcu-starter-kit-for-usb. Includes Jlink debugger, can debug/program external devices as well. Those are not popular with hobbyists but are really popular in industry. These MCUs have very interesting peripherals and are very cheap. They also have ARM dev boards at similar price but I believe their ARM MCUs aren't as popular in industry as 8051. Silabs also offers completely free IDE, and free licence for Keil compiler. Code examples are given as well.
List of 8 bit dev boards:
http://www.silabs.com/products/development-tools/mcu/8-bit#starter
« Last Edit: July 13, 2017, 11:54:32 PM by wraper »
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2305
(
p.s.
Oh, I have two 8051 boards and an old (but brand new) PIC-KIT2 for sale.
)
 

Offline flochlandla

  • Contributor
  • Posts: 6
  • Country: at
Regarding MSP430:
Take a look to Olimex (www.olimex.com). It's a bulgarian company which has a big offer for starter kits, header boards, etc.
Unfortunately they stopped providing new DLLs for their MSP-debugger, i.e. it does not work with the latest IAR workbench  :(

I think one of the most powerful starter kits they provide is this one:
https://www.olimex.com/Products/MSP430/Starter/MSP430-5438-STK/
 

Offline teijo

  • Contributor
  • Posts: 5
  • Country: fi
I'm surprised of no mention of AVR yet. It's one of the few chips I had heard of even before getting to learn more about MCUs. Coincidence or what's that about?
 

Offline teijo

  • Contributor
  • Posts: 5
  • Country: fi
Take a look to Olimex (www.olimex.com). It's a bulgarian company which has a big offer for starter kits, header boards, etc.
Unfortunately they stopped providing new DLLs for their MSP-debugger, i.e. it does not work with the latest IAR workbench  :(

Thanks for the Olimex pointer, looks like they offer plenty of stuff to tinker with :)

Degrading/ed support sucks. I'm trying to avoid any chips/kits that have any complications with the development workflow. I don't want to waste my time on another MSP430FR5739.
 

Offline NorthGuy

  • Frequent Contributor
  • **
  • Posts: 270
  • Country: ca
Degrading/ed support sucks. I'm trying to avoid any chips/kits that have any complications with the development workflow.

No matter what you use, you may hit problems with "development workflow". One guy hits problems with ABC and swears XYZ is better. Another one hits problems with XYZ and swears ABC is better. In reality, all of them are more or less the same.
 

Online blueskull

  • Supporter
  • ****
  • Posts: 6753
  • Country: cn
  • Final year EE PhD
Where's the wall of pre-formatted text >:D?
SIGSEGV is inevitable if you try to talk more than you know.
 
The following users thanked this post: JPortici

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 5138
  • Country: gb
    • Having fun doing more, with less
Even if you never use these devices, understanding their philosophy will improve the way you "think about" and architect realtime systems. The philosophy has a good theoretical pedigree, was first defined and implemented in the 70s, and continues to be incorporated into new languages and hardware.

The XMOS xCORE devices are interesting because they have a set of unique characteristics:
  • cycle-accurate deterministic timing, which is critical for hard realtime systems whatever their speed
  • FPGA-like I/O structures easily and simply controlled by software, e.g. SERDES up to 250Mb/s, externally/internally clocked, strobed/master-slave
  • timed i/o, e.g. this input occurred at time t, or do that output at time t, where t is defined in clock cycles, where a cycle can be 4ns
  • encroaching into FPGA territory in ways that are impossible for conventional device such as ARMs etc
  • multicore - up to 32 32-bit 100MIPS cores on a chip, extendable across chips
  • parallelism isn't a bolt-on afterthought; it has solid hardware support and the programming language (xC) is a good example of Tony Hoare's 40 year old CSP concepts (many other modern languages are borrowing concepts from CSP, e.g Go and arguably Rust)
  • no need for an RTOS!
  • free Eclipse based development environment

A simple example of their power: they can implement a 100Mb/s MII ethernet interfaces, and USB interfaces in software; try that with any other processor! (Some of their chips also have onboard hardware USB and Ethernet interfaces)

£12 devkit: https://www.digikey.co.uk/en/product-highlight/x/xmos/startkit (or Farnell)
30000 ft concepts: http://www.xmos.com/published/xcore-architecture-flyer?version=latest
Very readable programming tutorial : https://www.xmos.com/support/tools/programming?component=17653
There are lies, damned lies, statistics - and ADC/DAC specs.
Gliding aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 
The following users thanked this post: NivagSwerdna

Online blueskull

  • Supporter
  • ****
  • Posts: 6753
  • Country: cn
  • Final year EE PhD
And BTW, check out ADI's ADSP-BF70x family. At a reasonable price (still, per MIPS it's more expensive than Chinese ARM A7/A9 chips, but ADSP can run without OS happily and can boot up in milliseconds), you get 400 32*32 MMACS or 800 16*16 MMACS, plus quite some on chip L2 RAM (up to 1MB) and separate I/D L1 cache. BF592 offers much cheaper price with much less L2 and much worse 32*32 MMACs performance, but if you do 16*16 operations only on small data sets, it is equally fast compared with BF70x at half the price.

The ADI chips (generally across Blackfin product line) are cheap compared with its competitors (TI), but on the other hand, example code and tutorials are next to impossible to find, so effectively you are one your own. Their community isn't that active either.
SIGSEGV is inevitable if you try to talk more than you know.
 

Offline teijo

  • Contributor
  • Posts: 5
  • Country: fi
£12 devkit: https://www.digikey.co.uk/en/product-highlight/x/xmos/startkit (or Farnell)
30000 ft concepts: http://www.xmos.com/published/xcore-architecture-flyer?version=latest
Very readable programming tutorial : https://www.xmos.com/support/tools/programming?component=17653

The xCORE MCUs looked very interesting. With that pricing I'll definitely put one kit into my shopping basket, even if it might not be in mainstream use :)
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2305
cycle-accurate deterministic timing, which is critical for hard realtime systems whatever their speed

I have been designing a softcore with this characteristic for four years. I have recently committed a revision five, not so good, but not so bad, I mean ... in the "multi cycles" version (not pipelined) every core cycle, except some arithmetic operations (e.g. MUL/DIV/MAC) cycles and load/store cycles whose characteristics depends on wait states, is composed exactly by ten clock cycles and every exception takes only 20 clock cycles to switch into a completely isolated context, so, no need to spend more time saving registers, you are all done!

The core is thin enough to fit into a spartan3e-200 fpga with 45% resource utilization (well, it consume a lot of Block RAM as well as Distributed RAM), therefore on spartan3e-500 you can have up to four cores with the same characteristics (already tried, it does fit, and it works) :D

The pipelined version is a branch of research which is good only because it improves the CPI, but it's not efficient as a five-stages-MIPS (e.g. R2K), and it is bad because it introduces the need of having a branch prediction, pipeline stalls (bubbling? nopping? oh well ...).

At the end, it makes the design more complex, especially for the built in debugger, and it uses more resources on the fpga, and the whole design has been made with the intention of being more friendly than a classic RISC to be programmed in assembly.

In short, I will confirm the cycle-accurate feature, and for the next step ... I'd like to "grab & copy" some good concepts from XMOS.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 2305
encroaching into FPGA territory in ways that are impossible for conventional device such as ARMs etc[/li][/list]

what do you mean with that?

p.s.
in my case, cores have a simple "interrupt driven hardware mailbox unit" which makes them to communicate.  On spartan3e-500 I have enough resources to implement it.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 5138
  • Country: gb
    • Having fun doing more, with less
    encroaching into FPGA territory in ways that are impossible for conventional device such as ARMs etc[/li][/list]

    what do you mean with that?

    It is the combination of the features I mentioned; see XMOS' literature for more details.

    (BTW, I forgot to mention the "wait for port to eq/neq a value" in combination with the other port capabilities, and multiple programmable clocks).

    Quote
    p.s.
    in my case, cores have a simple "interrupt driven hardware mailbox unit" which makes them to communicate.  On spartan3e-500 I have enough resources to implement it.

    Interrupts instantly destroy the possibility of knowing how long a piece of code will take to execute, thus losing the cycle-accurate attribute. The same is true for any form of cache or statistical prediction logic.

    Let's consider a couple of use-cases to illustrate possibilities:
    • using only the general purpose built-in i/o facilities and software, make a frequency counter by counting the transitions on two input pins (fIn and fReference). Do that while reporting results up a USB link to a PC and interacting with front panel controls
    • LCDs require zero DC bias across their segments, which implies guaranteed i/o waveform timings; that's why most people use a display module with inbuilt controller. With the XMOS devices that can be done in software with a small part of one chip
    There are lies, damned lies, statistics - and ADC/DAC specs.
    Gliding aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
    Having fun doing more, with less
     

    Offline legacy

    • Super Contributor
    • ***
    • Posts: 2305
    Interrupts instantly destroy the possibility of knowing how long a piece of code will take to execute, thus losing the cycle-accurate attribute. The same is true for any form of cache or statistical prediction logic.

    Well, on { D, I }, { I } is the worst since its cache miss makes you unable to estimate how long a piece of code will take to execute, the best you can do is considering the worst of the possible foreseeable circumstances when you have to reload the cache and access the (slow) memory to do so.

    In my case there is no cache, and all the fetches happen within the same time.

    Btw, how can you make cores able to communicate each others if you don't use an interrupt driven mail box?

    Another possible solution is that each cpucore keeps looping on a shared memory waiting for data. It implies TAS instructions to implement software semaphore, as well as read-modify-write cycles to save the coherence. In my case, since I have fours cores connected through a bar-matrix, I can implement a quadri-port-memory, but it's not a good idea on fpga since BRAM is usually dual port, thus I abandoned it since it implies a lot of resource wasted.

    A hardware mail box looks easier and more efficient. Indeed, in avionics, we have a lot of hardware mail boxes in our fly-boards.

    I still have to see what has been implemented in XMOS chips to allow their cores to communicate.
    « Last Edit: July 18, 2017, 12:40:55 AM by legacy »
     

    Offline Sal Ammoniac

    • Frequent Contributor
    • **
    • Posts: 613
    • Country: us
    • cycle-accurate deterministic timing, which is critical for hard realtime systems whatever their speed

    Cycle-accurate deterministic timing is nice to have when designing hard real-time systems, but it's not a necessity. I've designed plenty of hard real-time systems over the years that did not have cycle-accurate timing.
    Never trust a government that doesn't trust you.
     

    Offline NorthGuy

    • Frequent Contributor
    • **
    • Posts: 270
    • Country: ca
    Cache certainly destroy real-timeliness and creates lots of problems in testing. But highly pipelined cores are not very fast without cache. For example, PIC32MZ can run at 200MHz. Their cash-less version PIC32MM only runs at 25MHz. For comparison, dsPIC33EP has a processor designed to run from flash without cache, can run at 70MHz and produces cycle-accurate results.

    Interrupts are not impedance, but rather a means to meat real time requirements. But with one CPU you can meet requirements of only one process - if two things happens at the same time, a single CPU can't deal with both.

    Therefore, a design with multiple cores, each of them performing its own task, is very good for real time. There are few problems though.

    Lots of tasks the MCU is performing are standard. For example, you often will need UART. You can create a core to do UART. However,  low cost MCUs, such as PIC16, already have several UART "cores" and cost much less. So, you often can get by with a small CPU and diverse specialized peripherals. In such case, multicore will be an overkill.

    If you want to do something highly non-standard, then FPGA comes to mind. You can build any numbers of any cores and also make them work really fast. They will run in parallel and will meet real-time requirements perfectly. The only real drawback is cost. To compete with FPGAs, the multi-core designs must be much less expensive than FPGAs. Doesn't seem to be the case.

     

    Online tggzzz

    • Super Contributor
    • ***
    • Posts: 5138
    • Country: gb
      • Having fun doing more, with less
    Interrupts instantly destroy the possibility of knowing how long a piece of code will take to execute, thus losing the cycle-accurate attribute. The same is true for any form of cache or statistical prediction logic.

    Well, on { D, I }, { I } is the worst since its cache miss makes you unable to estimate how long a piece of code will take to execute, the best you can do is considering the worst of the possible foreseeable circumstances when you have to reload the cache and access the (slow) memory to do so.

    In my case there is no cache, and all the fetches happen within the same time.

    We agree; to get consistent timing, you have to turn caches off - so why have the bloody things in the first place!

    Quote
    Btw, how can you make cores able to communicate each others if you don't use an interrupt driven mail box?

    RTFXMOSLiterature, understand CSP, and think about what hardware and software is necessary to support it. I have some computers datestamped 8751 that supported it in hardware; I never had an application for them. The XMOS devices are descendants of those processors.

    Quote
    Another possible solution is that each cpucore keeps looping on a shared memory waiting for data.

    Shared memory isn't scalable, even on-chip and definitely off-chip.

    Quote
    It implies TAS instructions to implement software semaphore, as well as read-modify-write cycles to save the coherence. In my case, since I have fours cores connected through a bar-matrix, I can implement a quadri-port-memory, but it's not a good idea on fpga since BRAM is usually dual port, thus I abandoned it since it implies a lot of resource wasted.

    A pain indeed. Plus, when there's nothing for a core to do, spin loops waste power doing nothing. Much better to sleep until the relevant event occurs. XMOS is quoting event to processor handling the event latencies of <100ns. Obviously that is presuming the processor is waiting for the event to occur.

    Quote
    A hardware mail box looks easier and more efficient. Indeed, in avionics, we have a lot of hardware mail boxes in our fly-boards.

    Yup. You need the hardware to make it efficient, and the software languages to be able to use it. XMOS has both: xCORE and xC.

    Quote
    I still have to see what has been implemented in XMOS chips to allow their cores to communicate.

    RTFDS :) You will find it worthwhile.

    You may even note echoes of CSP in the way systems are architected.
    There are lies, damned lies, statistics - and ADC/DAC specs.
    Gliding aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
    Having fun doing more, with less
     


    Share me

    Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
    Smf