Looking for set of MCU devkits representative of industry and hobbyists - Page 1
Forum section: electronics / general

author: teijo
author_rank: Newbie
timestamp: July 13, 2017, 12:05:31 am
content: 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 withVariety of brandsMCU 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 POVVariety of architectures and capabilitiesWeight on how common the MCU isWhat 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?

author: NorthGuy
author_rank: Super Contributor
timestamp: July 13, 2017, 04:00:48 am
content: Quote from: teijo on July 13, 2017, 12:05:31 amI 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.

author: legacy
author_rank: Super Contributor
timestamp: July 13, 2017, 10:07:57 am
content: 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?

author: teijo
author_rank: Newbie
timestamp: July 13, 2017, 01:20:53 pm
content: 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.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: July 13, 2017, 01:29:32 pm
content: Quote from: colorado.rob on July 13, 2017, 03:17:12 am+1In PIC land...http://www.microchipdirect.com/ProductSearch.aspx?Keywords=DM240004http://www.microchipdirect.com/ProductSearch.aspx?Keywords=DM320104but it really depends on what you want to do with it.

author: wraper
author_rank: Unknown
timestamp: July 13, 2017, 01:46:08 pm
content: You could get some silicon labs dev board (very fast 8051 core). For examplehttps://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

author: legacy
author_rank: Super Contributor
timestamp: July 13, 2017, 02:30:16 pm
content: (p.s.Oh, I have two 8051 boards and an old (but brand new) PIC-KIT2 for sale.)

author: flochlandla
author_rank: Newbie
timestamp: July 14, 2017, 07:38:58 am
content: 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 workbenchI think one of the most powerful starter kits they provide is this one:https://www.olimex.com/Products/MSP430/Starter/MSP430-5438-STK/

author: teijo
author_rank: Newbie
timestamp: July 14, 2017, 09:35:33 pm
content: 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?

author: teijo
author_rank: Newbie
timestamp: July 14, 2017, 09:45:12 pm
content: Quote from: flochlandla on July 14, 2017, 07:38:58 amThanks for the Olimex pointer, looks like they offer plenty of stuff to tinker withDegrading/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.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 16, 2017, 01:21:37 am
content: Quote from: teijo on July 14, 2017, 09:45:12 pmNo 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 16, 2017, 08:31:49 am
content: 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, andcontinuesto 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 iscriticalforhardrealtime systemswhatever their speedFPGA-like I/O structureseasily and simplycontrolled by software, e.g. SERDES up to 250Mb/s, externally/internally clocked, strobed/master-slavetimed 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 4nsencroaching into FPGA territory in ways that are impossible for conventional device such as ARMs etcmulticore - up to 32 32-bit 100MIPS cores on a chip, extendable across chipsparallelism 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 environmentA simple example of their power: they can implement a 100Mb/s MII ethernet interfaces, and USB interfacesin 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=latestVery readable programming tutorial :https://www.xmos.com/support/tools/programming?component=17653

author: teijo
author_rank: Newbie
timestamp: July 16, 2017, 10:44:45 am
content: Quote from: tggzzz on July 16, 2017, 08:31:49 amThe 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

author: legacy
author_rank: Super Contributor
timestamp: July 17, 2017, 07:01:15 am
content: Quote from: tggzzz on July 16, 2017, 08:31:49 amI 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)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.

author: legacy
author_rank: Super Contributor
timestamp: July 17, 2017, 07:08:21 am
content: Quote from: tggzzz on July 16, 2017, 08:31:49 amwhat 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 17, 2017, 07:28:36 am
content: Quote from: legacy on July 17, 2017, 07:08:21 amIt 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).QuoteInterrupts 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 controlsLCDs 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

author: legacy
author_rank: Super Contributor
timestamp: July 17, 2017, 02:37:33 pm
content: Quote from: tggzzz on July 17, 2017, 07:28:36 amWell, 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 17, 2017, 04:14:36 pm
content: Quote from: tggzzz on July 16, 2017, 08:31:49 amCycle-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.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 17, 2017, 04:27:44 pm
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 17, 2017, 04:40:15 pm
content: Quote from: legacy on July 17, 2017, 02:37:33 pmWe agree; to get consistent timing, you have to turn caches off - so why have the bloody things in the first place!QuoteRTFXMOSLiterature, understand CSP, and think about what hardwareand softwareis 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.QuoteShared memory isn't scalable, even on-chip and definitely off-chip.QuoteA pain indeed. Plus,whenthere'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.QuoteYup. You need the hardware to make it efficient, and the software languages to be able to use it. XMOS has both: xCORE and xC.QuoteRTFDSYouwillfind it worthwhile.You may even note echoes of CSP in the way systems are architected.

