Multi Microcontroller design. - Page 1
Forum section: electronics / general

author: jitece
author_rank: Newbie
timestamp: May 01, 2020, 09:49:59 pm
content: Hi friends,I am working on an application where there are 2 pcb boards.Board A : Critical task only. Cant be used settings because of the delays involved .EEPROM is on this Board.Board B : Mcu with lcd and switches for storing the user defined variables.Board A is doing a critical task soit can't be usedfor user defined settings .Board B is having lcd and switches so we have to use it for saving the settings. The changes made in this board will have to be reflected to eeprom on other Board A.But these settings have to be transferred to board A so that it can be used for its working......and also we might need to read some physical parameters (unsigned long int , unsigned int type) from Board A to Board B for display on the Lcd of Board B.The Main concern is even if the Board B is busy in doing the settings , Board A operation of operating some critical relays should not be delayed because it cannot wait if we think of putting the settings part on uc A.What is the best approach in this kind of scenario where Communication between 2 mcus is needed without interrupting the critical operation of one of the mcus ,which is on Board A in our case.Any specific protocol: Uart interrupt based , I2C data transfer etc.For writing part:I was also thinking of using a common eeprom for storing settings from Board B , and then reading by Board A when required by some extra pins used as i/o on both sides.For reading Part : I2C or spi read of the variables from Board A to Board B.Please let me know how to proceed in such scenario....

author: deskpro256
author_rank: Contributor
timestamp: May 01, 2020, 11:18:31 pm
content: Hello.Well, there is never one best solutionThere are many variables to what you should use and why.Data transfer speed, amount of data, distance between devices, how many devices would be on the bus and many more.What would the distance between the two boards be? Look into RS485 or CAN.I, personally, haven't used CAN yet, but I have made a project with RS485 and some custom messaging protocol. You can also use MODBUS or other protocols.What I have is a fairly simple system with a Master and (up to 16) Slave devices. The master is always, let's say, 0x1C and the slaves have a 4 bit DIP switch, that the user uses to set their addresses from 0x00 to 0x0F. When the devices turn on, they read their ID and their setting from the EEPROM and start doing their thing.The master also does the same and then starts sending messages to all the devices on the bus one by one. The slaves are always reading the bus if there are messages being sent and if the message has their ID in the messages ID byte, they read the whole message, do the thing according to the command and then reply to the master.A basic protocol would consist of:Start byte | Receiving device address byte | Sender device address byte | Command byte | Your data[some byte lenght] | CRC byte | End byteIf you want to have dynamic length messages, you could also add a byte for the data length, so the receiver knows how much to read next and later calculate the CRC.I'd say use the EEPROM's the devices already have, and send the config/settings over the bus, saves you I/O, board space and money for a part.That should get you started I guess.I'm certain others have some other ideas and experience based opinions on this subject.

author: ajb
author_rank: Super Contributor
timestamp: May 02, 2020, 02:00:16 am
content: "Critical tasks" and user interaction do not necessarily need to be carried out on different MCUs. Tons of applications manage to do both on one part, through non-blocking design and careful management of task and interrupt priority. There are some applications where the critical task is too demanding to also have user interaction on the same MCU core, but turning a couple of relays on and off generally doesn't rise to that level.More sophisticated MCUs are of course better suited to multi-tasking, especially where you will have multiple threads of execution, because you can either use a real RTOS that handles a lot of task switching for you, or you can rely on nestable prioritzed interrupts and system interrupts to manage program flow and also use DMA to free the core up from having to manually shuttle data around.Of course it's impossible to say what the best approach is for you without knowing what, exactly, is "critical" about the things Board A is doing.Anyway, if you really need to minimize the communication overhead Board A needs to deal with I would pick a part and a protocol that will allow Board A to receive messages from Board B with little or no CPU overhead--meaning a peripheral with DMA. That way Board A can just sit there and periodically, between critical tasks, check a DMA flag to see if a complete message has been received from board B, and if so, process it and use DMA to send whatever response is required back to Board B. I'm not sure if I2C will be good for this, that's generally harder to DMA because the slave has to respond at the master's pace (clock stretching aside), but SPI or UART or maybe even CAN should be doable. You might need to plan for Board A's critical tasks to be able to interrupt the processing of a message, depending on how predictable those tasks are and how complicated it is to handle a message, that's generally not a big deal.

author: asmi
author_rank: Super Contributor
timestamp: May 02, 2020, 03:12:04 am
content: Take STM32H7 dual-core MCU and that will give you 2 MCUs in a single package with no routing headaches associated with multiple MCUs. It's got an M7 core good up to 480 MHz, and M4 core up to 240 MHz. I use it in one of my customer's projects and I got to say it's a beast!

author: jackthomson43
author_rank: Contributor
timestamp: May 02, 2020, 06:44:43 am
content: Working on multiplemicrocontrollersin a single project is never a good option. You can try Arduino YUN, it got the microprocessor and microcontroller embedded in a single chip.

author: tggzzz
author_rank: Super Contributor
timestamp: May 02, 2020, 06:57:52 am
content: Look at the XMOS xCORE devices, available from DigiKey.An MCU can contain up to 32 cores and run 4000MIPS, and are designed forhardrealtime embedded work. It is perfectly possibleand simpleto have some cores doing the computation, some the critical i/o, others front panel operation, others communicating over ethernet or USB.When doing all that, the timing isguaranteed by design; the IDE tells you the exact number of clock cycles between here and there. There is no need to run the code andhopeyou have encounted the worst case.I/O timing can be specified down to a specific clock cycle, and i/o clocks can be 250MHz / 4ns and are independent of the core speed.

author: ale500
author_rank: Frequent Contributor
timestamp: May 02, 2020, 07:37:31 am
content: The XCORE chips come in several flavours, with up to 8 (think of SMT) logical processors per core. It executes one opcode in 4 clocks but it interleaves the other logical processor's execution and does not waste any clocks (unless you use less than 4 logical processors, then some cycles are "empty"). Very clever use of resources. You get up to 500 (they say 1000 with some trickery) MIPS per logical core. I used to develop for their earliest generation back in 2008, they had at the time 64 kSRAM. Newer parts have 512 kBytes of shared memory between logical cores. The programming language, a derivative of C, called XC (also supports C, the compiler is gcc based), has extensions for thread start and such things. And very comprehensive multi platform development tools. Worth looking at.You could also, depending on the amount of data go for a Parallax Propeller (1 or 2), they have 8 separated processors sharing some common memory. The Propeller 1 has 32 kBytes shared and gets 20 MIPS per processor, and the Propeller 2 has 512 kBytes and gets something like 180 MIPS per processor. These may be simpler to access, in my opinion very easy to work with (I have only used the Propeller 1). Very nice easy assembly.

author: tggzzz
author_rank: Super Contributor
timestamp: May 02, 2020, 08:30:16 am
content: Quote from: ale500 on May 02, 2020, 07:37:31 amThe XMOS hardware is neat and simple to use, but there have been many processors like that.The single most impressive thing about the XMOS is that thesoftware(the xC language) andtools(the IDE) are closely integrated with the hardware. That is absolutely necessary in order to be able to make full use of the hardware.An demonstration of the power of the system is that it is possible to havesoftwarereceiving and transmitting serial 100Mb/s ethernet streams 32bits at a time,anddecoding packets,whileother cores are doing the application's work. The trick is to be able toguaranteethat no input is missed nor output timings is violated when the other work is being done. N.B. arguably that is a waste of cores, and dedicate silicon is more appropriate. Nonetheless, that demonstration even being possible is impressive.BTW, no indiviual XMOS component is radically new. They are a modern refinement of proven techniques: Transputer, Occam, and Hoare's CSP.QuoteWhen I looked at the Propellor a few years ago, I didn't spot nice i/o nor integrated language nor integrated tools. Parallel hardware is easy; parallel software isn't.

