-1

Say I'm developing firmware for a smart thermostat in someone's home. The current implementation is a multi threaded solution running on a single core processor (lets just throw out Cortex-M since that's what I'm familiar with) and I'm using some off the shelf RTOS.

If I take that project and move/port it over to a dual/multi core processor, how does that work? Do I just tell the RTOS which threads should run on each core and the RTOS manages it all from there? Is there a certain amount of refactoring that needs to be done on each thread so that it works more efficiently in a multi core environment? Or does the RTOS just take whatever thread is in the READY state and run that task on a core with free time available?

Tom Harrington
  • 69,312
  • 10
  • 146
  • 170
PC load letter
  • 1
  • 1
    Unanswerable, I'd say. Certainly, it fully depends on the support and capabilities of the scheduler ("RTOS") you use. Have you looked into the documentation for the "RTOSs" you would consider? – JimmyB Dec 06 '16 at 16:10
  • 1
    Besides, a "smart thermostat" application does not sound like it could justify the use of a multi-core in the first place. – JimmyB Dec 06 '16 at 16:23
  • @JimmyB Given the price and availability of multi-core systems-on-chip, I don't think that there's much in the way of "justification" needed. You can get one for $10 in quantity, DRAM included. Think of the thermostat running on a platform like Raspberry Pi. – Kuba hasn't forgotten Monica Dec 06 '16 at 17:43
  • The smart thermostat was just an example to ask my question. My assumption is that it's handled by the scheduler. I am just trying to figure out how the tasking on multiple cores works. I realize it's probably RTOS dependent, but I thought there may be some sort of common practice. – PC load letter Dec 06 '16 at 19:15
  • @KubaOber I'd guess that you can easily get the thermostat job done with a controller in the US$1-2 range. Generally, I fail to see the need for powerful CPUs or SoCs for many of the embedded applications. A thermostat is an excellent example for that. My advice is hence to first get your code straight, use the HW peripherals available (avoid software PWM &c.), move from polling to interrupt-driven, never use busy waiting, maybe reduce the number of floating-points to what you actually need. You may gain a lot of free CPU time. (And please, don't use an Arduino.) – JimmyB Dec 07 '16 at 12:06

1 Answers1

0

Generally speaking, the fact that you're running on a multi-core machine shouldn't matter. It's up for the OS to schedule threads to available cores. Of course your RTOS needs to support the multi-core platform!

There's a gotcha: if your code doesn't handle concurrency properly, and especially if it doesn't handle memory barriers properly, you might run into bugs that were hidden by the fact that it all ran serially on one core. Once you toss a second core into the mix, any such bugs tend to surface, but usually they do it first during an important demo or after release. So design your code so that it will be concurrency-bug-free by construction.

Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313