ARM Cortex M3 newbie questions

Hi David,

On 5/7/2012 6:37 AM, David Brown wrote:
> On 07/05/2012 15:27, Stephen Pelc wrote:
>> On Sun, 06 May 2012 11:35:30 -0700, Don Y<not@my.name> wrote:
>>
>>> Biggest problem (IM) with network stacks in an embedded system
>>> is remembering they were designed for *benign* environments.
>>> I.e., they try to handle the consequences of (unfortunate)
>>> hardware and transient faults -- not deliberate attacks!
>>
>> Oh, really? We have clients with instruments on a raw
>> internet feed - no firewall, nothing. The instruments
>> were attacked within 30 seconds of first power up.
>>
>> Now our stack survives this environment. But then,
>> we charge for our stack.
>> http://www.mpeforth.com/powernet.htm
>
> There is also the point that in many cases, you /have/ a benign
> environment. It is very common for the network of embedded systems to be
> a closed network - you know exactly what is connected to the network,
> and what software is running on the systems. If you need to connect to a
> dangerous network (such as the Internet), you put appropriate firewalls
> in between.

Yup.  There is also the case of people starting off with this
sort of assumption -- then *forgetting* it.  Or, forgetting to
reevaluate the consequences.  Then, wondering why they are
"suddenly" seeing bizarre system behaviors that "don't make sense"
from an examination of the code...

> It is all about designing the system appropriately, and putting the
> right kind of resources in the right place.

Exactly.  *Not* just picking up some "component" and dropping
it in place because it *looks* like it SHOULD do the job.

> If you need to connect to
> dangerous networks, then you need a stack that is tried and tested
> against such environments.

Note that this sort of stack only needs to have *predictable* behavior
in those environments.  That doesn't mean that it has to "work" there.
E.g., my network speakers have really slim stacks (i.e., big
chunks omitted to get them down into a tiny resource footprint)
but they will survive "exposed" without "crashing" or being
exploitable.  Put them in a more benign environment and they
will easily outperform a "full" stack.  They "work" in each case.
But, "work better" in the environment for which they were designed.

> But if you only need to connect to safe,
> known networks, then it's fine that your stack goes offline (denial of
> service) at the first attack, and that you control it by unencrypted
> telnet connections and pass around passwords using plain text.
>
> The danger, of course, is when people use software and configurations
> targeted at benign networks, and then connect them to dangerous ones.