author: ogden
author_rank: Super Contributor
timestamp: May 02, 2020, 09:11:55 am
content: Quote from: jitece on May 01, 2020, 09:49:59 pmIf Board A can safely communicate with Board B then it can safely handle basic user interface as well. You don't need ultra-high performance multicore MCU for that. Shame to Xcore preachers who are offering overkill solution. Generic ARM MCU running at >= 4x higher frequency than existing MCU's could be enough for the job.

author: tggzzz
author_rank: Super Contributor
timestamp: May 02, 2020, 10:24:53 am
content: Quote from: ogden on May 02, 2020, 09:11:55 amAnd what, precisely, make you qualified to know what is necessary and sufficient in this case?What is the justification for your specific advice, given that the OP has givenzeroinformation about:specific timing constraintsprocessors/boardsapplicationpenalty of missing deadlinesFor that matter, do you know what isnecessarytoguaranteethat a deadline will be met? Hint: if measurement is involved, you have lost

author: ogden
author_rank: Super Contributor
timestamp: May 02, 2020, 01:35:13 pm
content: Quote from: tggzzz on May 02, 2020, 10:24:53 amYes you are right, I don't know for sure due to many unknowns here. My advice is as good as yours. What I said was result of guesswork based on few clues provided in the post #1. To state obvious: never take posts in the public forum for a granted

author: nctnico
author_rank: Super Contributor
timestamp: May 02, 2020, 01:58:34 pm
content: Quote from: jitece on May 01, 2020, 09:49:59 pmMy first advice is: don't use 2 MCUs but do everything in one. You can use either an RTOS or interrupts to make sure the critical task gets handled. I see the interrupt controller as a hardware multi-tasking OS. Do time critical things inside an interrupt (including all the processing!) and do other less criticial things in the main thread. By having multiple interrupts and setting priorities you can have several parallel processes. But you'll need to make sure that the CPU has enough processing power and there is enough buffering to handle all processes in time. This needs prototyping / verification.If you do need to use 2 boards then I strongly suggest to use the SCPI text based protocol which is commonly used for test equipment. Currently I'm working on a project which has a Linux SBC for the user interface and a microcontroller for a hard realtime process. Between these 2 there is an RS232 link and the communication goes through the SCPI protocol. Realtime process related settings are in the realtime board, user related settings are in the Linux SBC. But it is a bit of a mess when it comes to the settings and dividing tasks between two platforms has limitations. If you are not careful there has to be a lot of communication between the 2 platforms to stay in sync which also consumes processor time. Also the 2 platforms should handle the situation where one is no longer responding. The latter is the biggest hurdle to overcome when dealing with multi-microcontroller designs and it is often under-estimated.All in all, think about what your problem actually is: you don't know how to make processes work in parallel on a microcontroller, 1 microcontroller doesn't cut it and you are unfamiliar with one which does, 1 microcontroller (even the fastest one) is not fast/good enough or there are regulations saying you must use 2 microcontrollers. Only the last 2 reasons are good to go for a multi-microcontroller system. The others mean you have some learning to do.

author: jitece
author_rank: Newbie
timestamp: May 02, 2020, 03:48:47 pm
content: Well I would share some more details regarding the application.Board A :The mcu used is PIC 24 series running at 40 MHz.It is involved in reading 3 phase AC voltages , READING KWH (ENERGY) FROM 3 phase Load by continuously reading the registers of the energy meter ic within one second based on interrupt, It cant be delayed .i.e the code is polling every second to read energy.Based on the values of 3 phases which can change anytime ,it switches a sequence of 10 relays in 3 -4 seconds interval.It is also running some logic to continuously do the automation part , driving 3 relay boards , reading some 12 input conditions like faults , driving separate 20 relays as output.It is also sending data to (gsm modem with another mcu) for logging to server.Logging Faults in eeprom on this Board A only.I have tried running the user interface (LCD and Switches ) on this board.But the problem is The moment i go into setting menu The relay operation retains the last value as i am not operating it using timer.Also the user interface which is a graphic lcd doesnt respond properly to the switches as there is a lot operating behind using timers and interrupts.So this is the reason why i m planning to add another mcu to drive the glcd and switches to change the settings flawlessly.However this will put another challenge to me of how to read the data from this Board A (data like energy , voltages ,faults to be displayed )from mcu RAM to my new Board B(dedicated Glcd,switches).The data to be transferred to Board Will be around 50 variables of unsigned int type.And there is data to be read also from eeprom settings as well as faulty logs.I hope That clarifies some doubts.The distance between 2 boards is not much .Around 2 feet.

author: oPossum
author_rank: Super Contributor
timestamp: May 02, 2020, 03:53:24 pm
content: Quote from: jitece on May 02, 2020, 03:48:47 pmThere are dual core 16 bit PIC...https://www.microchip.com/design-centers/16-bit/products/dspic33c/dspic33ch

author: nctnico
author_rank: Super Contributor
timestamp: May 02, 2020, 03:55:57 pm
content: Quote from: jitece on May 02, 2020, 03:48:47 pmThis project doesn't need 2 microcontrollers (or dual core). Just use a RTOS to make the tasks run in parallel; that will be much less painful to develop compared to trying to make 2 seperate microcontrollers work together.

author: jitece
author_rank: Newbie
timestamp: May 02, 2020, 04:19:02 pm
content: Quote from: oPossum on May 02, 2020, 03:53:24 pmHi My application requires around 100 pin mcu , Not available in PIC 16 bit series yet.

author: jitece
author_rank: Newbie
timestamp: May 02, 2020, 04:31:59 pm
content: Quote from: nctnico on May 02, 2020, 03:55:57 pmNever used RTOS before . Can you brief some more detail how it works , does it need some new software in case of PIC24 series.

author: nctnico
author_rank: Super Contributor
timestamp: May 02, 2020, 04:42:55 pm
content: You can look here:https://www.freertos.org/portpic24_dspic.htmlYou likely want to use pre-emptive scheduling so the OS divides the CPU time across the tasks. But you will have to do some work yourself as well like using sleep or a (OS provided) timer so tell the RTOS a task doesn't need any processing time right now.Also a good book on using microcontrollers and creating parallel tasks without using an RTOS is this: 'Making embedded systems' written by 'Elecia White'. This book shows an approach using state machines and interrupts to achieve parallel tasks.

author: snarkysparky
author_rank: Frequent Contributor
timestamp: May 02, 2020, 05:14:46 pm
content: Doesn't seem like the real time requirements are that hard. You mention seconds for timing.they key is non blocking code. If possible never pause anywhere. Scan for work needing to be done.Is the LCD code doing so much per call that it is blocking a long time?Try to break the work up over multiple short duration scans of all the code.That said I must confess to having just made a board with 17 microcontrollers on it. One master 16 slaves.Ducks for thrown objects