author: tggzzz
author_rank: Super Contributor
timestamp: July 17, 2017, 05:11:32 pm
content: Quote from: NorthGuy on July 17, 2017, 04:27:44 pmWell, 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 ispractical!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 4000MIPSisn'tthe limit.The top-of-the range processor costs $31 in one-off quantities. Cheapest is £4.50, 250 off.FFI seehttps://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=25QuoteNot really. Interrupts areone wayof 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)QuoteYes and no; it depends on thecombinationof 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 devicescan- but obviously that isn't always a good choice, so some xCORE devices also have dedicated USB and Ethernet links in them.QuoteJust so. xCORE devices aren't magic!Nonetheless they are pushing into FPGA territory in ways that conventional processors and languages simply cannot.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 17, 2017, 06:18:22 pm
content: Quote from: tggzzz on July 17, 2017, 05:11:32 pmThis is an interesting way of measuring performance.Quote from: tggzzz on July 17, 2017, 05:11:32 pmPIC18 interrupt latency is 125nsQuoteQuote from: tggzzz on July 17, 2017, 05:11:32 pmThis 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 17, 2017, 09:54:42 pm
content: Quote from: NorthGuy on July 17, 2017, 06:18:22 pmFairly 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!)QuoteDoes the IDE guarantee that at compile time? And what is it when it issimultaneouslydealing 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 whathardrealtime systemshaveto do.With xCORE the IDE guarantees maximum timings, for the entire chip with all its cores. That's "FPGA like"!QuoteShrug. Anyone can come up with small systems with relaxed non-critical timing. Boring.QuoteNo, 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 [] 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.QuoteTwo 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 wastefulQuoteMany 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.QuoteThat 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 17, 2017, 11:21:09 pm
content: Quote from: blueskull on July 17, 2017, 10:33:51 pmI 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 thelonghistory!The architectural concepts in the language have averygood 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,thatTony 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 18, 2017, 12:03:39 am
content: Quote from: tggzzz on July 17, 2017, 09:54:42 pmMCUs 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.Quote from: tggzzz on July 17, 2017, 09:54:42 pmFPGA 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.Quote from: tggzzz on July 17, 2017, 09:54:42 pmMy 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.

author: Unknown
author_rank: Unknown
timestamp: July 18, 2017, 03:17:06 am
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 18, 2017, 06:36:12 am
content: Quote from: Elf on July 18, 2017, 03:17:06 amI'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.QuoteYes 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 thatQuoteMy understanding is that theydohave 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.QuoteI 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.

author: Unknown
author_rank: Unknown
timestamp: July 18, 2017, 06:56:35 am
content: Quote from: tggzzz on July 18, 2017, 06:36:12 amThe 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 18, 2017, 09:50:06 am
content: Quote from: Elf on July 18, 2017, 06:56:35 amYes 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 18, 2017, 10:26:14 am
content: I notice your other fallacious statements and misapprehensions have melted away. Good.Quote from: NorthGuy on July 18, 2017, 12:03:39 amAh, 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.QuoteYou 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?Beforeimplementing 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)?QuoteThere 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)QuoteCommon 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 18, 2017, 12:18:19 pm
content: Quote from: blueskull on July 17, 2017, 11:35:30 pmI suspected it might be, but I haven't seen that specific FLA beforeI 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.QuoteYes. 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" languagewith only a few minor advantages and disadvantages. Curiously I'd used the same reasoning to avoid learning Delphi a decade earlier.Idon'tregard 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", itdoesdo what it claims.I'm more than happy for people to decide not to use XMOS stufffor 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

author: NorthGuy
author_rank: Super Contributor
timestamp: July 18, 2017, 01:42:49 pm
content: Quote from: tggzzz on July 18, 2017, 10:26:14 amCommon 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.

author: legacy
author_rank: Super Contributor
timestamp: July 18, 2017, 02:08:53 pm
content: Quote from: tggzzz on July 17, 2017, 04:40:15 pmYup, 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 timep.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:mac rt0, rs1, rs1, rs2TrapOnOverFlowThe 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

author: tggzzz
author_rank: Super Contributor
timestamp: July 18, 2017, 02:14:26 pm
content: Quote from: NorthGuy on July 18, 2017, 01:42:49 pmNo, 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".

author: legacy
author_rank: Super Contributor
timestamp: July 18, 2017, 02:23:36 pm
content: 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 )

author: tggzzz
author_rank: Super Contributor
timestamp: July 18, 2017, 02:26:18 pm
content: Quote from: legacy on July 18, 2017, 02:08:53 pmYou're nutsVacations are for doing something completely differentQuoteIf you are interested in the assembly level, thenhttps://www.xmos.com/published/xs2-isa-specificationmight 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 18, 2017, 02:57:17 pm
content: Quote from: legacy on July 18, 2017, 02:23:36 pmThe architecture is indeed "event driven". But then most embedded software systemsareevent 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.QuoteMy 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! GoodQuoteChannels are directly modelled on CSP concepts. The Ada rendezvous has the same heritage. You will notice the correspondanceThat 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. Isuspectthe interface notification might be a useful implementation mechanism for such server FIFOs.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 18, 2017, 04:46:19 pm
content: Quote from: NorthGuy on July 18, 2017, 12:03:39 amAnd 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 18, 2017, 05:13:01 pm
content: Quote from: Sal Ammoniac on July 18, 2017, 04:46:19 pmThey 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 18, 2017, 05:30:20 pm
content: Quote from: tggzzz on July 18, 2017, 05:13:01 pmFrom 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 18, 2017, 08:11:13 pm
content: Quote from: Sal Ammoniac on July 18, 2017, 05:30:20 pmAgreed, 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: July 22, 2017, 03:37:19 pm
content: Quote from: tggzzz on July 18, 2017, 12:18:19 pmA little humility would do you good--your posts are technically interesting, but often argumentative and annoying. You're more reasonable in person, right?QuoteBeing 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 22, 2017, 05:24:29 pm
content: Quote from: andyturk on July 22, 2017, 03:37:19 pmSometimes, sometimes notA 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 arepigheadedlymisguided it is necessary to emphatically point out where they are simply wrong.QuoteYes 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 rejectingbeneficialadvancesbecausethey 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 withsomerelevant 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.