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

0 Members and 1 Guest are viewing this topic.

Offline teijoTopic starter

  • Newbie
  • 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

  • Frequent Contributor
  • **
  • Posts: 419
  • Country: us
 :popcorn:
 
The following users thanked this post: Jeroen3

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • 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 legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
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 teijoTopic starter

  • Newbie
  • 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: 16794
  • 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, 01:54:32 pm by wraper »
 

Offline legacy

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

Offline flochlandla

  • Newbie
  • 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 teijoTopic starter

  • Newbie
  • 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 teijoTopic starter

  • Newbie
  • 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

  • Super Contributor
  • ***
  • Posts: 3137
  • 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.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19279
  • Country: gb
  • Numbers, not adjectives
    • 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.
Glider pilot's 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

Offline teijoTopic starter

  • Newbie
  • 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: 4415
  • Country: ch
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: 4415
  • Country: ch
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.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19279
  • Country: gb
  • Numbers, not adjectives
    • 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.
    Glider pilot's 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: 4415
    • Country: ch
    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 17, 2017, 02:40:55 pm by legacy »
     

    Offline Sal Ammoniac

    • Super Contributor
    • ***
    • Posts: 1662
    • 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.
    Complexity is the number-one enemy of high-quality code.
     

    Offline NorthGuy

    • Super Contributor
    • ***
    • Posts: 3137
    • 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.

     

    Offline tggzzz

    • Super Contributor
    • ***
    • Posts: 19279
    • Country: gb
    • Numbers, not adjectives
      • 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.
    Glider pilot's 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 tggzzz

    • Super Contributor
    • ***
    • Posts: 19279
    • Country: gb
    • Numbers, not adjectives
      • Having fun doing more, with less
    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.

    Well, if you come from an x86/ARM background and can't think outside that box, then I suppose you are right. But XMOS has built on what their designers were doing 30 years ago - so your experience is misleading you as to what is practical!

    The xCORE devices are 32-bit 10ns cycle time and are quoted at up to 4000MIPS for a 32-core chip. If that isn't enough, the on-chip comms hardware and software also work between chips - so 32 cores and 4000MIPS isn't the limit.

    The top-of-the range processor costs $31 in one-off quantities. Cheapest is £4.50, 250 off.
    FFI see https://www.digikey.com/products/en/integrated-circuits-ics/embedded-microcontrollers/685?FV=fffc0370%2Cffe002ad%2C1f140000&mnonly=0&ColumnSort=-143&page=1&stock=0&pbfree=0&rohs=0&cad=0&datasheet=0&nstock=0&photo=0&nonrohs=0&newproducts=0&quantity=&ptm=0&fid=0&pageSize=25

    Quote
    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.

    Not really. Interrupts are one way of doing that, but they come with significant disadvantages in hard realtime applications. A clear example is the latency required to notice an input has changed, then  save/restore processor and RTOS state.

    Other mechanisms avoid those problems. (xCORE latency <100ns :) )

    Quote
    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.

    Yes and no; it depends on the combination of I/O devices an application requires. That can lead to "kitchen sink" chips where much of the (expensive) silicon remains unused in an application.

    Apart from that, UARTs are boringly and trivially slow.  Can a "conventional" processor implement a 100Mb/s ethernet link in software, while also doing other things? Or a USB endpoint? The XMOS devices can - but obviously that isn't always a good choice, so some xCORE devices also have dedicated USB and Ethernet links in them.

    Quote
    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.

    Just so. xCORE devices aren't magic!

    Nonetheless they are pushing into FPGA territory in ways that conventional processors and languages simply cannot.
    There are lies, damned lies, statistics - and ADC/DAC specs.
    Glider pilot's 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 NorthGuy

    • Super Contributor
    • ***
    • Posts: 3137
    • Country: ca
    The xCORE devices are 32-bit 10ns cycle time and are quoted at up to 4000MIPS for a 32-core chip. If that isn't enough, the on-chip comms hardware and software also work between chips - so 32 cores and 4000MIPS isn't the limit.

    This is an interesting way of measuring performance.

    Other mechanisms avoid those problems. (xCORE latency <100ns :) )

    PIC18 interrupt latency is 125ns ;)

    Quote
    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.

    Apart from that, UARTs are boringly and trivially slow.  Can a "conventional" processor implement a 100Mb/s ethernet link in software, while also doing other things? Or a USB endpoint? The XMOS devices can - but obviously that isn't always a good choice, so some xCORE devices also have dedicated USB and Ethernet links in them.

    This example illustrates my point well. 100BaseT Ethernet controller is cheaper when done in hardware. Software implementations will be more expensive. Thus, when you can do things in hardware, it is more cost-efficient.

    UART may look boring to you, but if you need it what do you do?

    - Small MCUs have hardware modules - very little silicon, low cost, low power.

    - XMOS needs to sacrifice a full core - the one that could do much much more than simple UART. The capabilities get unused, but the core still uses power.

    - FPGA uses a very tiny part of the logic. Xilinx FPGA requires 4 or 5 slices. It is way more silicon that hardware implementation, but it is much less than is needed to build the whole core. And there's no waste - you use only your 5 slices.

    Now imagine you need 3 UARTs, 4 SPI, and I2C, 5 simple PWMs. Each task uses its own core but does very little. The same could've been accomplished by a small MCU with diverse peripheral, or by very small part of FPGA logic. And the cost (in terms of used silicon, power etc.) would be less in both cases.

    So, multi-core sounds like a good idea, but when you look at the economy of things, it really isn't. And you can see how this is reflected in the prices of XMOS devices.

     

    Offline tggzzz

    • Super Contributor
    • ***
    • Posts: 19279
    • Country: gb
    • Numbers, not adjectives
      • Having fun doing more, with less
    The xCORE devices are 32-bit 10ns cycle time and are quoted at up to 4000MIPS for a 32-core chip. If that isn't enough, the on-chip comms hardware and software also work between chips - so 32 cores and 4000MIPS isn't the limit.

    This is an interesting way of measuring performance.

    Fairly standard, and quite relevant when moving away from the old-fashioned single core processors. (And the instructions in each IPS are relatively high level; they certainly aren't microcode!)

    Quote
    Other mechanisms avoid those problems. (xCORE latency <100ns :) )

    PIC18 interrupt latency is 125ns ;)

    Does the IDE guarantee that at compile time? And what is it when it is simultaneously dealing with i/o from a USB link plus a front-panel, plus  a motor, plus control-loop processing, plus data presentation processing, plus some DSP, plus... That's what hard realtime systems have to do.

    With xCORE the IDE guarantees maximum timings, for the entire chip with all its cores. That's "FPGA like"!

    Quote
    Quote
    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.

    Shrug. Anyone can come up with small systems with relaxed non-critical timing. Boring.

    Quote
    Apart from that, UARTs are boringly and trivially slow.  Can a "conventional" processor implement a 100Mb/s ethernet link in software, while also doing other things? Or a USB endpoint? The XMOS devices can - but obviously that isn't always a good choice, so some xCORE devices also have dedicated USB and Ethernet links in them.

    This example illustrates my point well. 100BaseT Ethernet controller is cheaper when done in hardware. Software implementations will be more expensive. Thus, when you can do things in hardware, it is more cost-efficient.

    UART may look boring to you, but if you need it what do you do?

    - Small MCUs have hardware modules - very little silicon, low cost, low power.

    - XMOS needs to sacrifice a full core - the one that could do much much more than simple UART. The capabilities get unused, but the core still uses power.

    No, and no.

    No, it doesn't need to use a full core. In some circumstances it is possible for the compiler to merge tasks onto a single core (see the xC [[composable]] annotation).  Even when not, it is easy to manually interleave processing from several sources in a single core. (Currently I'm using a single core for several independent tasks: UART IO plus protocol, reading front panel controls, and a few other things as well)

    No, it doesn't use power. If a core is waiting for an incoming event (e.g. an input or timeout) then it consumes zero power.

    Quote
    - FPGA uses a very tiny part of the logic. Xilinx FPGA requires 4 or 5 slices. It is way more silicon that hardware implementation, but it is much less than is needed to build the whole core. And there's no waste - you use only your 5 slices.

    Two can play that (rather unenlightening) game, viz: presumably you are either using a tiny part of an FPGA and have an additional processor, or you have a very inefficient soft-processor in the FPGA. Either way is wasteful :)

    Quote
    Now imagine you need 3 UARTs, 4 SPI, and I2C, 5 simple PWMs. Each task uses its own core but does very little. The same could've been accomplished by a small MCU with diverse peripheral, or by very small part of FPGA logic. And the cost (in terms of used silicon, power etc.) would be less in both cases.

    Many of my designs have non-standard IO devices for which there are no standard protocols. xCORE can deal with those without needing extra external hardware; standard MCUs need extra external custom hardware.

    xCORE can even "suck in" some traditional external logic, thus reducing the board cost. A neat example that is simple to explain is LCD processors. They guarantee LCDs have zero DC voltage applied across the segments. You couldn't safely do that in a bog-standard MCU, but the guaranteed timing in an xCORE processor makes it possible.

    Quote
    So, multi-core sounds like a good idea, but when you look at the economy of things, it really isn't. And you can see how this is reflected in the prices of XMOS devices.

    That entirely depends on your application. Don't presume that your limited view of the world encompasses all applications.

    That's reflected in the company's (XMOS's) valuation, in the number of companies that have invested and are continuing to invest in XMOS.
    There are lies, damned lies, statistics - and ADC/DAC specs.
    Glider pilot's 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 tggzzz

    • Super Contributor
    • ***
    • Posts: 19279
    • Country: gb
    • Numbers, not adjectives
      • Having fun doing more, with less
    If I just want as high MMACS as possible with as guaranteed timing as possible while being constrained by cost, give me a reason not to use MAX 10 or Cyclone 10 LP? Hardware multipliers, true dual port RAM, on chip configuration (MAX 10) and proven language and IDE.

    I don't know what an MMACS is (a mini hamburger?), so I can' t help you there. I'm not an XMOS employee, so I don't feel any reason to try to persuade you to leave your comfort zone. As for "proven language and IDE", you are clearly unaware of the long history!

    The architectural concepts in the language have a very good pedigree - both theoretical and commercial - having been first developed in the mid 70s, i.e. 40 years ago. FFI, see Tony Hoare's Communicating Sequential Processes (CSP). (Yes, that Tony Hoare, of Quicksort, Dining Philosophers, null references, Z, formal methods fame!)

    The first language and highly scalable parallel processors (OCCAM and the Transputer) were developed in the mid 80s, i.e. 30 years ago. Some of the hardware concepts are so good they keep being reinvented over the decades, e.g. in some of the Texas TMS320 chips. Modern non-embedded languages are beginning to pick up on its concepts - because they have been proven to be sound and practical over the decades.

    The xCORE processors and xC language are direct descendents of OCCAM and the Transputer, by some of the same people.

    The IDE is Eclipse, and the compiler is LLVM, and the debugger is GDB. They seem to have a reasonable pedigree.

    So I really don't think that the language and IDE are as much of a problem as you leaving your comfort zone.

    Moores law is at an end. Multicore computing is everywhere. C won't cut it for long, and will gradually become less important, in the same way that Cobol and C++ are. Unless you are at the end of your career, you are going to have to leave your comfort zone. Might as well do it with something that has a solid pedigree forged over the decades.
    There are lies, damned lies, statistics - and ADC/DAC specs.
    Glider pilot's 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 NorthGuy

    • Super Contributor
    • ***
    • Posts: 3137
    • Country: ca
    And what is it when it is simultaneously dealing with i/o from a USB link plus a front-panel, plus  a motor, plus control-loop processing, plus data presentation processing, plus some DSP, plus... That's what hard realtime systems have to do.

    MCUs don't work that way. Most of the work is dome by peripheral modules which ensure real-time operations. Peripheral does buffering, can do DMA if needed. This removes urgency from the CPU. CPU mostly organizes everything and often sits idle waiting for things to happen.

    Two can play that (rather unenlightening) game, viz: presumably you are either using a tiny part of an FPGA and have an additional processor, or you have a very inefficient soft-processor in the FPGA. Either way is wasteful :)

    FPGA don't work that way neither. Most of the stuff in FPGA is done by state-machines in parallel. The fabric is split between tasks and the tasks run pretty much independent using just as much resources as needed. Although, you can build soft cores and specialize them for the application, this is not necessary and often not needed.

    BTW: "very inefficient soft-processor", such as Xilinx MicroBlaze can run circles around XMOS-cores.

    Xilinx Artix-7 wich can handle clock periods  of 2ns starts from $25.

    That entirely depends on your application. Don't presume that your limited view of the world encompasses all applications.

    My limited view of the world doesn't encompass applications. It encompasses principles and common sense. If you want to discuss applications, post the detailed description and specs for the application, and then we can discuss applications.
     

    Elf

    • Guest
    Dynamic, horizontally scaled infrastructure and parallelized software architecture is my current day job, and Erlang is one of my favorite programming languages, so I was very interested in the XMOS chips. I bought the start kit and the programmer and all that. Neat product, well thought out.

    The only thing is that most problems, or at least the ones I deal with in electronics (rather than on computers), are "boring problems." I actively try to find a reason to use XMOS chips in my project backlog, but I always end up back with a cheaper microcontroller with peripherals doing most of the lifting, and the rest with perhaps somewhat ugly, but workable, use of interrupts. Implementation on an xCore chip could be more elegant from a software perspective, but not actually necessary, a few dollars too expensive, and still not quite a substitute for what an FPGA is good at.

    It seems like some strong applications of xCore are pretty much any kind of display interfacing, and dealing with digital audio. Makes sense, since they also seem to have an audio-centric product line.

    I think if they released a cut down low end chip (even smaller than their 4 core) in QFN or QFP, around the $2-3 price point, I would use it a lot more often, just because programming with interrupts is not very fun. Or, with their current lineup, if they just had a good vendor supplied USB host library. (Not something I want to implement on my own)

    As far as the original topic I think the Renesas RL78 is often overlooked and probably one of my favorite chips. Good documentation, easy to work with, inexpensive chips (although the dev board cost is above average), and absolutely loaded with peripherals. More timers and serial units than you can shake a stick at. Their RX lineup also seems similarly good if you want more resources and 32-bit, but I have not used it as much.
     

    Offline tggzzz

    • Super Contributor
    • ***
    • Posts: 19279
    • Country: gb
    • Numbers, not adjectives
      • Having fun doing more, with less
    Dynamic, horizontally scaled infrastructure and parallelized software architecture is my current day job, and Erlang is one of my favorite programming languages, so I was very interested in the XMOS chips. I bought the start kit and the programmer and all that. Neat product, well thought out.

    I've always liked Erlang for the reasons you mention, plus the claimed advantage of relatively easy hotswapping hardware and software - which is vital for "high availability" applications. Unfortunately I haven't been able to justify deploying Erlang, since there are advantages to sticking with widely understood languages such as Java. (A point that is also valid in this xCORE vs conventional MCU debate).

    Unsurprisingly "my" systems ended up having many resemblances to Erlang (and some of its properties), but in a "homebrew" architecture.

    Quote
    The only thing is that most problems, or at least the ones I deal with in electronics (rather than on computers), are "boring problems." I actively try to find a reason to use XMOS chips in my project backlog, but I always end up back with a cheaper microcontroller with peripherals doing most of the lifting, and the rest with perhaps somewhat ugly, but workable, use of interrupts. Implementation on an xCore chip could be more elegant from a software perspective, but not actually necessary, a few dollars too expensive, and still not quite a substitute for what an FPGA is good at.

    Yes indeed! I agree completely.

    Nonetheless it is useful and beneficial to understand radical alternatives, so that you can better understand how to recognise and mitigate the disadvantages of conventional approaches. It sounds like you actively do that :)

    Quote
    It seems like some strong applications of xCore are pretty much any kind of display interfacing, and dealing with digital audio. Makes sense, since they also seem to have an audio-centric product line.

    I think if they released a cut down low end chip (even smaller than their 4 core) in QFN or QFP, around the $2-3 price point, I would use it a lot more often, just because programming with interrupts is not very fun. Or, with their current lineup, if they just had a good vendor supplied USB host library. (Not something I want to implement on my own)

    My understanding is that they do have a USB host library. It seems each USB endpoint requires a separate core. I don't know enough about USB to be able to make useful comments about its effectiveness. Commercially I would have thought it would be better to have dedicated hardware for a USB (or ethernet) interface - and oddly enough that's exactly what XMOS does!

    The noteworthy point is that it is possible and practical to do it in software at the same time as your application does useful work.

    Quote
    As far as the original topic I think the Renesas RL78 is often overlooked and probably one of my favorite chips. Good documentation, easy to work with, inexpensive chips (although the dev board cost is above average), and absolutely loaded with peripherals. More timers and serial units than you can shake a stick at. Their RX lineup also seems similarly good if you want more resources and 32-bit, but I have not used it as much.

    I have no comment, other than to note that (just as with computer languages) there are too many MCU families for it to be possible to learn them all - and that many problems can be adequately solved using any variant.

    The things that are worth understanding are the tools with radically different strategies for skinning the cat. Both xCORE/xC and Erlang fall into that category.
    There are lies, damned lies, statistics - and ADC/DAC specs.
    Glider pilot's 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
     

    Elf

    • Guest
    I've always liked Erlang for the reasons you mention, plus the claimed advantage of relatively easy hotswapping hardware and software - which is vital for "high availability" applications.
    The language does make it easy to instrument, but practical implementation is the difficult part. You have to plan around things like versioning data structures and backwards compatibility, since you may have older instances of objects still out there somewhere from before the code upgrade. An interesting challenge, though.
     

    Offline tggzzz

    • Super Contributor
    • ***
    • Posts: 19279
    • Country: gb
    • Numbers, not adjectives
      • Having fun doing more, with less
    I've always liked Erlang for the reasons you mention, plus the claimed advantage of relatively easy hotswapping hardware and software - which is vital for "high availability" applications.
    The language does make it easy to instrument, but practical implementation is the difficult part. You have to plan around things like versioning data structures and backwards compatibility, since you may have older instances of objects still out there somewhere from before the code upgrade. An interesting challenge, though.

    Yes indeed, but that is inherent in the problem, however you choose to solve it. Hence it is true of any and every HA system, regardless of the language and implementation technologies, including RDBMSs.

    Erlang makes one aspect of the solution easier, and doesn't make the other aspects more difficult.
    There are lies, damned lies, statistics - and ADC/DAC specs.
    Glider pilot's 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 tggzzz

    • Super Contributor
    • ***
    • Posts: 19279
    • Country: gb
    • Numbers, not adjectives
      • Having fun doing more, with less
    I notice your other fallacious statements and misapprehensions have melted away. Good.

    And what is it when it is simultaneously dealing with i/o from a USB link plus a front-panel, plus  a motor, plus control-loop processing, plus data presentation processing, plus some DSP, plus... That's what hard realtime systems have to do.

    MCUs don't work that way. Most of the work is dome by peripheral modules which ensure real-time operations. Peripheral does buffering, can do DMA if needed. This removes urgency from the CPU. CPU mostly organizes everything and often sits idle waiting for things to happen.

    Ah, the old trap of thinking that hard realtime == fast. It doesn't. Hard realtime means guaranteed timing.

    Your statement ignores the requirement for timing that is guaranteed by design, not by testing and measurement.

    Quote
    Two can play that (rather unenlightening) game, viz: presumably you are either using a tiny part of an FPGA and have an additional processor, or you have a very inefficient soft-processor in the FPGA. Either way is wasteful :)

    FPGA don't work that way neither. Most of the stuff in FPGA is done by state-machines in parallel. The fabric is split between tasks and the tasks run pretty much independent using just as much resources as needed. Although, you can build soft cores and specialize them for the application, this is not necessary and often not needed.

    BTW: "very inefficient soft-processor", such as Xilinx MicroBlaze can run circles around XMOS-cores.

    You appear to be switching your definition of "efficient" between "low area" and "high performance" without bothering to tell people which you mean in any given statement.

    There are many variants of MicroBlaze; which are you referring to?
    Before implementing one in your design, what is the guaranteed cycle time (i.e. pre-layout)?
    By what measure does the smallest (or largest) MicroBlaze run circles around the smallest (4 core) xCORE  processor or largest (32 core)?

    Quote
    Xilinx Artix-7 wich can handle clock periods  of 2ns starts from $25.

    There are obviously cases where FPGAs will beat other technology; only a fool would think otherwise.

    However, I'll note that the XS1 devices found in the £10 StartKit handle clock periods of 4ns - which is definitely encroaching on FPGA territory.

    The newer  xCORE200 devices have two tiles with up to 8 concurrent threads each. Each thread can run at up to 100 MHz, and threads may be able to execute 2 instructions in a clock cycle. Five threads follow each other through the pipeline, resulting in a top speed of 2000 MIPS (if all instructions dual issue), and a speed of at least 1000 MIPS (if all instructions are single issue)

    Quote
    That entirely depends on your application. Don't presume that your limited view of the world encompasses all applications.

    My limited view of the world doesn't encompass applications. It encompasses principles and common sense. If you want to discuss applications, post the detailed description and specs for the application, and then we can discuss applications.

    Common sense isn't common, and is irrelevant in significantly different situations.

    Theory without practice is mental masturbation. Practice without theory is fumbling in the dark. The XMOS approach is strong in both theory (40 years old) and practice (30 years old) and specific implementation (10 years old).

    You appear to be unaware of fundamental theory, so I'm unsurprised that you don't understand the relevant principles, and unsurprised that your "common sense" isn't applicable in this case.
    There are lies, damned lies, statistics - and ADC/DAC specs.
    Glider pilot's 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 tggzzz

    • Super Contributor
    • ***
    • Posts: 19279
    • Country: gb
    • Numbers, not adjectives
      • Having fun doing more, with less
    I don't know what an MMACS is (a mini hamburger?), so I can' t help you there.

    Million Multiply and Accumulations. Used to benchmark raw power of DSPs. Many classical (FFT, FIR, IIR) DSP algorithms and software neural network can be computed as blocks expressed as y=y+k*x, which is a MAC (mult-accu).

    I suspected it might be, but I haven't seen that specific FLA before :)

    I won't comment on the suitability for your application, but I will note that XMOS devices have been used for DSP for a while now. Currently they seem to be pushing "smart microphones", which I presume is heavy on DSP. I suspect, without any evidence whatsoever, that the alternative implementation technologies would involve FPGAs, but that XMOS devices can be cheaper.

    Quote
    Moores law is at an end. Multicore computing is everywhere. C won't cut it for long, and will gradually become less important, in the same way that Cobol and C++ are.

    I turned to C#. Spending 1.5 years on HPC (OpenCL, CUDA, OpenMP/gcc) as a hobby, I realized by my own force doing HPC isn't really that smart. I would like MS to get that done for me and give my parallelized libraries.
    Windows 10 is a perfect example -- they introduces parallelism in CLR level, so even a (seemingly) single thread program, as long as it's based on .NET, can take advantage of multi-core.
    Also, C# has recently introduces quite some new features on using multiple cores, besides libraries (think of STL in C++), such as async functions and async linq.

    Yes. While I started using C when there were precisely two books about it, IMNSHO C/C++ started to be part of the problem (rather than part of the solution) in the early-mid 90s. Fortunately Java came along to pick up where C/C++ were getting into difficulties. What kind of difficulties? Well, POSIX libraries having to rely on compiler/language behaviour that was explicitly outside the language definition (and punted to the libraries!), the language designers not realising templates are Turing complete in their own right, and the interminable unresolvable committee arguments about whether "casting away constness" was mandatory or forbidden.

    I'd been using Java for 5 years (IIRC) when I listened to a talk by Hejlsberg just before C# was released, and mentioned to him that it looked like C# was Java with a different optimisation strategy and reduced security. His response wasn't memorable, and I decided not to bother learning yet another vendor specific "me too" language with only a few minor advantages and disadvantages. Curiously I'd used the same reasoning to avoid learning Delphi a decade earlier.

    I don't regard xC/xCORE as being "me too" with only a few minor differences to existing products. IMNSHO they have some unique characteristics that fit with my interests and my beliefs (hopes really :( ) about the future direction technology ought to take. Having "kicked the technology's tyres", it does do what it claims.

    I'm more than happy for people to decide not to use XMOS stuff for valid reasons. Being out of their comfort zone and/or presuming they can rely on their pre-existing rules-of-thumb don't count as valid reasons :)
    There are lies, damned lies, statistics - and ADC/DAC specs.
    Glider pilot's 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 NorthGuy

    • Super Contributor
    • ***
    • Posts: 3137
    • Country: ca
    You appear to be unaware of fundamental theory, so I'm unsurprised that you don't understand the relevant principles, and unsurprised that your "common sense" isn't applicable in this case.

    Common sense is applicable everywhere. It lets us distinguish facts from the soup of numbers and cliché phrases which you're outputting here. No wonder you don't like it.

    I'm sorry. I grew a little bit tired of your stupidity, so I'll bail out of this thread.
     

    Offline legacy

    • Super Contributor
    • ***
    • !
    • Posts: 4415
    • Country: ch
    RTFDS :) You will find it worthwhile.

    You may even note echoes of CSP in the way systems are architected.

    Yup, I am going to download everything I can download into my Kindle PaperWhite (ebook reader made by Amazon), so I will have interesting things to read under the umbrella on the beach during the next vacation time :D

    p.s.
    oh, MIPS removed the status register, so I have also removed it from my Arise-v2/r5 project. Looking at XMOS, I see it comes with threads, dedicated registers, and there is also a status register which contains various mode bits, but the processor does not have the standard ALU result flags like carry, zero, negative or overflow.

    Probably I will have to study the XMOS ALU. Mine is a standard MIPS design where I am supporting overflow and underflow as "exceptions". If you enable the features in COP1 (in my design it's the arithmetic signed/unsigned unit) then the unit raises an exception when an overflow/underflow event occurs. I also have special "trap" instructions: e.g. TrapOnOverFlow, TrapOnUnderFlow, which you need to put after a computation. From the point of view of the datapath along the CPUCORE it's a "NOP", but if the COP1 has an event ... you get trapped into exception.

    e.g.
    Code: [Select]
    mac rt0, rs1, rs1, rs2
    TrapOnOverFlow

    The difference between them is: with the first class of instruction everything that makes an over/under flow is catch as exception, whereas with the second class of instruction I can selectively check operations of my specific interest.

    I also have a COP2, which is a DSP engine with a saturated arithmetic, it means no overflow/underflow can happen. Never.

    What do you think about that?

    Let me download XMOS's doc. Probably I will end buying an Evaluation board  :D
     

    Offline tggzzz

    • Super Contributor
    • ***
    • Posts: 19279
    • Country: gb
    • Numbers, not adjectives
      • Having fun doing more, with less
    You appear to be unaware of fundamental theory, so I'm unsurprised that you don't understand the relevant principles, and unsurprised that your "common sense" isn't applicable in this case.

    Common sense is applicable everywhere. It lets us distinguish facts from the soup of numbers and cliché phrases which you're outputting here. No wonder you don't like it.

    No, common sense isn't always applicable; it frequently leads people astray.

    We note you have made many assertions (e.g. "runs circles") that you have neither clarified when requested, nor backed up with numbers.

    If you don't want to learn and expand your horizons, then it is indeed better if you "bail out".
    « Last Edit: July 18, 2017, 02:16:21 pm by tggzzz »
    There are lies, damned lies, statistics - and ADC/DAC specs.
    Glider pilot's 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: 4415
    • Country: ch
    XMOS (at least the XS1 architecture) seems to be "event-driven"

    I mean, as far as I understand for the ISA, there are two kind of instructions:
    those that can dispatch an external events (synchronous)
    those that can handle interrupts (asynchronous)

    So we still have interrupts, but you can choose to use events, and if so, the underlying processor has to expect an event and wait in a specific place so that it can be handled synchronously.

    That is interesting, since in my case every I/O can ONLY be handled asynchronously using interrupts.



    p.s.
    I am reading that in XS1 all the communication between threads is performed using channels that provide full-duplex data transfer between channel-ends. That is another interesting concept.

    In my case I am using mailboxes. I have to understand the difference, they are similar in some aspects ( I believe )
     

    Offline tggzzz

    • Super Contributor
    • ***
    • Posts: 19279
    • Country: gb
    • Numbers, not adjectives
      • Having fun doing more, with less
    RTFDS :) You will find it worthwhile.

    You may even note echoes of CSP in the way systems are architected.

    Yup, I am going to download everything I can download into my Kindle PaperWhite (ebook reader made by Amazon), so I will have interesting things to read under the umbrella on the beach during the next vacation time :D

    You're nuts :) Vacations are for doing something completely different :)

    Quote

    p.s.
    oh, MIPS removed the status register, so I have also removed it from my Arise-v2/r5 project. Looking at XMOS, I see it comes with threads, dedicated registers, and there is also a status register which contains various mode bits, but the processor does not have the standard ALU result flags like carry, zero, negative or overflow.

    Probably I will have to study the XMOS ALU. Mine is a standard MIPS design where I am supporting overflow and underflow as "exceptions". If you enable the features in COP1 (in my design it's the arithmetic signed/unsigned unit) then the unit raises an exception when an overflow/underflow event occurs. I also have special "trap" instructions: e.g. TrapOnOverFlow, TrapOnUnderFlow, which you need to put after a computation. From the point of view of the datapath along the CPUCORE it's a "NOP", but if the COP1 has an event ... you get trapped into exception.

    e.g.
    Code: [Select]
    mac rt0, rs1, rs1, rs2
    TrapOnOverFlow

    The difference between them is: with the first class of instruction everything that makes an over/under flow is catch as exception, whereas with the second class of instruction I can selectively check operations of my specific interest.

    I also have a COP2, which is a DSP engine with a saturated arithmetic, it means no overflow/underflow can happen. Never.

    What do you think about that?

    Let me download XMOS's doc. Probably I will end buying an Evaluation board  :D

    If you are interested in the assembly level, then https://www.xmos.com/published/xs2-isa-specification might be of interest to you.

    You will note there are some instructions for setting up on comms channels between cores, between tiles and between chips. Hence you might be interested in the XSwitch technology.

    You will also note there are some instructions for i/o ports, so you might also be interested in the ports architecture.

    Summary: multicore, fast i/o, comms and the language are all tied together in a unified whole, in a way that just doesn't occur with traditional MCUs.
    There are lies, damned lies, statistics - and ADC/DAC specs.
    Glider pilot's 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 tggzzz

    • Super Contributor
    • ***
    • Posts: 19279
    • Country: gb
    • Numbers, not adjectives
      • Having fun doing more, with less
    XMOS (at least the XS1 architecture) seems to be "event-driven"

    The architecture is indeed "event driven". But then most embedded software systems are event driven. An interrupt is captured, the ISR generates an internal software event, which is  delivered to a task using RTOS facilities such as mailboxes and FIFOs etc.

    With XMOS, the events are generated in the ports, and the corresponding event is transmitted through the switch fabric to the relevant core. In that sense the hardware pokes something into "an RTOS mailbox", and the RTOS is in hardware. That gives an inkling of why traditional interrupts aren't very interesting.

    Quote
    I mean, as far as I understand for the ISA, there are two kind of instructions:
    those that can dispatch an external events (synchronous)
    those that can handle interrupts (asynchronous)

    My interest so far has been to push hard on the xC/xCORE facilities to see where they aren't sufficient for a simple hard realtime system (a dual channel 15MHz frequency counter implemented in software, with a real front panel and a soft front panel at the other end of a USB link).

    Since I've been able to do everything I wanted at that level, I haven't felt it necessary to find out about interrupts - and that's significant. Indeed, I'm not clear where they might be or must be used.

    I suspect your knowledge will rapidly exceed mine in this area!  Good :)

    Quote
    So we still have interrupts, but you can choose to use events, and if so, the underlying processor has to expect an event and wait in a specific place so that it can be handled synchronously.

    That is interesting, since in my case every I/O can ONLY be handled asynchronously using interrupts.

    p.s.
    I am reading that in XS1 all the communication between threads is performed using channels that provide full-duplex data transfer between channel-ends. That is another interesting concept.

    In my case I am using mailboxes. I have to understand the difference, they are similar in some aspects ( I believe )

    Channels are directly modelled on CSP concepts. The Ada rendezvous has the same heritage. You will notice the correspondance :)

    That blocking synchronisation between the sender and receiver, while theoretically sufficient, can be a pain in the backside. For example, you can make traditional multiple-input single-server FIFOs out of channels (see an XMOS app note), but you "lose" a core.

    Fortunately there are also xC "interfaces", which enable non-blocking notification between tasks. I've used both: channels for strict hard realtime dataflow, and interfaces for notification that a user has requested a change that the receiver can pick up and implement at a convenient time.  I suspect the interface notification might be a useful implementation mechanism for such server FIFOs.
    There are lies, damned lies, statistics - and ADC/DAC specs.
    Glider pilot's 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 Sal Ammoniac

    • Super Contributor
    • ***
    • Posts: 1662
    • Country: us
    BTW: "very inefficient soft-processor", such as Xilinx MicroBlaze can run circles around XMOS-cores.

    And if those soft cores are not enough horsepower, there's always the Xilinx Zynq parts, which have dual core ARM Cortex-A9 or dual and quad core Cortex-A53 (and dual Cortex-R5) CPUs running at over a GHz, plus the FPGA fabric, plus gigabit Ethernet, USB 3, SATA 3.1, Display Port, and more.
    Complexity is the number-one enemy of high-quality code.
     

    Offline tggzzz

    • Super Contributor
    • ***
    • Posts: 19279
    • Country: gb
    • Numbers, not adjectives
      • Having fun doing more, with less
    BTW: "very inefficient soft-processor", such as Xilinx MicroBlaze can run circles around XMOS-cores.

    And if those soft cores are not enough horsepower, there's always the Xilinx Zynq parts, which have dual core ARM Cortex-A9 or dual and quad core Cortex-A53 (and dual Cortex-R5) CPUs running at over a GHz, plus the FPGA fabric, plus gigabit Ethernet, USB 3, SATA 3.1, Display Port, and more.

    They do indeed have a lot of horsepower, and are interesting devices. However they aren't cheap, and the development environment (Vivado) is a pig in several ways! In some ways that's to be expected, since the underlying capabilities are powerful, complex, and unconstrained.

    If you are proficient in VHDL/Verilog and ARM/C and Eclipse, I wonder how long it takes to become proficient in the use of Vivado itself. I would guess several weeks at least. That's an impediment to someone that might or might not want to develop an FPGA design just to understand their characteristics.

    By way of contrast, knowing Eclipse but having zero experience of xCORE and xC, I was creating useful non-trivial first versions of my application within a day. By non trivial I mean determining the speed of the core part of the application.

    That was easier than I expected, and means that I think it is practical and worthwhile for many people to expand their horizons, even if they never use xC/xCORE in anger.
    « Last Edit: July 18, 2017, 05:16:20 pm by tggzzz »
    There are lies, damned lies, statistics - and ADC/DAC specs.
    Glider pilot's 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 Sal Ammoniac

    • Super Contributor
    • ***
    • Posts: 1662
    • Country: us
    If you are proficient in VHDL/Verilog and ARM/C and Eclipse, I wonder how long it takes to become proficient in the use of Vivado itself. I would guess several weeks at least. That's an impediment to someone that might or might not want to develop an FPGA design just to understand their characteristics.

    From personal experience: about two days. Vivado is much better than the earlier Xilinx software (ISE).

    Even if it takes longer, that's not an impediment to a professional developing a commercial product.
    Complexity is the number-one enemy of high-quality code.
     

    Offline tggzzz

    • Super Contributor
    • ***
    • Posts: 19279
    • Country: gb
    • Numbers, not adjectives
      • Having fun doing more, with less
    If you are proficient in VHDL/Verilog and ARM/C and Eclipse, I wonder how long it takes to become proficient in the use of Vivado itself. I would guess several weeks at least. That's an impediment to someone that might or might not want to develop an FPGA design just to understand their characteristics.

    From personal experience: about two days. Vivado is much better than the earlier Xilinx software (ISE).

    Even if it takes longer, that's not an impediment to a professional developing a commercial product.

    Agreed, but I'm surprised it isn't longer. I've heard complaints about Figaro, but I haven't used ISE.

    One thing that did surprise me about Vivado (a few years ago when it was still novel) was that I couldn't find a definition of which of the myriad files should and should not be stored in a source control system.
    There are lies, damned lies, statistics - and ADC/DAC specs.
    Glider pilot's 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 andyturk

    • Frequent Contributor
    • **
    • Posts: 895
    • Country: us
    [...] IMNSHO [...]

    A little humility would do you good--your posts are technically interesting, but often argumentative and annoying. You're more reasonable in person, right?

    Quote
    I'm more than happy for people to decide not to use XMOS stuff for valid reasons. Being out of their comfort zone and/or presuming they can rely on their pre-existing rules-of-thumb don't count as valid reasons :)

    Being out of one's comfort zone is *absolutely* a valid reason for not using a technology--at least in a commercial project. I.e., if I'm not comfortable with a technology, I have no business telling someone I can deliver a product with it.
     

    Offline tggzzz

    • Super Contributor
    • ***
    • Posts: 19279
    • Country: gb
    • Numbers, not adjectives
      • Having fun doing more, with less
    [...] IMNSHO [...]

    A little humility would do you good--your posts are technically interesting, but often argumentative and annoying. You're more reasonable in person, right?

    Sometimes, sometimes not ;)

    A lot depends on humility in the form of being dissatisfied with what I did last time, and seeking to improve next time around. A lot depends on having the experience to know when you are on solid ground, and the humility to recognise where you are not. Part of that comes from actively seeking contrary opinions, and assessing where they are/aren't valid - and from running away as fast as possible from "echo chambers".

    Sometimes it is beneficial for all parties involved if some concepts and conceptions are vigorously challenged. It is necessary, however, that the concepts are being challenged with the right intention, e.g. making step improvements.

    Sometimes when people are pigheadedly misguided it is necessary to emphatically point out where they are simply wrong.

    Quote
    Quote
    I'm more than happy for people to decide not to use XMOS stuff for valid reasons. Being out of their comfort zone and/or presuming they can rely on their pre-existing rules-of-thumb don't count as valid reasons :)

    Being out of one's comfort zone is *absolutely* a valid reason for not using a technology--at least in a commercial project. I.e., if I'm not comfortable with a technology, I have no business telling someone I can deliver a product with it.

    Yes and no.
    • if that attitude is taken too rigidly, then it prevents progress and improvement.
    • in most of my professional career, I have been in application domains that were novel and/or using technologies that were novel. (Where "novel" is either to the team/company, or globally)
    So being out of my comfort zone is normal, and it biasses me against rejecting beneficial advances because they are novel.

    However, on some commercial projects I have indeed made the decision that the risks of the unknown outweigh the foreseeable potential benefits. (E.g. C# w.r.t. Java, or Delphi w.r.t. C.)

    OTOH, on some commercial projects (e.g. as the manager of a project proposing to use C for the first time, back in 1982), I was definitely out of my comfort zone but I listened to those with some relevant experience. That was a good decision.

    And I expect most of us have seen people that have naive outdated notions about technology, and refused to believe that they simply don't understand modern advances. Classic example is that "garbage collectors are slow and not suited to (soft) realtime systems", and refusing to comprehend that they had only heard about decades old reference counting GCs, and that Java's GCs were perfectly adequate. Even when presented with presented with a working system, they still clung to their outdated notion, and started to whinge about other things.
    « Last Edit: July 22, 2017, 05:26:55 pm by tggzzz »
    There are lies, damned lies, statistics - and ADC/DAC specs.
    Glider pilot's 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