author: mikerj
author_rank: Super Contributor
timestamp: May 02, 2020, 06:16:23 pm
content: Quote from: jackthomson43 on May 02, 2020, 06:44:43 amNever is a strong word. Occasionally it can be a reasonable, or possibly the only option.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 02, 2020, 06:58:21 pm
content: Quote from: mikerj on May 02, 2020, 06:16:23 pmIndeed.Interesting how in this thread we can read a lot of very strong, one-sided opinions, sprinkled with never's and always's.Actually using two different physical processors, if just for safety concerns (isolating), is a pretty reasonable option. It might take a bit more effort, but it's also much easier to properly ensure tasks are fully isolated. Ensuring that on a single physical processor is of course possible (to some extent), but takes cautious approaches and is often a lot harder to prove correct.And then of course, it all depends on the project, its criticity, other technical requirements, cost requirements, and many more criterions.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: May 02, 2020, 07:30:39 pm
content: Doesn't need multicore or RTOS, just some basic multitasking. There is a lot more to real time techniques than a polling superloop.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: May 03, 2020, 01:26:36 pm
content: What is this "critical task" hookaboora?And why would it mean a single uC would not be able to handle a display as well?There can be many reasons for splitting a design over multiple uC's, but from OP there simply is not enough info to give any reasonable advice.How much work does the uC have to perform?Maybe the simplest 8-bitter is good enough, or he needs a multi GHz device.A simple UART based control is easiest to split with optocouplers, if that is an advantage.Simplest protocol would be a one-way communication. the "critical uC" then sleeps during the "critical stuff" for lower noise in analog stuff, and periodically sends it's results through a opto to "elsewhere".The other uC could for example assume there is no "critical task" ongoing just after it received a message from the "critical task", and then spit out some bytes to change settings or such for the next measurements.The main thing though is that you have to work out some kind of protocol and both sides need to speak the same protocol.If galvanic isolation is not mandatory, then I2C may have an edge over other protols. Every decent implementation of I2C has slew rate limited drivers, which help to keep the noise down.A uC continuously scanning a matrix keyboard, while simultaneously using the ADC is very difficult to get right on Vero Board.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 03, 2020, 01:48:05 pm
content: These threads are always fun; no one has freaking idea aboutanythingthat's needed to solve the problem, yet the opinions are strong. tggzzz's silver bullet is the XMOS, and nctnico's silver bullet is never ever even considering multi-MCU.Task:Turn somerelayson/off without delays.Solution:Use XMOS so that the IDE proves timing to 4ns!!!! You LOSE otherwise!Reality:Relays havemillisecondsof delays and timing jitter!What we really need, is better specification of the problem.For really tight timing in really complex situations, options are FPGA, CPLD, or maybe the XMOS product series if it hits the sweet spot.Sometimes, multi-MCU is a fairly easy, also low-cost solution, but I'd default to not recommending it. You'll see if it makes your life easier instead of making it harder in your particular design.In most cases, any properly selected single MCU does the job. ARM MCUs implement interrupt priorities and pre-empting interrupts; they also implement 12-cycle interrupt latency; running from flash induces slightly variable timing, but it's easy to prove the timing approximately. It's irrelevant whether the "turn off the relay" operation takes 15 or 20 cycles, if the specification requires doing it in less than 20000 cycles. Also the most common use cases tend to be covered by the peripherals, IN HARDWARE, for example cycle-by-cycle current limiting and safety cutoffs in motor control applications.The chances are, the problem in the opening post is easily solved by making the safety critical things happen in a highest-priority interrupt, and the UI code run in the main loop. Make the highest-priority interrupt unmaskable by modifying BASEPRI instead of turning interrupts on/off completely. But yes, this is just guesswork. It may be that XMOS isjustthe tool that the OP happens to need in this completely unspecified problem.Or maybe the OP needs a bicycle, or a potato. We don't know.

author: nctnico
author_rank: Super Contributor
timestamp: May 03, 2020, 04:47:14 pm
content: Quote from: Siwastaja on May 03, 2020, 01:48:05 pmSorry but that is not true.What I have seen many times is that novices tend to use multiple MCUs in order to make a project easier. At least they seem to think they do. The OP seems to be no exception to my observations. In a previous post in this thread I already outlined good and bad reasons to go for a multi-CPU solution (which you also re-iterated).

author: tggzzz
author_rank: Super Contributor
timestamp: May 03, 2020, 07:30:45 pm
content: Quote from: Siwastaja on May 03, 2020, 01:48:05 pmSorry, that is not true.I wrote "look at the XMOS devices" and listed some of their characteristics. I didnotwrite "use the XMOS devices"QuoteSorry, that is not true. See my reply #11.Quote... as is implied in my reply #11.Quote... as is implied in my response #11.

author: ogden
author_rank: Super Contributor
timestamp: May 03, 2020, 09:50:24 pm
content: Quote from: tggzzz on May 03, 2020, 07:30:45 pmTaste your own medicine. I wrote "4x higher freq ARM MCUcould be enoughfor the job", yet you did not hesitate to jump on me with "what makes you qualified" and deadline guarantees "arguments"

author: hans
author_rank: Super Contributor
timestamp: May 04, 2020, 03:34:40 pm
content: Quote from: Siwastaja on May 03, 2020, 01:48:05 pm"prove" "approximately". Tight timing is not real-time. Real-time means that the environment imposes constraints on the processing and timing of the system, where missing a deadline can have serious consequences. This thread started with us guessing what the deadlines really are of this application, and turns out to be rather slow, but other than that it's still rather unspecified. This doesn't really help if you need to define the specifications of a real-time system.In addition, proving that software is indeed never going to miss a deadline, from a digital engineering and/or firmware perspective, is not trivial. I agree with tggzzz that measurement is not a correct way to determine for example WCET's of such systems, where application-oriented 'cached' ARM designs are incredibly hard to design for in this environment. Gaining confidence in hard real-time systems is more than a matter of saying "it can ran fine on the bench".I liked tggzzz comment for it's technical content, not for his comment on "are you qualified".Therefore, recommending a4x higher frequencyARM microcontroller is an odd solution to recommended. How do you know that CPU load is the limitation, and by how much? Many (online) scheduling algorithms cannot approach a high CPU load in real-time systems anyway, for example inrate monotonic schedulers, so I think that the design motive of - it will run fine on a high speed ARM chip - is void: define "fine", and define "high speed".Performing critical tasks in hardware (such as FPGAs) can be beneficial because you can design & verify for latency and timing. But it's also incredibly expensive and complex for many systems.I agree with @nctnico that doing multi-MCU designs for the sake of multi-tasking is a bad reason. If anything, communication and synchronisation between systems is a much harder problem to solve than most people think. Writing software in interrupts with UI code in main() could perhaps be acceptable if there are sufficient CPU cycles left for the interface.

