Re: Getting started with bare-board development

[antispam@math.uni.wroc.pl]

Adam Jensen <hanzer@riseup.net> wrote:
> On 11/14/2016 08:14 PM, antispam@math.uni.wroc.pl wrote:
> > Just to address this point: real time embedded systems are frequently
> > done with single chip microcontrollers.  Microcontroller contains
> > combinatorial logic (processor core, digital peripherials),
> 
> https://en.wikipedia.org/wiki/Combinational_logic
> https://en.wikipedia.org/wiki/Combinatory_logic
> 
> > SRAM, flash and analog parts.  Having all this on single chip
> > brings substantial advantages.  But the drawback is that
> > various parts have conflicting manufacturing requirements.
> > So no part is as good as "pure" chip could be.  In particular,
> 
> I'm inclined towards an approach that involves an FPGA such that signal
> and control processing could take place in custom logic. Given that, it
> might make sense [for me and my applications] to use a soft processor
> core like the LEON3. With this approach, the peripheral components,
> being implemented in the FPGA, could be selected and tuned specifically
> for the application.

Yes, that is valid approach.  But there are also limitations.
IIUC FPGA-s have no analog parts.  Frequently (always???) flash
is external.  Prices seem to be high.  And soft processors
seem to have rather unimpressive parameters -- they are good
if you have modes need for processor power and have some
free space in FPGA that you need for other reasons.  But
if all functions could be done by existing hard processor,
then soft processor just adds cost.

> > microcontroller at lower end may have as little as 32 bytes
> > of RAM and at high end rarely go into megabyte range.
> > Basically, if you need more RAM you need to go into multi-chip
> > design with separate memory chip.  Then you can easily get
> > say 256 MB, but latency of external memory is much larger
> > than internal SRAM.  So while you may have plenty of
> > external memory program using it will run slower.  Worse,
> > high latency means that it is hard to give assurance
> > of real time behaviour.
> 
> Slow doesn't mean less deterministic, right?

Well, smallest and slowest MCU-s tend to be the most
deterministic ones.  But common DRAM timing means that you
need processor with clock significantly faster than DRAM
latency.  So usualy DRAM is used together with caches
and determinism iss lost: mostly access is quite fast
but sometimes gets much slower.

> > STM32F4-Discovery contains relatively large microcontoller.
> > Nucleo boards have several versions containg both middle
> > sized and large microcontollers.
> > 
> > Note that flash is typically much larger than RAM, so
> > in fact you can have quite a lot functionalty inside
> > a single chip microcontroller.  When talking about
> > critical system I would say that modern microcontollers
> > give you quite a lot of space where bugs can hide.
> > In other words, to limit effort spent on validating
> > code you may wish to limit size of your system so
> > that in effect it fits in small device.
> 
> Do you have any estimates and/or examples of how much flash
> and RAM are required/used for various run-time profiles and
> programs of varying complexity?

ATM I have examples in C.  On STM Cortex-M0 (STM32F030) "do nothing"
bare-bone program is about 392 bytes of flash and uses single
word (4 bytes) of stack (and no RAM otherwise) -- that basically measures
fixed overhead payed by all programs.  Blinking LED program
using 552 bytes of flash (and no RAM beside stack) when using
defult clock frequency, 1028 bytes flash and 8 bytes of RAM
when using a library to configure processor clock to 48 MHz
and 684 bytes flash when clock is configured via port access.
With extra 100 bytes of flash one gets various simple gadgets
that flash LED-s in response to button presses.  One needs
about 1000 bytes of flash to handle few digits LED display
using funky serial protocol for communication (+ 1000 bytes
of common overhead/setup).  About 400 bytes for interrupt
driven serial transmission.  About 1000 bytes to setup and
use ADC.  About 650 bytes to drive monochrome graphic LCD
via polling SPI interface, about 900 the same using DMA
chanell (that uses about 149 bytes of RAM, including
84 byte buffer for DMA transfer).  PetitFS (FAT filesystem
used on SD cards) is about 1500 bytes of flash.  RAM usage
of PetitFS is normally dominated by two 512 byte sector
buffers.  TinyOS (tasks with preemptive scheduler, ques
and semaphores -- IIUC this is more or less what Ravenscar
offers) is slightly less than 8 kB of flash.
Libmaple library (Arduino style library which contains
drivers for most devices in STM32F103) is about 20 kB.
Several devices (like fast battery charger with modes
for various kinds of batteris and a lot of user settings)
use STM32F103C8 which is 72 MHz Cortex-M3 with 20 kB of RAM
and 64kB of flash.  IIRC to send and receive Enhernet
packet via extenal Ethernet chip one need about 4 kB
of code.  To implement "full" TCP/IP stack one needs
about 80kB of code (and probaly at least 40 kB of
RAM for buffering).  If you want to add fancy GUI to
embedded system you may need copy of the screen in RAM,
which will take something between tens of kilobyte and
megabytes.  If you are building sampling osciloscope,
then you need sample buffer -- while 10-20 kB may
work you can offer extra features with large buffers
(say hundreds of megbytes or more).

Much depends on problem and strategy used for solution.  For
example, for simple messaging 16 byte serial buffer may be
enough.  OTOH to transfer large amounts of data concurrently
with higher priority tasks one may want bigger buffers, say
2kB.  If you have 8 serial ports and allocate 2kB buffer
for each serial port (which naive serial library may do)
you get 16 kB, which may be large portion of available
RAM (such thing happened on MCU with 32 kB of RAM and
8 serial ports).  On PC-s there is tendency to use very
large buffers to minimize cost of context switches.
MCU-s tend to have smaller context and fast context swiches,
so buffers may be smaller.  Also, control messages
frequently are small.

-- 
                              Waldek Hebisch