Unfortunately, I think many aren't really aware/qualified to
understand what can go wrong "on the wire" and "in the stack".
This is a consequence of "black box" *thinking* (i.e., "I
don't need to understand how it works, just how to *use* it...")

Everyone (?) knows that a second order equation will yield
up its roots with:

(-b + sqrt(b*b - 4*a*c))/(2*a)
(-b - sqrt(b*b - 4*a*c))/(2*a)

[sorry, sticking to ASCII makes this harder to visualize than
it should be  :>   Hopefully I didn't munge the parens!  Or,
the *signs*!!]

However, *blindly* applying the quadratic formula (in a computing
environment) will, eventually, lead you astray with certain
"types" of curves.  E.g., understanding this leads to a more
appropriate use of:

(2*c)/(-b - sqrt(b*b - 4*a*c))
(-b - sqrt(b*b - 4*a*c))/(2*a)

or:

(-b + sqrt(b*b - 4*a*c))/(2*a)
(2*c)/(-b + sqrt(b*b - 4*a*c))

as fitting to the curve in question.  The difference, of course,
is *understanding* the solution instead of just blindly *applying*
it!  (a tiny bit more work but a far more "accurate" result!)

> But that's the fault of the system designers or users, not of the stacks.

> http://www.coocox.org/Index.html- Hide quoted text -
>
Is this any good AAMOI ?  Has anyone here used it for real and can
tell me how stable and usable it is ?

Also, I am thinking of using the Olimex ARM-USB-TINY-H for ST ARM
Cortex M3 device development, has anyone any experience with this
setup ?

Are there any ARM Cortex M3 forums that are well frequented and not
specific to any particular manufacturer ?  I like c.a.e. but it's a
bit low-volume atm and I wonder if there is anywhere out there where
all the big kn0bs hang out in ARM terms ?

Thanks,

Mike

Don Y wrote:

> Noob wrote:
> 
>> Linux makes sense in a growing number of scenarios, even
>> in the (32-bit, virtual memory) embedded market : connected
>> TVs, "smart" phones, decoder set-top boxes, routers, etc.
> 
> And you will notice that desktop stacks take a *boatload*
> of resources!  Have you tried porting one to an environment
> with (just) 10's or 100's of KB of total RAM?

Connected TVs, "smart" phones, decoder set-top boxes, routers, etc
have *WAY* more RAM than that; typically /hundreds/ of megabytes,
up to 1 gigabyte (!) for the Galaxy S3. RAM prices have reached an
all-time low, at 4-8 euros per GB.

>> The TCP/IP stack in Linux is robust and mature, and the rare
>> security bugs are fixed fast.
> 
> Just because a bug is fixed in a Linux/*BSD release (or patch),
> doesn't automatically convey those same fixes to the TV/phone/STB!

Phones and STBs can easily be upgraded in the field (TVs too, but
consumers may not feel comfortable doing it).

> Also, the nature of attacks on a desktop/server is different
> than from an embedded device.  The desktop stack just has to
> safeguard against being *crashed*.

And DoS, and spoofing, and hijacking.

> E.g., I do a *lot* of processing in and just above the network
> driver (i.e., low in the stack) so I can discard "inappropriate"
> incoming packets before they percolate up the stack (to the
> appropriate level of abstraction where they might, otherwise,
> be recognized as "inappropriate").  Outgoing traffic inherits
> the priorities of the sending task, etc.  I.e., the stack
> is more of an extension of the application than a separate
> "service" provided to it.

FTR, lwip can be configured that way too.

> In a desktop stack, you either rely on hardware MMU/VM
> mechanisms to  move data between userland and the kernel
> or do lots of copyin/out's.  The stack has no idea how it
> is being used/abused so has to take a generic approach
> to how it provides its services (to the application).
> 
> There are costs (time+space) for this generality.  In a
> desktop, you usually have (or can upgrade to have) these
> resources.  How much "slop" (extra cost) do you add to
> your embedded device to safeguard against this *possibility*
> (which may never come to pass)?
> 
> Desktop stacks tend to be more focused on throughput at the
> expense of all else.  Embedded systems tend to be more concerned
> with a particular "functionality" within a given resource set.
> 
> Desktops are often overkill for *specific* markets/applications.
> If you look carefully at your application and what it expects
> of its environment, you can find many opportunities where a
> "general purpose" network stack can be trimmed down to better
> fit that application -- saving resources, improving resiliency
> and "predictability" in the process.
> 
> This sort of scrutiny is, IMO, invaluable in designing robust
> products; how can you be comfortable with an implementation
> if you don't understand the technology on which it relies
> (to a level of detail that allows you to excise those portions
> that are inappropriate, liabilities, etc.)?

You sound like someone who enjoys reinventing the wheel again
and again (and again). In my opinion, the main strength of
open-source software is to free developers from /continuously/
solving the same problems (what a waste of human brain-power).

Regards.

On 5/14/2012 11:46 AM, Noob wrote:
> Don Y wrote:
>
>> Noob wrote:
>>
>>> Linux makes sense in a growing number of scenarios, even
>>> in the (32-bit, virtual memory) embedded market : connected
>>> TVs, "smart" phones, decoder set-top boxes, routers, etc.
>>
>> And you will notice that desktop stacks take a *boatload*
>> of resources!  Have you tried porting one to an environment
>> with (just) 10's or 100's of KB of total RAM?
>
> Connected TVs, "smart" phones, decoder set-top boxes, routers, etc
> have *WAY* more RAM than that; typically /hundreds/ of megabytes,
> up to 1 gigabyte (!) for the Galaxy S3. RAM prices have reached an
> all-time low, at 4-8 euros per GB.

How many GB are you going to put in your refrigerator?  Freezer?
Washing machine?  Dryer?  Bluetooth earpiece?  Household thermostat?
Irrigation system?  Furnace?  Range/stove?  Telephone?  Multimedia
system remote control?  Toaster?

<http://www.uberreview.com/2005/09/netbsd-controlled-toaster.htm>

Where do you think all those IPv6 addresses are GOING???  Do you
really think consumers will be excited about the UNNECESSARY
ADDED COSTS of "megabytes" of RAM just so their microwave
oven can "know" the right defrost cycle for a 12 pound turkey?
Or, so their washing machine can inform them when the wash
cycle is complete??

>>> The TCP/IP stack in Linux is robust and mature, and the rare
>>> security bugs are fixed fast.
>>
>> Just because a bug is fixed in a Linux/*BSD release (or patch),
>> doesn't automatically convey those same fixes to the TV/phone/STB!
>
> Phones and STBs can easily be upgraded in the field (TVs too, but
> consumers may not feel comfortable doing it).

We've already seen how wonderfully unsolicited updates work!
You've never encountered a problem where your machine "broke"
after a SOLICITED update?  "Gee, Bob, the TV was working
yesterday!  Honest, I didn't *touch* it!  And don't go
blaming the kids for this, either!!"

>> Also, the nature of attacks on a desktop/server is different
>> than from an embedded device.  The desktop stack just has to
>> safeguard against being *crashed*.
>
> And DoS, and spoofing, and hijacking.

It doesn't have to continue to heat the house when under attack.
Or prevent the items in the freezer from thawing (because it
was commanded to raise the temperature setpoint to 10C).
Or ensure that the plants in the yard keep getting watered
despite any "schedule/weather updates" from external services
("Gee, is it Summer out there?  Should I be watering more
often?  Or, less?  I sure wish I knew... but, someone is
pinging the hell out of my interface and I can't seem to
get any useful information...")

>> E.g., I do a *lot* of processing in and just above the network
>> driver (i.e., low in the stack) so I can discard "inappropriate"
>> incoming packets before they percolate up the stack (to the
>> appropriate level of abstraction where they might, otherwise,
>> be recognized as "inappropriate").  Outgoing traffic inherits
>> the priorities of the sending task, etc.  I.e., the stack
>> is more of an extension of the application than a separate
>> "service" provided to it.
>
> FTR, lwip can be configured that way too.

Look at *where* the filtering happens.  If you harvest a
packet, you have incurred cost.  If you can discard it *in* the
driver, you haven't.

>> In a desktop stack, you either rely on hardware MMU/VM
>> mechanisms to  move data between userland and the kernel
>> or do lots of copyin/out's.  The stack has no idea how it
>> is being used/abused so has to take a generic approach
>> to how it provides its services (to the application).
>>
>> There are costs (time+space) for this generality.  In a
>> desktop, you usually have (or can upgrade to have) these
>> resources.  How much "slop" (extra cost) do you add to
>> your embedded device to safeguard against this *possibility*
>> (which may never come to pass)?
>>
>> Desktop stacks tend to be more focused on throughput at the
>> expense of all else.  Embedded systems tend to be more concerned
>> with a particular "functionality" within a given resource set.
>>
>> Desktops are often overkill for *specific* markets/applications.
>> If you look carefully at your application and what it expects
>> of its environment, you can find many opportunities where a
>> "general purpose" network stack can be trimmed down to better
>> fit that application -- saving resources, improving resiliency
>> and "predictability" in the process.
>>
>> This sort of scrutiny is, IMO, invaluable in designing robust
>> products; how can you be comfortable with an implementation
>> if you don't understand the technology on which it relies
>> (to a level of detail that allows you to excise those portions
>> that are inappropriate, liabilities, etc.)?
>
> You sound like someone who enjoys reinventing the wheel again
> and again (and again).

I believe in coming up with the right solution for the problem.

Do you use long longs for all your "numbers"?  Heck, you can
represent 1, 35099, 68736, 5003876555, etc. ALL as long longs!
Why bother with byte_t's, shorts, ints, longs and long longs
when you could just use long longs for ALL of them!!!  Why
REINVENT all the arithmetic operations for each of these
different data type sizes?!

Hmmm... we'll have problems with floating point values, though.
OK, so we;ll use long *doubles* for all out numeric needs!
Why bother with integer data types, floats, doubles *and*
long doubles if we can just handle them all with long doubles?!
Why REINVENT all the math LIBRARIES to support each of these
types?  Why burden printf with having to know which size
argument it is dealing with?  "Numbers are numbers", right?

Of cource, we also haev to worry about numbers that can't be
accurately expressed in those representations.  So, maybe
we should adopt the use of a *rational* data type.  I.e.,
    typedef struct {
        long double numerator;
        long double denominator;
    } rational_t;
And, of course, that won't handle complex numbers so we need
a complex_rational_t as well...

Look at all the REINVENTING that we've been able to AVOID!
After all, memory is cheap!  Put a few GB in your toaster
so you can implement:
     turn_on_heating_element();
     sleep( (rational) (5.0L, 1.0L) );
     turn_off_heating_element();
     eject_toast();
     beep();
with those nice CONSISTENT numeric types!  :>

Do you have ONE sort() routine in your toolbox?  Heck, sort
is sort is sort.  Why REINVENT such a trivial facility?
Just throw more CPU cycles/memory at "whatever" algorithm you
settle on and live with that!  Of course, you will have to
make sure your sort() is completely parameterized so you can
sort arbitrary objects -- not just "numbers" (which we have
already decided will be complex_rational_t's) or "strings"
(which should all be of variable length -- do we do LR alpha
sorts?  What if we're sorting some numerical strings?  Do
we add a SWITCH to sort right justified??)  Look at how much
we'll *save* by not reinventing specialized sort()'s!  :>

And, we surely don't need gets(), fgets(), getchar(), fgetc(),
getc(), UNgetc(), scanf(), sscanf(), fscanf(), etc.  Let's
just settle on *one* so we don't REINVENT any of the same
(and incompatible) mechanisms.

Nor, different window managers, operating systems, "computers",
mice, etc.  Choice is bad.  One size fits ALL!  Need a pocket
calculator?  Carry a laptop!  Need a pencil and pad of paper?
Put your desk on wheels!!  :-/

We'll take a VOTE next Tuesday and rid ourselves of all this
UNNECESSARY duplication!

> In my opinion, the main strength of
> open-source software is to free developers from /continuously/
> solving the same problems (what a waste of human brain-power).

People often mistake *code* reuse with *design* reuse.
The thought that cobbling some existing (hopefully *working*)
code into a new project somehow cuts a corner.  Sure!  If
you are making essentially the same *thing* as that for
which the code was originally created!  (is your washing
machine essentially the same as your STB??  Or your
furnace?  Granted, they each might have a network
connection -- but, are their roles and needs *that*
similar that they would benefit from the same network
stack as that used in your PC???  REGARDLESS OF IT'S
SOFTWARE COST??)

The real gains are in reusing *designs*, not *code*.
Approaching similar problems in similar ways.

Reusing *code* assumes the code works, you *understand*
it sufficiently to *know* that it addresses your problem
domain adequately and that you will be able to *maintain*
it (what good is developing a product "overnight" if
you have to answer the first customer complaint with,
"Gee, I'll post a message on the forum and hope someone
*there* can tell me what's going wrong...").  This is how
product counterfeiters often falter -- when something
goes wrong, they haven't the knowledge of how to *fix* it
(because they've COPIED instead of ENGINEERED).

[It's also a great way to *thwart* counterfeiters by
designing your product to "break" if subtly altered!]

Reinventing for the sake of reinventing is a non-starter.
Blindly *reusing* is even worse!

>> http://www.coocox.org/Index.html- Hide quoted text -
>>
>Is this any good AAMOI ?  Has anyone here used it for real and can
>tell me how stable and usable it is ?

I am are working with the coocox IDE and found it pretty good and reliable.
Our project is an autopilot system for RC models. After a year of
development it's in production. 

While there are other compatible interfaces, colinkex is the safe bet for
the coocox IDE. I had some trouble with others, worked with a version and
failed with the next edition. 



	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

Don Y wrote:
> Noob wrote:
>> Don Y wrote:
>>> Noob wrote:
>>>
>>>> Linux makes sense in a growing number of scenarios, even
>>>> in the (32-bit, virtual memory) embedded market : connected
>>>> TVs, "smart" phones, decoder set-top boxes, routers, etc.
>>>
>>> And you will notice that desktop stacks take a *boatload*
>>> of resources!  Have you tried porting one to an environment
>>> with (just) 10's or 100's of KB of total RAM?
>>
>> Connected TVs, "smart" phones, decoder set-top boxes, routers, etc
>> have *WAY* more RAM than that; typically /hundreds/ of megabytes,
>> up to 1 gigabyte (!) for the Galaxy S3. RAM prices have reached an
>> all-time low, at 4-8 euros per GB.
> 
> How many GB are you going to put in your refrigerator?  Freezer?
> Washing machine?  Dryer?  Bluetooth earpiece?  Household thermostat?
> Irrigation system?  Furnace?  Range/stove?  Telephone?  Multimedia
> system remote control?  Toaster?

You're a big fan of logical fallacies, aren't you?

The answer is mu. ( http://www.catb.org/jargon/html/M/mu.html )

I was discussing systems running on 32-bit, MMU-enabled CPUs.
Would you use an ARM Cortex M3 in your toaster?

<huge snip>

> Do you use long longs for all your "numbers"?  Heck, you can
> represent 1, 35099, 68736, 5003876555, etc. ALL as long longs!
> Why bother with byte_t's, shorts, ints, longs and long longs
> when you could just use long longs for ALL of them!!!  Why
> REINVENT all the arithmetic operations for each of these
> different data type sizes?!

Again, mu.

Also, a bad analogy is like a leaky screwdriver.

On Wed, 16 May 2012 11:03:12 +0200, Noob wrote:

> Don Y wrote:
>> Noob wrote:
>>> Don Y wrote:
>>>> Noob wrote:
>>>>
>>>>> Linux makes sense in a growing number of scenarios, even in the
>>>>> (32-bit, virtual memory) embedded market : connected TVs, "smart"
>>>>> phones, decoder set-top boxes, routers, etc.
>>>>
>>>> And you will notice that desktop stacks take a *boatload* of
>>>> resources!  Have you tried porting one to an environment with (just)
>>>> 10's or 100's of KB of total RAM?
>>>
>>> Connected TVs, "smart" phones, decoder set-top boxes, routers, etc
>>> have *WAY* more RAM than that; typically /hundreds/ of megabytes, up
>>> to 1 gigabyte (!) for the Galaxy S3. RAM prices have reached an
>>> all-time low, at 4-8 euros per GB.
>> 
>> How many GB are you going to put in your refrigerator?  Freezer?
>> Washing machine?  Dryer?  Bluetooth earpiece?  Household thermostat?
>> Irrigation system?  Furnace?  Range/stove?  Telephone?  Multimedia
>> system remote control?  Toaster?
> 
> You're a big fan of logical fallacies, aren't you?
> 
> The answer is mu. ( http://www.catb.org/jargon/html/M/mu.html )
> 
> I was discussing systems running on 32-bit, MMU-enabled CPUs. Would you
> use an ARM Cortex M3 in your toaster?


Add enough computing power to the toaster and you can save by leaving out 
the heating elements.

How to build a better toaster:
http://kcbx.net/~tellswor/bettoast.htm

Regards,
Allan