author: tggzzz
author_rank: Super Contributor
timestamp: May 04, 2020, 06:07:51 pm
content: Quote from: hans on May 04, 2020, 03:34:40 pmI agree with your points, including 'I liked tggzzz comment for it's technical content, not for his comment on "are you qualified"'. That was a direct response to ogden's inaccurate "Shame to Xcore preachers who are offering overkill solution"! (reply #10)

author: Siwastaja
author_rank: Super Contributor
timestamp: May 05, 2020, 01:19:50 pm
content: Quote from: hans on May 04, 2020, 03:34:40 pmAnd, anyone can play a critical realtime expert on the Internet. Yet it's unbelievably complex and in many ways, it's far more than just logic timing.Further, deadlines are not specified in clock cycles, but in the SI time unit. Therefore talking about cpu clock cycles is irrelevant (especially when discussing relays). 5 clock cycle interrupt latency on a 4MHz 8-bit CPU similarly cannot be compared to a 12 clock cycle interrupt latency on a 200MHz 32-bit CPU.For safety critical, you need to prove a thing like:"Voltage level exceeding 2.5V on input pin #42 for more than 1 microseconds leads to output at #57 turn below 0.5V in less than 10 microseconds"The design work for ARM and XCORE is equal; after the many steps of verifying analog input protection, and output driver functionality, you end up with the question, how do you prove that the CPU is reliable enough to run the codeat all? The ISR likely is just a line of code that drives '0' to the IO port, and is triggered by an input pin. The XCORE solution, if I understood it correctly, might be a busy loop in one of the cores, looking at the input pin. Both will definitely work in less than 10µs, given that the CPU itself isn't having some kind of failure mode. How do you verifythat?In addition to just timing, robustness against all other sources of errors are equally important. A tightly clocked logic that always does the sequence in fixed amount of clock cycles is equally error prone to all electrical, mechanical etc. sources of errors as is a system which has a branch predictor causing a variability of a few nanoseconds between iterations. By reading tggzzz's marketing speechess on XMOS, you may get an impression that a variable timing caused by a pipelined CPU, flash memory, and possibly caches, is a complete turn-off for getting any safety-critical timing out of the system - you have lost already. This is obviously false because such critical systems are done using such processorsall the time. Another fallacy is that just introducing cycle-predictable timing, everything's made so much easier. In reality, if being cycle accurate was your #1 concern, I'm sure you are not seeing the forest.There are just so many aspects to it so concentrating on such a tiny detail definitely makes you lose the big picture.Yes, you can buy the clock-accurate SystemC or equivalent simulation models for ARM Cortex M7 and actually prove the timing. Safety-critical is so freaking expensive and slow anyway.Or you can do what I did just a few days ago, turn off the dynamic branch prediction, copy the program in ITCM, and verify the timing on an oscillosscope. Yes, I needed cycle-accurate. Yes, it is cycle-accurate. Yes, it works exactly the same every time. No, the system isn't safety critical so if I'm wrong, no one dies; finally, no, safety critical systems almost never rely on being cycle accurate. If it seems that way, please reconsider if the safety really depends on the cycle-accurate timing or if you could do something better to avoid such requirement.QuoteI think I understand what you mean by "application-oriented 'cached'" design.Yet, no one forces you to use ARM Cortex-M series devices in that "application-oriented cached" way. Heck, I've been using them for years and have yet to build such application-oriented thing, I have not even turned the caches on, not even once! Yes, a M7canbe used a bit like a high-performance application processor, and I'm aware some treat them like application processors, but you don't1) have to use M7.2) use the M7 that way; It's still an MCU!The heavily pipelined dual-issue structure with quite advanced dynamic branch prediction means it's more difficult, possibly "insane", to buildcycle-accuratethings on M7 (still I have done that), but that doesn't mean your loop which normally runs in 200ns suddenly would be taking 200us. On a Cortex-A running linux, this is a real problem.If you really need safety, it's all about the big picture, not a detail in whether an instruction takes 1 or 2 cycles. Providing independent watchdog systems is highly recommended; they can be analog, or even mechanical, for example.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 05, 2020, 01:36:43 pm
content: Finally, Xcore likely isn't an "overkill", and if that's what you are familiar with, and are buying anyway, it's likely the most sensible choice to go with (as usual with microcontrollers, "use what you know"). So I'm sure tggzzz would use an XMOS product and solve the problem in no time with it, with great results and minimal time-to-market.I would likely use an STM32 though, and make the project happen similarly quickly. Someone would do it with an 8-bit PIC, equally successfully. (All three examples are capable of safety-critical real-timetiming. Whether the solution is safe in safety-critical environment, is completely up to other factors.)If really,reallysafety-critical, I'm sure all tggzzz's, mine, and the "someone else"'s solution would all fail in vigorous real-world testing and someone would die as a result. We all went for minimized time-to-market using what we are familiar with, after all. That means some mistakes while being comfortable!From the OP's viewpoint though, they very likely have never heard about Xcore processors. With absolutely zero information about the requirements of the application (and some stronghintsthat it's likely not timing-critical; relays!), though, offering such specific product series may send the OP to wrong tracks. Wrong in the sense of wasting time, when we should be discussing about the requirements.ARM MCUs are different; you very likely have used one, or will use one. They are everywhere, they run the world. If you have never heard about them, you can't go on designing microcontroller-based anything without fixing this massive gap.Popularity has a real technical meaning here. Also for design-for-manufacturability, product lifetime, part availability, price.If "the default" does the job just fine, start from there.Your "default" may vary, though. Someone is an FPGA wiz and will use it even if not strictly required. Someone else defaults to XMOS and makes a business around that.

author: tggzzz
author_rank: Super Contributor
timestamp: May 05, 2020, 02:01:07 pm
content: Quote from: Siwastaja on May 05, 2020, 01:19:50 pmIt is inconceivable that the clock rate is unknown; I didn't think that needed saying!It is entirely conceivable that, in most processors, the number of clock cycles is unknown - and variable over a wide range. Even in 486 class processors with their tiny cache and interrupts, asimpletest case could demonstrate a 5:1 timing variation (from memory 30 years ago!). The only mitigation would be to disable all the caches and performance enhancements, thus greatly reducing the performance and wasting a lot of silicon. Better to use that silicon are as an independent core, as in the xCORE devices and Sun's Niagara processors.Hence having a no interrupts and defined clock cycle count is asignificantadvantage.QuoteThere is the concept ofnecessaryandsufficient. Having adefinedmaximum timing is necessary but is not sufficient. That should be obvious.QuoteOK, you slugged the system. That's sufficient for the timing, but wasteful and inelegant.You still had tomeasurethe timing. That is equivalent to inspection, and as engineers used to be taught, "you can't inspect quality into a product".QuoteI've designed and implemented a system where it could kill people - even if it worked as designed and to specificationQuoteNo, it isn't all about the big picture - the details are also critical.

author: tggzzz
author_rank: Super Contributor
timestamp: May 05, 2020, 02:22:06 pm
content: Quote from: Siwastaja on May 05, 2020, 01:36:43 pmNonsense.Every situation is different, and I choose an appropriate tool that gets the entire job done. Sometimes, for a very relaxed specification, that can be an arduino!At HP it was drummed into us that time-to-marketwasn'tthe most important thing. Read thelast paragraphon this page from "The HP Phenomenon"

author: ogden
author_rank: Super Contributor
timestamp: May 05, 2020, 04:00:16 pm
content: Quote from: tggzzz on May 05, 2020, 02:22:06 pmAny specialist low volume, high value product manufacturer will laugh about such "rule". In short: it depends.There are electronics product segments where you copy-paste your "go to MCU" like XCORE into every product because it is cheaper to not change anything. Then there are product segments where you not only find cheapest MCU at the moment, but optimize code out of your mind to squeeze into smallest, thus cheapest model of the cheapest MCU kind.

author: tggzzz
author_rank: Super Contributor
timestamp: May 05, 2020, 04:21:04 pm
content: Quote from: ogden on May 05, 2020, 04:00:16 pmI'm not sure what you mean there.HP was not only a "low volume high value" manufacturer. It also sold intoextremelycost sensitive and time sensitive markets: consider PCs and peripherals.I was chatting to the person in charge of HP's PC division (before he went to be come a Microsoft VP). He explicitly regarded PCs as being like bananas: low margin and if they stayed on the shelf for too long them began to smell.OTOH I know of other HP divisions where they spent large amounts of money to on a hardware accelerators used to simulate ICs. The reasoning was simple: if you can accelerate novel product's development so it hits the market earlier, then you gain a lot of sales over the product lifecycle.Nonetheless,in all those cases not meeting the specification was regarded as unacceptable- and several "Bill and Dave" stories were used to drive home that point.

author: ogden
author_rank: Super Contributor
timestamp: May 05, 2020, 04:28:14 pm
content: Quote from: tggzzz on May 05, 2020, 04:21:04 pmYou can't get what I mean if you don't read (on purpose or not). I said "Anyspecialistlow volume, high value product manufacturer".

author: tggzzz
author_rank: Super Contributor
timestamp: May 05, 2020, 04:39:14 pm
content: Quote from: ogden on May 05, 2020, 04:28:14 pmCould you at least read to the end of my post before commenting? You then choose to make a point, and deliberately snip the context that indicates your point is little more than a strawman argument. That does not reflect well on you.To make that point clear, I reiterate my previous post:Quote from: tggzzz on May 05, 2020, 04:21:04 pm

author: ogden
author_rank: Super Contributor
timestamp: May 05, 2020, 04:52:55 pm
content: When I say "specialist low volume high value manufacturer" - I did not talk about HP. I did mean small shops specializing in custom projects. Such can't afford MCU change and they don't need to because MCU price is irrelevant in such kind of business. Get it now?

author: tggzzz
author_rank: Super Contributor
timestamp: May 05, 2020, 05:02:22 pm
content: Quote from: ogden on May 05, 2020, 04:52:55 pmIn many markets HPwasa "specialist low volume high value manufacturer". I'm sure you are aware of all their test equipment; that tradition is carried on by the other "parts" of HPAK: Agilent now Keysight.Hence it was entirely reasonable to presume your descriptionwasreferring to HP. You have now chosen to, ahem, "clarify" that. OK.

author: ogden
author_rank: Super Contributor
timestamp: May 05, 2020, 05:34:26 pm
content: Quote from: tggzzz on May 05, 2020, 05:02:22 pmWishful thinking. I will let others to decide - "specialist product manufacturer" sounds like HP in following context or rather not, especially knowing that explanation about HP as specialist product manufacturer came from you *after* my post:Quote from: ogden on May 05, 2020, 04:00:16 pm

author: Siwastaja
author_rank: Super Contributor
timestamp: May 07, 2020, 12:39:45 pm
content: Quote from: tggzzz on May 05, 2020, 02:01:07 pmGood guess, but just wrong.The system has a small cycle-accurate bit, but before and after that, it does normal processing, which may be written by others. Branch prediction is turned off for the cycle-accurate bit only, which is mostly unrolled anyway, so no significant performance loss. For this bit, only worst-case performance matters. Can't share the exact details, but let's say, it needs to generate a 3.000MHz signal (with some other details). With branch prediction enabled, it initially generates a 3.000MHz signal for one cycle, then something like 3.050MHz. Nothing is "crippled" by forcing it to generate the desired cycle-accurate signal equal to the worst-case performance. (You could achieve the same result keeping the branch predictor enabled; but I feel it's moreelegantto turn off the error source, than to "trick" it, even if "tricking" could be proved to work consistently.)After the small cycle-accurate bit has been ran, all CPU features are back on. Now a M7 core is a lot more capable, performance-wise, than an XMOS core, thanks to strong pipelining, dual-issue, branch prediction, caches, and so on. Single-thread performance helps software development; latter processing can be easily written in C, without taking extra measures on paralleling the code (parallel data processing isn't always trivial!), which would be necessary for a multicore system where each core is comparatively inefficient.Because most of the code is where M7 shines - general purpose (not constrained by worst-case timing requirements; average case is important) data processing and user interfaces - and only a tiny part is cycle-accurate, it makes sense to choose M7 and "force" it to do the cycle-accurate part as well, even though it's extra work. M7 is low-cost, as well.Youcoulddo it otherwise - choose something that's better suited for cycle-accurate work, but less suited for available developers to write efficient UI and data processing code on something they are familiar with. Or, you could build a multi-chip solution. All of these are more expensive, and the end result is not magically any better.QuoteNice try, but you are just plain wrong.What the XMOS IDE is doing, it is simulating the internal operations of the CPU, and reporting the result to the user.In digital logic, simulating (with proper simulation models) and measuring the number of clock cycles provide equivalent results. With improper simulation models, the actual hardware isright.Buying the Cortex-M7 simulation model does exactly the same - the only difference, it's expensive, and likely has a more difficult user interface (like having to write your own SystemC wrapper).Running the code on Cortex-M7 and measuring it does the same, though. It's, after all, implementing the actual digital logic. The operation runtime can be measured, and it will match the cycle-accurate simulation model.So, cycle-accurate simulation is onlyconvenient. It's fundamentally not magically more "accurate" than running the actual digital logic. It's actually the opposite: the simulation model must contain zero bugs. Measuring the actual device provides the correct result, in case the simulation model has any problem in it.The error you make is, you seem to think that measuring the number of clock cycles a digital system runs in, is somehow equivalent to measuring a voltage on a prototype of a single unit of voltage reference; or measuring a length of a single piece of cut metal. This is not true.You arenotmeasuring a system with random error terms; you are measuring a circuit consisting of known digital logic, and if you can enumerate the possible sources of variation and show they do not exist, you have a guaranteed number of cycles.But I'm sure it's wayeasierto do on XMOS, though. I'm sure they have put a lot of thought into providing an easy-to-use, yet accurate simulation models integrated in the IDE. And, most importantly, they have "crippled" the CPU performance by deliberately not including modern-day CPU optimizations that would increase the average processing performance, with the cost of variability in timing.If you do timing-accurate work in a modern complex processor like an M7 MCU, you need toknowwhat those timing-invariable elements are, and know how to either disable them (note: it does not necessarily cripple the performance, because they can beselectivelydisabled; like caches on certain memory areas, or just turning things on/off periodically), or how to calculate for the worst-case timing. Latter is more challenging, but completely possible.I'm sure that if you havea lotof cycle-accurate work to do, Xcore is likely orders of magnitude easier to work with than a Cortex-M7. And I would love to work with one, if someone would pay me for doing that. For my own projects, I'm defaulting to the most commonly available, most easily second-sourcable parts whenever it's possible, and only resort to specialistic products with their special best-in-class features, when I absolutely must.

author: tggzzz
author_rank: Super Contributor
timestamp: May 07, 2020, 01:30:21 pm
content: Quote from: Siwastaja on May 07, 2020, 12:39:45 pmSo, if I understand you, there is a small bit which has tight timing, then a lot with little timing constraint. And I guess the tight timing section has to be repeated starting at a precise instant. If that's the case then how much spare capacity do you have to allow in order for the tight timing section to restart at the right instant?That's a rather peculiar workload compared with a typical real time workload where the problem is ensuring the many competing timing requirements are met.QuoteNo. The in the XMOS IDE instructions are not simulated, they arecounted. That's a very big difference.The nearest to simulation is that youinspectan instruction to see if it is a branch instruction, and then "take"bothdirections and include both the counts in theanalysis.QuoteI don't understand the point you are trying to make.In this context simulation+measurement is equivalent to execution+measurement; that seems blindingly obvious and is the crux of the limitations. Given the inherent variability in execution times in a system with caches and prediction and interrupts, that's all you can do. Just hope you have stumbled on the worst case execution times. That is inelegant, and uninteresting "business as normal".The XMOS system removes the variability by design, plus keeps the aggregate throughput high by other means. That's interesting and novel.Sun managed to do the same in its Niagara processors, but that was in the server market.

author: nctnico
author_rank: Super Contributor
timestamp: May 07, 2020, 01:58:16 pm
content: I still don't get why you'd need cycle accurate timing in software execution on a modern high speed microcontroller. Usually there are many tasks and modern hardware peripherals are perfectly capable of providing accurate (ns level) timing using timers & DMA to make things happen. When I need accurate timing I choose a microcontroller which has peripherals which can do the accurate timing in hardware. The software then needs to make sure to fill buffers / change parameters in time but the timing requirements for such actions are way more relaxed.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 07, 2020, 02:05:15 pm
content: Quote from: nctnico on May 07, 2020, 01:58:16 pmSpot on - cycle accurate code is a rare special case.

author: tggzzz
author_rank: Super Contributor
timestamp: May 07, 2020, 02:39:02 pm
content: Quote from: nctnico on May 07, 2020, 01:58:16 pmYou don't need cycle accurate timing per se. It is the means to the benefit: see below."High speed" are irrelevant adjectives, unless you add a statement "...relative to...".QuoteAnd that's the crux of the problem:provingthat the softwarewilldo that!Forhardrealtime systems you need to know the worst case performance. That means you must know the worst case execution time betweenhereandthere. The question is how you achieve that. The problem is the unpredictability that caches and predictorsmust by designintroduce - they only increase performanceon average, but we need worst case.The first approach is to measure and hope you happen to have spotted the worst case instruction path and pessimal data-dependent timing. Yuck.The second approach is to turn off all caches and predictors, then measure and then hope you have exercised the worst case instruction path. The consequence is the processor is much slower, so why didn't you use a lower cost processor in the first place.The third approach is to overspecify and underutilise a processor. That's fine (albeit wasteful) except when your problem is pushing the limits of the technology (where I normally operate), or when certification requires proof (where I have operated).The fourth approach is to use dedicated hardware without a processor. That's fine, but expensive.The fifth is toknow in advanceexactly how long a processorwilltake to execute a task, and that is best achieved by counting instructions and having zero data-dependent timing. That implies a relatively low performance core, as in the second approach. Then the question is how to "rescue" yourself from "lost" performance, and that can be achieved by multiicore parallelism. That raises the problems of inter-core comms and multi-core programming, and that's where xC and xCORE are unique.If you have low-end requirements, then you can throw technology at the problem and the solution will be adequate (if inelegant).Inallthe real-time systems I've developed over the decades, I'vealwaysbeen pushing the limits of what processors can achieve. The discrete hardware I've designed into such systems has been theminimumnecessary to bridge between what the processor canand willachieve, and what the system requires.But then I've never used a processor to blink a LEDYMMV

author: Siwastaja
author_rank: Super Contributor
timestamp: May 07, 2020, 04:18:32 pm
content: Quote from: tggzzz on May 07, 2020, 02:39:02 pmBingo, and improving processing performance by utilizing multicore parallelism is notoriously hard, and full of synchronization traps - I'm sure you know this, and I'm sure you can't be claiming that the XMOS IDE would be the silver-bullet to solve such vast problem field once and for all.Single-core performance matters. Especially if the algorithm is non-trivial to parallelize, yet you want simplicity and predictability, which is just what is needed in embedded systems.You talk about interrupts like they are some kind of burden or error source. Actually they aren't, they make your life easier. You get easy timing guarantees with interrupts! Just look at the worst-case interrupt latency, which is easy to calculate (even if you need to take flash fetch latency into account), and look at the priorities, higher-priority interrupt pre-empts lower priority one. No need for guesswork.As I see it, multi-core parallelism as implemented by XMOS would really shine doing independent IO interfaces that no classic hardwired peripheral exist for (such cases are fairly rare, though, but I can see you could replace a more costly FPGA with this, in some cases); or implementeasily parallizablealgorithms.Though, to be fair, my earlier example with cycle-accurate thing on M7, by the way, would be perfectly well handled by standard MCU peripherals,cycle accurateand no CPU interaction at all, if ST Microelectronics could get their shit together and design MCU peripherals thatwork.But when ST fails to provide an SPI interface which can access the most common types of SPI devices, I need to nearly bit-bang, and then I indeedcoulduse XMOS to do that part a bit more easily. But I still choose to do it with M7 with a bit more complexity. The end-result pays off, still, because I can leverage all the processing power, popularity, part availability and price of the ARM ecosystem. If I change to a different MCU, the chances are the SPI and DMA "just work" there and I can ditch that (small) part of the code, but if not, the cycle accurate code will be equally cycle accurate on the other manufacturer's M7!QuoteYet strangely, I have very similar goals. One of my goals is also to be able to depend on very common, second-sourceable, popular parts and take them to their limits. Minimizing BOM line count and BOM cost, making the MCU do whatever it can. Implement a DC/DC controller with software to save a $2 DC/DC controller IC when the MCU is thereanywayfor other tasks. For microcontroller cores, I default to ARM very much thank you, but that's only for highly practical reasons.I'm sure a 32-core design will keep most of the cores just waiting most of the time*, though. Which I'm completely OK with, I just don't understand what youactuallymean by "bridging between what the processor can and will achieve", but clearly it isn't efficient usage of the resources. Which is interesting, because you seem to be implying repeatedly that an "overperformance" ARM is a problem, but an "over-cored" XMOS somehow isn't.*) Unless it's a completely trivial small piece implementing a continuous, fully parallelizable data processing algorithm.QuoteRelative to the requirements, obviously...

author: tggzzz
author_rank: Super Contributor
timestamp: May 07, 2020, 05:16:25 pm
content: Quote from: Siwastaja on May 07, 2020, 04:18:32 pmThere are no silver bullets.Hardware is inherently parallel, but people don't complain about it being "notoriously hard" and "full of synchronisation traps". Why not? A signifcant part of that is because the design patterns and tools have evolved to deal with it and make best use of it. Such design patterns plus tools are notoriously absent from software, especially at the embedded level where ad-hoc "seems to work" hacks are normal.The CSP/xC/xCORE mentality, design patterns and tools are the besthardware/software plus tools systemavailable, especially in the hard realtime arena. If you know of alternatives where the hardware+software+toolset are all tied together as a coherent whole, please let us know.QuoteInterrupts can, with care and attention, make a few easy timing guarantees. But they bring many problems, especially where there are many interrupts with different priorities, and many tasks with many priorities, and schedulers. Unless your processors can be underutilised, I'm sure you have been bitten by such.If you think about it, interrupts plus a single core are no more than a workaround for not having multiple independent cores.QuoteBingo! Except...My experience in the embedded world is that "classic hardwired peripherals" either don't exist or are limited to clocked/strobed/SERDES interfaces. xCORE has all of those easily accessible by software. Some processors have dedicated silicon for USB and Ethernet peripherals, even though that can be done in xC.Actually I think they shine with ad-hoc algorithms that are independent butaren'teasily parallelisable. Algorithms that are easily parallelisable tend to imply many many threads of control, and the XMOS cores are a strictly limited resource.QuoteI can't comment on that, but I wasverypleasantly surprised at how easy it was to setup and use the xCORE i/o ports, plus I didn't spot any errata.None of that is inherent in the xCORE/xC system, but it might be an property that emerges from having people that (appear to) understand both hardware and software and how they need to work together in embedded realtime systems.In most places the hardware and software teams occasionally throw things over a partition, and assume that the other people will solve what they haven't got right.QuoteThe breadth of the ARM ecosystem is definitely and advantage. In spite of that XMOS appears to be successful and growing; they must havesome"secret sauce"QuoteThose are valid pragmatic reasons. But they don't detract from the xC/xCORE ecosystem's value.QuoteA 32 core MCU doesn't have 32 physical coresIt has 4 "intel style" cores, each of which implements 8 "SMT threads" - the silicon cost is merely duplicated register set and multiplexers.Sun did exactly the same with their Niagara server chips, where each core's cycle time was the same as the memory's, thus removing the need for out-of-order processing and some levels of cache. Superb for "embarassingly parallel" workloads; I used that to great effect with telecom server applications.

author: tggzzz
author_rank: Super Contributor
timestamp: May 07, 2020, 05:30:27 pm
content: Looks like an edit crossed in the ætherQuote from: Siwastaja on May 07, 2020, 04:18:32 pmHaving "excessively" underutilised MCU doesn't actuallysolvethe hard realtime problem - it merely makes it less likely the problem will be noticed. Having too many cores is merely inefficient - and once you realise how 8 cores are implemented in one tile, you understand that the inefficiency penalty in terms of silicon areaand/orpower is small.QuoteActually, that's not the case. "Fully parallelisable" tends to imply many parallel operations, and the xCORE cores are a strictly limited resource. as in "there are only three numbers: zero, one, and many".

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 07, 2020, 06:53:03 pm
content: Quote from: tggzzz on May 07, 2020, 05:16:25 pmI suppose you're talking about the UltraSPARC T1:https://en.wikipedia.org/wiki/UltraSPARC_T1

author: tggzzz
author_rank: Super Contributor
timestamp: May 07, 2020, 07:35:12 pm
content: Quote from: SiliconWizard on May 07, 2020, 06:53:03 pmExactly.They sounded good on paper, and people in two companies were surprised at the soft realtime performance my Java application achieved. But then event driven telecoms applications have always been embarrassingly parallel.

author: thm_w
author_rank: Super Contributor
timestamp: May 07, 2020, 11:37:20 pm
content: Quote from: Siwastaja on May 07, 2020, 04:18:32 pmSecond sourceable outside the of the MCU itself right?

author: Siwastaja
author_rank: Super Contributor
timestamp: May 08, 2020, 06:20:45 am
content: Quote from: thm_w on May 07, 2020, 11:37:20 pmNo, I mean, if the shit really hits fan so that an STM32 Cortex-M7 MCU isn't available (which is, of course, quite remote possibility, given the designer has done due diligence and not picked a NRND STM32 part), it isn'tdisastrousfor the project to change to an NXP Cortex-M7 part instead. There will be minor PCB layout changes, and maybe 1-5% of the codebase (for a typical say 10000 LoC embedded project) changes, but it's far from a complete redo of the project. This is because many things keep the same, including the ARM core and all software development tools. The MCU peripherals are different, but often notthat muchdifferent (again, similar design philosophy is seen in most ARM microcontrollers), and for the more complex peripherals, you had them hopefully abstracted behind low-level drivers. You write some low-level peripheral access parts again.As a contrast, if the design relies on the XCORE philosophy, there is no competition, which seems good for their business, but you have no options but to redesign from scratch if, for any reason, XCORE becomes unusable. Not that this is a high probability, just sayin'.What I really want to see is the XCORE philosophy becoming a more standard way of thinking. This includes harsh competition. As long as it's a special snowflake, I'm only interested when I absolutely must use it and have no other options. I think many designers think the same way, and see the appeal of getting the job done using the most industry-standard ways available.

author: tggzzz
author_rank: Super Contributor
timestamp: May 08, 2020, 06:56:23 am
content: Quote from: Siwastaja on May 08, 2020, 06:20:45 amYes indeed, except I also want to see improvements in the multicore programming arena.The main theoretical abstraction underlying Occam/Transputer and cC/xCORE is Hoare's CSP from the mid 70s. Some of those concepts appear in other places, e.g. Go and Rust both use CSP/xC style channels for comms.

author: klmbk
author_rank: Contributor
timestamp: May 08, 2020, 08:03:22 pm
content: A somewhat related question, though at its core it might be more of an analog question:Suppose I want to drive multiple DAC chips over RS-485, with one twisted pair (or differential pair trace) per DAC chip coming out of a bigger MCU or CPU, the sample data is packetized and is unpacked and buffered on the receiving end by a small MCUs before the DAC, and clocked out of the MCUs into the DACs by the DAC clock (shared among all DACs.)Suppose that data synchronization just works all perfect, but optimizing for EMI is very important. Question is, should I care about synchronizing the main clocks of the small MCUs around the DACs instead of just letting them run freely on their own internal clocks? Would that be of any benefit for EMI?

author: Siwastaja
author_rank: Super Contributor
timestamp: May 08, 2020, 08:14:49 pm
content: Quote from: klmbk on May 08, 2020, 08:03:22 pmFree-running should yield better EMI performance, because now the clocks (and the related power supply spikes, and synchronous DAC output updates) and their harmonics are at a bit different frequencies (spread spectrum), and thus, the peaks are lower. And the peaks are being measured at the lab.However, in theory, you could get unlucky and they might all accidentally run at close enough frequencies, in sync, so that the peaks are there after all. Syncing them to begin with would make the result more consistent between units and environmental variations.Running all those clock lines, though, would be a huge possible source of extra radiation.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 09, 2020, 01:24:57 pm
content: Quote from: Siwastaja on May 08, 2020, 08:14:49 pmYeah. If you need that for sync reasons, well, that's one thing. But that sure could be only worse as far as EMI is concerned.

author: tggzzz
author_rank: Super Contributor
timestamp: May 09, 2020, 01:37:18 pm
content: Quote from: klmbk on May 08, 2020, 08:03:22 pmYou should consider starting a thread about that. Benefits:it won't be buried and a "distraction" in this threadmore people will see it, so you have a better chance of getting a solid answerother people can find it in the future, either by browsing or searchingWhat's not to like about thatI would suggest this subforum:https://www.eevblog.com/forum/projects/but EMI/EMC might be found inhttps://www.eevblog.com/forum/rf-microwave/Have a look and make your choice - butdon't double post in both places!

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 09, 2020, 02:13:49 pm
content: Quote from: Siwastaja on May 08, 2020, 06:20:45 amYes, that was also my point which I already stated a while ago... and one of the main reasons I never used xCore in any project so far.That's a shame though, as the architecture makes writing real-time software easier, and MUCH easier to validate IMO. That sure would be interesting to see similar architectures appearing in more common MCUs/CPUs. As said above, it's not that much that you can write cycle-accurate software (although it can be a benefit in some cases, in which you may otherwise have to take an hybrid MCU-FPGA approach, or FPGA only with a soft core), but most of all that you can write provably correct software (at least timing-wise.)

author: tggzzz
author_rank: Super Contributor
timestamp: May 09, 2020, 02:27:20 pm
content: Quote from: SiliconWizard on May 09, 2020, 02:13:49 pmYes indeed. Propagation of the concepts and improvement of the concepts will benefit all.For that to happen people have to realise that C + single-core MCU was fine in the 80s, but is creaking at the seams now and definitely won't be sufficient in the future. They need to realise that there arealreadyalternatives that are better in some respects.Knowing what one toolcando better often alert you to the deficiencies ofothertools. when returning to this area after a quarter of a century, I washorrifiedat how little fundamentally new things I needed to learn. Smaller, cheaper, faster != new and different

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 09, 2020, 02:34:01 pm
content: Yeah, no breakthrough really. Yes parts (and dev tools) are cheaper, have more memory, are faster (sometimes hugely), and draw less power. That's not too shabby, but those are more incremental changes than true innovations.

author: nctnico
author_rank: Super Contributor
timestamp: May 10, 2020, 10:02:15 am
content: Quote from: SiliconWizard on May 09, 2020, 02:13:49 pmThere are many multi-core microcontrollers on the market today. Also SoCs tend to come with hardware virtualisation and microcontrollers built in nowadays. That way you can physically seperate generic and hard realtime tasks. At some point throwing more processors at a task even becomes counter productive because you also have to prove the system as a whole meets the realtime & safety requirements.

author: tggzzz
author_rank: Super Contributor
timestamp: May 10, 2020, 11:03:02 am
content: Quote from: SiliconWizard on May 09, 2020, 02:34:01 pmBack in 1981 I was cross-compiling C on a Unix box to run via an in-circuit emulator in a 8-bit processor. Fast forward 35 years, and I found myself doingexactly the same.The only difference is that in 1981 the Unix box was the size of an American fridge, the Unix was a Microsoft product(!), and the setup would have cost a couple of year salary. Now it costs a couple of hours salary and fits on a desk.Since there was no change, it didn't take me long to get up to speedMind you, even with the XMOS setup, that only took one day before I was running my software against external inputs, and it was working as expected at full rate. Stunningly easy.By comparison, programming an atmega328 at the bare silicon level took much longer to get right, even though there were no fundamental surprises for me.Basically with the atmega328 you have to fiddle with lots of bitmasks and registers, and all those are coupled/merged together in whatever way was convenient for the silicon guys. OTOH the xCORE experience is three easy orthorgonal statements to define a port's width, type (clocked, strobed, SERDES etc), clock rate. Job done

author: nctnico
author_rank: Super Contributor
timestamp: May 10, 2020, 01:33:45 pm
content: Quote from: tggzzz on May 10, 2020, 11:03:02 amBut now you are comparing the typical low end Atmel crap to a properly engineered chip. This has nothing to do with using one or multiple cores.

author: ehughes
author_rank: Frequent Contributor
timestamp: May 11, 2020, 02:19:50 pm
content: I always try to keep things in a single CPU if I can. This project does not sound like it would benefit from multiple CPUs I found that I need something super tight, software is the wrong place to solve the problem. My observation over the years is that the majortity of problems that are considered "hard real time" or "timing critical" really aren't once you figure out what really matters.There are a couple projects where we have a verify dedicated function that is programmed into a small MCU and is used across many designs. The firmware is locked down and we can essentially treat it as a fixed function chip. You usually don't know you need this until you have reused it several times.Usually I go in this order:1. Try to get a peripheral or a combination of them to solve the problem.2. Find some sort of discrete solution that solves the problem.3. Use an FPGA/CPLDI evaluated XMOS several times. The architecture is academically interesting but burning CPU cycles to bitbang everything was over the top. I know they added some hard peripherals in later series but just power consumption was over the top to solve pretty simple problems. I have not found a case where a critical timing problem wouldn't be better solved with an FPGA, FPGA+CPU , or some combination with dedicated logic.I personally like the idea of using standard languages and tools (Verilog, etc) to design critical logic. It is so much easier to write 100% covereage tests.I think they carved out a niche in Audio which seemed like an OK fit. The only argument of an XMOS might be cost but that never is anywhere near the top of priorities when you have a timing critical application. Your engineering/test/compliance costs dwarf chip cost is most cases.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 11, 2020, 03:15:47 pm
content: Quote from: nctnico on May 10, 2020, 10:02:15 amI think you just missed the point we were just discussing above (with xCore as an example). Or maybe I missed the point you were just trying to make here.Multi-core MCUs are just traditional architectured MCUs with a bunch of classic cores, and yes, properly using them comes with difficulties and limitations, and that's where alternative multi-core architectures could come in handy.

author: tggzzz
author_rank: Super Contributor
timestamp: May 11, 2020, 03:23:21 pm
content: Quote from: ehughes on May 11, 2020, 02:19:50 pmYou don't bitbang everything. The port options include all the standard classes (except for UART) up to and including 250Mb/s SERDES.QuoteYou don't waste power. If a core is waiting to do something, it sleeps and doesn't use any power. Waiting includes waiting for any/all of a message, i/o, timeout or until a particular input is == or != a specified value. The latter allows "idle signals" to be ignored.QuoteThe FPGA plus tightly coupled CPU (e.g. the Zynq devices) are powerful and sufficient in many cases. The development ecosystem and toolset has a very steep learning curve, much more so than the XMOS toolset.If timing was only a hardware issue, I would completely agree.Inhardrealtime systems the issue is proving the hardware+software system timing constraints are met. That is much more difficult, and XMOS is the only game in town there. No, "suck-t-and-see-and-hope measurements" aren't sufficient.Within some obvious limitiations, the XMOS ecosystem is also the best story w.r.t. multicore/multasking systems.

author: nctnico
author_rank: Super Contributor
timestamp: May 11, 2020, 07:51:31 pm
content: Quote from: SiliconWizard on May 11, 2020, 03:15:47 pmI was responding to your statementwriting real-time software easier, and MUCH easier to validate IMO.. On one hand having isolated tasks seems easier but also those isolated tasks will need to work together. If you have 20 cores (just a number) executing 20 different tasks then it will be difficult to make sure these tasks are executed in the right order. Alternatively if you use a scheduler which executes each task in a fixed order then it is much easier to prove that the tasks don't interfere in an unpredictable way. Just to outline a black & white situation without any timing requirements.I have quite a few multi-processor projects under my belt and getting & keeping the processes to execute in the correct order is much harder then it looks at first sight. Dealing with error situations and recovering is the hardest part.This make me wonder that if I where to use a multi-core system with many (>10) cores I might want to aim for executing a single task in parallel.

author: tggzzz
author_rank: Super Contributor
timestamp: May 11, 2020, 08:56:26 pm
content: Quote from: nctnico on May 11, 2020, 07:51:31 pmYes, it isn't easy - even though it looks easy until you try it!QuoteI'm unconvinced that would make anything easier. Different or transformed, yes - but that's not necessarily easier.One theoretical advantage of CSP is that it has a decent mathematical pedigree, and that it can be analysed mathematically. Whether that translates into a practical advantage is a different matter.Of course there's nothing preventing multiple CSP processes being multiplexed onto a single control flow a.k.a. thread. Hence my comment "not necessarily easier".