FreeRTOS and newlib - comments requested

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I'd appreciate any comments from those of you who have
used (or tried to use) this combo, especially if I've
gotten anything wrong or missed anything...

Thanks in advance,
Best Regards, Dave

Re: FreeRTOS and newlib - comments requested

Quoted text here. Click to load it

Thanks very interesting, good to know, I'm (I hope) starting a new project  
in a near future and was thinking on using a Kinetis and FreeRTOS.

The only thing I can add is that KDS examples are in general not very usefu
l (they don't explain much and often badly coded).
And also the KSDK is not bug free (at least until version 2.x, don't know a
bout v3), it seems they didn't test it properly.

Bye Jack

Re: FreeRTOS and newlib - comments requested
 > The only thing I can add is that KDS examples are in general not very useful (they don't explain much and often badly coded).
Quoted text here. Click to load it

I never use SDKs, just because of those things enumerated above. I usually
have the SDKs at hand, to look into when the manuals are not very clear.
Every manufacturer seems to want to have one, probably because this is
the trend, but in fact it's more hurt than help. You really cannot
rely on the SDK only, without reading the manuals. Because the documentation
of the SDK is very poor, partly because it would double the effort for
the manufacturer. So, what shall you study? the SDK or the manual? Usually
you need both.  

And the coding is most of the time a nightmare. I remember when I tried
using a SDK for a new microcontroller (to me). It was almost impossible
to write a "some_long_identifier = some_other_long_identifier;" on a  
single line :) And if you have to write this kind of code:
some_long_register_name = SOME_LONG_BIT_DEFINITION |
                          SOME_OTHER_LONG_BIT_DEFINITION |
You must use a single identifier on a line :)
Not to say about function calls with multiple arguments...
You just can't type anymore. Editing code is only a series of copy/paste.

Re: FreeRTOS and newlib - comments requested
On Wednesday, June 28, 2017 at 2:41:10 AM UTC-4, Jack wrote:

Quoted text here. Click to load it

The K64 has been a good part, one shipping product and starting a 2nd, howe

Quoted text here. Click to load it

The SDK is extremely buggy, and SDK behavior and interface unstable
across versions. For half the peripherals I had to write my own drivers.
The examples are typically not set up properly (see the link above).
And the Freescale 'support' is the worst I have ever encountered.
Note this is for Kinetis series; iMX may be much better.

Hopefully NXP will clean house as they integrate Freescale.
I had great experiences with NXP on a few former LPCxxx projects.

We'll see...

Re: FreeRTOS and newlib - comments requested
On 6/27/2017 11:41 PM, Jack wrote:

Quoted text here. Click to load it

These types of "support activities" are often handled by "junior engineers".
I think their thinking is that its a relatively "safe" way to use their
skills without too much risk (I think they expect developers to rework
the examples and not blindly incorporate them into product).  I know that
the quality of support folks with which I interact varies based on the
dollar volume of the business I'm doing.

The same is true of "application notes" -- both hardware and software.
Taking ANY of that stuff literally is almost certainly a bad idea.  I
don't think anyone actually proofreads the code/schematics...

It's worthwhile to develop your own standard libraries, drivers/handlers,
crt0.s, etc. that you are more intimately familiar with so you can more
readily port them to other projects without having to resort to kludges
layered on "foreign code" (e.g., how would you implement fprintf(3c) in
a variety of different execution environments?  sprintf(3c) to a dynamically
allocated buffer followed by a bytewise copy to the FILE* referenced
and tearing down the buffer at cleanup)

[Obviously, there are more effective/less risky approaches]

Re: FreeRTOS and newlib - comments requested
On Wednesday, June 28, 2017 at 10:39:57 AM UTC-4, Don Y wrote:
Quoted text here. Click to load it

Two different topics:
(1) 'support' desk
The unfortunate side-effect of cheap development kits (which we all love):
Every student and wannabee buys one, and then contacts support because they
need help opening the box. Hence a colleague at Garmin (who buys *lots*
of these parts gets to talk to an actual real engineer... And the rest of us
get to email to Freescale's lowest-possible-cost help desk in China staffed
with script-readers who tell us to reinstall the software and try again,
and cannot manage anything vaguely complex. If you have a real problem,
they by definition cannot help - if they were smart enough to
help they wouldn't be working there.

(2) Marketing-required SDKs and application notes:
Provided  by usually not the top-tier engineers, but at least engineers.
I've seen plenty of app notes that would cause a fire if copied,
and I've seen field failures when a witless engineer copied one
verbatim and shipped it without proper testing...
But the SDKs are relied on by real customers (who expect at least
working examples) so there is *some* pressure to make this stuff work.
But not enough to use top-tier engineers and implement real testing
(for at least many vendors). So you get stuff like Freescale's SDK,
which provides init functions for all the control structures, but
they don't actually initialize the entire structure - so the sample
code memsets the structure to 0 and then calls the init...
You couldn't make this stuff up!

Quoted text here. Click to load it

Absolutely. But don't stop there, implement the USB-stack, network-stack,
all drivers, compiler, runtime library, and operating system yourself.
That way you'll know what your getting for sure.
And don't forget to design your own improved peripherals using FPGAs.

Except for the USB and network stacks, I've done all the above *too*
many times (and I've had to *debug* some USB and network stacks).
But when I **actually have to build a product for a customer**, using
the latest MCUs and electronics, this is wildly impractical!

So we end up depending on variable-quality stuff,
and slogging through fixing the worst of it,
and economics say it ain't going to get better - not possible.

Enough, Hopefully I've helped a bit with the newlib stuff!

Re: FreeRTOS and newlib - comments requested
On 7/1/2017 11:16 AM, Dave Nadler wrote:
Quoted text here. Click to load it

(Well, the price of the kit isn't directly coupled to the quality of the
support; they *could* offer the kits "at cost" and force folks to pay
for support *or* rely on forum-based support as a consequence of the
low cost prototype)

Quoted text here. Click to load it

The manufacturer can't afford a "relationship" with each *potential*
customer.  Instead, they hope to seed development efforts and possible

I've found that the quality of the questions I issue and the critiques
of their "product" (documentation, hardware, toolchain, etc.) gets me
the attention of the right people.  I.e., they know I'm digging deep
under the hood and not just poking at something casually or for a

Then, it becomes an issue of keeping in touch with these inside contacts
often enough that as they move through (and between) organizations, they
remain accessible to you -- so you don't have to start all over at the

[This allows my work with bigger customers to benefit the little garage
shops -- who'd simply not have access to those sorts of resources with
their small volume purchases]

Quoted text here. Click to load it

Developing relationships with key customers lets you rely on them for
*thoughtful* feedback.  I've had relationships with tool vendors
where I would report a problem in the morning and have an updated
set of binaries TO TEST by evening.  Me benefitting from not having to
leave work-arounds in production code; they benefitting by not having
to do extensive testing before getting a pre-release out.  They
could defer releasing THIS version to their customer base until the
next "scheduled release" -- when it would have undergone more formal
documentation and testing.

Quoted text here. Click to load it

Again, find customers who are conscientious, go the extra mile for
them KNOWING they'll be willing/eager to share their efforts with
you.  They're obviously not going to share proprietary ideas or
algorithms; but can catch and repair errors as more than an academic
exercise -- they're *using* the code/schematic-sections that they're
feeding back to you.

Forums try to exploit this but the "relationship" is tenuous and,
by definition, "public".  I'd not want to discuss or reveal specific
details of a project in a public forum beyond what I need to get
a problem fixed.

By contrast, in private communications, I can pass far more detailed
information, larger code fragments, bigger portions of schematics, etc.
without wondering who *else* (competitors) is seeing what I'm doing.

Quoted text here. Click to load it

That's often a requirement.  I'm writing my fourth network stack as each
has had different design and operating constraints.  "One size fits all"
DOESN'T!  But, this really isn't hard if you've already created other
versions and just want to tweek them to fit a new set of requirements
or constraints.

It also shows you the value of writing "portable" code; you can inherit
a lot of quality without having to rewrite it all.

Quoted text here. Click to load it

Only if needed.  Buy what you can; write/design what you must.
Silly to waste time designing a DRAM controller when you can buy one
that's already integrated with the processor.  OTOH, if you want to
*share* physical memory with another device, you're likely not going
to find a COTS solution (for processor of your choosing).

Quoted text here. Click to load it

I think importing code/hardware is the more impractical.  You have
little idea of how it was *intended* to work, the skill level of
the developer, the ruthlessness of the folks testing it, etc.

And, you start over with each new platform with the same uncertainties.

By contrast, I can tweek the same libraries I've been using for years
to work with a new compiler/toolchain, new hardware platform, etc.
Ditto other major subsystems, device drivers, etc.  Most of the
"meat" lies in the choice of algorithms, not the vagaries of the
particular hardware.

Quoted text here. Click to load it


Re: FreeRTOS and newlib - comments requested
On Saturday, July 1, 2017 at 3:13:26 PM UTC-4, Don Y wrote:
Quoted text here. Click to load it

No they cannot - The competitive market and corporate budgeting dictates
these are sold at or below cost.

Quoted text here. Click to load it

Way back, my firm got several big customers after support contacts about
problems with their products.  But you will never, ever, reach serious folks
through today's support channels (like Freescale) because of the economics.
Unless you are my colleague at Garmin or similar you're screwed.
Perhaps I'm overly pessimistic given the recent support mishaps;
still have senior contacts at some vendors so its not impossible.
No idea how to reach anybody competent and attentive regarding the
Kinetis line, though NXP a few years back was great (fixed documentation
errors I pointed out, fixed bugs and helped me work around others).

I should stop teeth gnashing and go enjoy the summer with my wife now!
See ya, Dave

Re: FreeRTOS and newlib - comments requested
On 7/1/2017 1:02 PM, Dave Nadler wrote:
Quoted text here. Click to load it

That's the point; work on large volume kit and you'd be surprised who
they'll put on a *plane* to COME talk to you.  Of course, you
don't have to FORGET that contact when you move on to the next
"garage shop" project.  If *all* you effectively are is a "purchasing
agent" (i.e., you only appear to the vendor as a source of sales),
then you have little continued sway with that vendor or his staff.

OTOH, if you can engage them in technical issues that affect *their*
design decision of future products (because they want to develop
things that YOU will want to buy), you're more likely to *keep* their
(individual) attention, even after you've moved on to smaller ponds
or different domains.

[I.e., you want a *personal* relationship with the folks involved,
not a "business" relationship.  The former is tied to YOU, the
latter is tied to the firm you're representing along with the
firm at which your contact is CURRENTLY employed.]

Quoted text here. Click to load it

With most forums (fora?), there is little value to reporting problems
and solutions.  If it's not a "trivial" or *obvious* problem (one
that WILL affect everyone), chances are you'll have to fix it yourself.
How much time you want to spend beyond that is a personal issue as
you're unlikely to "get" much for that investment (beyond a sense
of having helped some other who *might* head down that same path).

Early in my career, clients made the decisions regarding which tools,
components, etc, they wanted used in THEIR products;   when they'd
invested tens of kilobucks in a "development system" -- not just
a compiler on a PC -- they were eager to leverage that prior investment
AND the past development/troubleshooting/manufacturing experiences
of their existing staff.  "Can't you do this with a 6809?  68K?  1802?
Those are the tools and components that we've experience with, now..."
(sure, but are any of those really the right way to approach the problem?)

Later, I learned to take more control of projects -- be a bigger fish
in a smaller pond, often.  So, I could tailor the hardware (that *I*
was going to be charged with designing) to the software (that I would
write) to the toolchain (that I would purchase/develop) to satisfy the
specification (that I'd write and the client would approve).  By
leveraging past designs, I could continue to take on larger projects
without having to "increase (my) resources" -- I knew where the
costs would be in my approach instead of having to open a new can
of worms, each time.

Quoted text here. Click to load it

Work should be *fun*.  If its not, then its a *job*.  :<

Quoted text here. Click to load it

Re: FreeRTOS and newlib - comments requested
On 01.7.2017 ?. 21:16, Dave Nadler wrote:
Quoted text here. Click to load it

Not everyone. I am the proof :-). In fact I have never wasted any time
with one of these. If I will design something I will have to design it
anyway, why would I waste time toying around with some other board
than the one I want to design.

Quoted text here. Click to load it

This is why I hate the trend. Because of the above programmers
are almost extinct. And because they are kids who know how to open
the box call themselves "programmers" and the public accepts that.
Worse, the customers of our kind do.


Dimiter Popoff, TGI   

Re: FreeRTOS and newlib - comments requested
On Saturday, July 1, 2017 at 3:41:28 PM UTC-4, dp wrote:
Quoted text here. Click to load it
Quoted text here. Click to load it

These boards are invaluable! On my desk I have one I used to bring up
most of a customer application, with stubs for the real hardware.
We sent a few to the end customer to debug their software against our
API before the real (hugely expensive) hardware was ready, and they
continue to use them for software development.

Quoted text here. Click to load it

Me too. But the depth of current stacks precludes doing everything
oneself like the old days. Witness your struggle moving to a new
processor ;-) Customers pretty quickly find out when they can't
get something that works reliably, promptly, who is a real engineer.
Or they go bust (plenty of stories of crating I've witnessed).
Anyway I'm not going to write another RTOS.

At least I can have fun teaching "How NOT To Do Embedded Design"!
Perhaps I'll do it again at fall west coast ESC...

See ya, Dave

Re: FreeRTOS and newlib - comments requested
On 01.7.2017 ?. 22:52, Dave Nadler wrote:
Quoted text here. Click to load it

I understand they can be useful in your case where your goal is to
sell just software, not a complete product. I have almost never been
there hence my point of view.

Quoted text here. Click to load it

Not such a huge struggle really - unless you envisage my moving
from the 68k architecture to power, this took me a year and was
anything but a walk in the park.
I'd like to see someone doing it in a shorter time - porting the
entire OS and all apps, was 6 or 8 M source back then (> 15 years
ago, how is THAT possible...). Say ARM to x86 or vice versa.

Moving within closer family has taken negligible time, say when I
needed a small MCU a few years ago for a one-off it took me
3 months to adapt my entire toolchain to it (mostly writing
the BDM thing and the debugger) and another month for the end
application code. I have yet to see someone matching the 4 months
for a product like that (hardware design, simulations, PCB
etc. included in the 4 months of course): , second product top
to bottom (the +/-100V saw generator),
Matching that using any board and any toolchain will still
have me impressed.

Quoted text here. Click to load it

Of course, they are not stupid. Or go bust :-).
But I have never managed - never tried really - to sell just
software, hence our differing points of view I guess.

Quoted text here. Click to load it

Hah, never say never :-).
I feel the same about dps of course.

Quoted text here. Click to load it



Dimiter Popoff, TGI   

Re: FreeRTOS and newlib - comments requested
On Saturday, July 1, 2017 at 4:22:28 PM UTC-4, dp wrote:
Quoted text here. Click to load it

No! We are making hardware products!
We used this eval board until real hardware was ready and working.
And we *still* use it when the expensive/huge real hardware isn't required.
For example when I have a rainy day at the races...
And the end-customer *still* uses it for working on their software,
with my simulation build loaded.

The cheapo eval boards are invaluable.
This is only the latest of many examples where I started projects
with these boards (from decades back when they were still expensive
and supported).

Re: FreeRTOS and newlib - comments requested
Hi Dimiter,

On 7/1/2017 12:41 PM, Dimiter_Popoff wrote:
Quoted text here. Click to load it

I think you're ignoring the fact that most folks don't design hardware,
anymore.  The thinking seems to be that you can "save lots of time"
by buying a board that you can glom some I/O's onto.

Of course, now you have to design the I/O board and hope its a clean
interface to the purchased board -- and, that the purchased board
meets *your* specific needs (gee, will it operate *reliably* over the
full temperature and power supply range?  will it be repairable?
will the vendor keep supplying THAT "component"?  etc.)

So, folks are even more willing to buy their prototyping hardware...
"so they can be writing code (that they've not fully DESIGNED!) sooner"!

[A guy in SED was looking to use an arduino to light an indicator when
it sensed a device (cell phone) was NOT plugged into the USB outlet.

There's this misplaced sense of "if I do THIS, I can cut all these
corners and be done quicker, cheaper, etc." -- but all you do is
swap in NEW "corners" that you'll need to work through.

[E.g., the guy who used a COTS PC as the UI for his process control
system -- then had to figure out how to package it in a way that
would protect the keyboard, disk drives, monitor, etc. from the harsh
environment to which they'd be subjected, etc.  And, of course, the
PC didn't have the necessary I/O's to interface to the field sensors
and actuators so he *still* had to design some boards for that.
Then, had to scurry when the PC vendor stopped offering that particular
model and new buses came into being, etc.  How much did he *really*

OTOH, there are markets where you need to be able to respond quickly
and choose not to invest in the staff that would otherwise enable you
to do so -- effectively outsourcing the skillsets that you would otherwise
need to ensure your *continued* viability.

And, finally, the folks who delude themselves into thinking they're
just going to use this to get a toe-hold in the market and THEN they'll
RE-design the product the "correct way"... only to discover that either:
- their product sucks and they've effectively NO market (share)
- their product has high demand, despite its shortcomings, and they
   are now caught up trying to address modifications/enhancements requested
   from their customer base -- while their competitors are free to work
   on the NEXT generation products that will supplant them in the market
   that they THINK they've got such a hold over!

[A manager at a multimillion dollar manufacturing company once lamented
to me that they LOST their market when they were busiest meeting its
needs -- as a virtual monopoly!  They were so busy being "wagged" by
their new/existing customers that they didn't have time to put resources
into "what comes next".  So, when the competition announced a better
mousetrap, sales dried up overnight and there was no "next" product
ready in the pipeline to compete!]

Quoted text here. Click to load it

Until they find a product that eats their lunch/reputation.

Re: FreeRTOS and newlib - comments requested
On 01.7.2017 ?. 23:15, Don Y wrote:
Quoted text here. Click to load it

Hi Don,

So you see I am not ignoring the fact they don't want to design
hardware; they have to design it anyway. Adapting it to a generic
board will cost at least as much as placing their own MCU on their
The latter option would get them much closer to what they want but
they typically "don't know how to open the box" as Dave said in
a post before.

Quoted text here. Click to load it

The thing with prototyping is that it only wastes your time if you
know what you are doing. Why do everything TWICE? Typically I design
the boards, the first revision obviously needs some cuts etc but
is quite acceptable, typically a lot more acceptable than first boards
I have seen having been made after months of prototyping etc.

The reason why one might want to use some prototyping board is if they  
want to sell software to run on it or if they want to write software
for a year or more and thus wait for chips to come out/go extinct
by the date of their end design. I have done neither hence my
point of view.
But these two are quite valid reasons.

The main reason behind these boards being so popular is the fact
that the design decisions are taken by people who do not know what
they are doing so they don't have the confidence to design the
product and try to make it easier for themselves by using something
"readily available". Well guess what, using a board with an MCU
is _harder_ than using an MCU alone, it just looks easier to
people who can't figure out "how to open the box". And these
people are defining the market trend... as it has been throughout
history, the slowest ones define the pace of the group.


Dimiter Popoff, TGI   

Re: FreeRTOS and newlib - comments requested
On 7/1/2017 1:52 PM, Dimiter_Popoff wrote:

Quoted text here. Click to load it

Exactly.  The MCU (even if CPU+memory, etc.) is a no-brainer
part of the design.  OTOH, some folks might not have SMT manufacturing
capabilities and the I/O's can often be designed to be thru-hole
(giving them more choices as to how/where they are fabbed).

Quoted text here. Click to load it

Exactly.  You slap together COTS stuff and you forfeit a lot
of control over cost, reliability, maintenance, form-factor, etc.

E.g., my "network speakers" are implemented in a "module" that
is composed of several TINY stacked PCB's.  Because, in one (common)
deployment, it has to fit in a 1.5 x 2.5 x 1" volume.

What COTS "assemblies" will give me that composite form factor
and support power sourced via PoE, 100Mb network interface,
two channel amplifier, microphone (w/preamp), Ir detector, CPU,
memory and enough horsepower to do real-time DSP (tone controls,

And, when I want to use the PoE subsystem on some *other* design
(e.g., HVAC thermostat), will I need to find some other COTS
assembly that fits THAT form factor and has similar performance
characteristics as the "network speakers'" PoE interface?

And, will all of these vendors continue to offer these assemblies
as long as *I* want/need them?  Or, will they decide to make changes
that I'll have to accommodate "on the fly"?  Or, stop offering
something entirely leaving me in dire need of a substitute (with
a possible new development effort in front of me)?

Quoted text here. Click to load it

I learned to "prototype in foil" more than 30 years ago.
Prototyping in any other way inevitably means you'll have to
eventually create a "first pass" at your *production* system
(which will likely need some hardware/software revision).
So, expect yet another pass after that before you can
expect to be ready for "production".

Quoted text here. Click to load it

I've gone back to prototyping on my current project simply because
most of the ideas that I am trying are untested -- there are no
simmilar products that I can point to and assure myself:
    "yes, this approach WILL work; this is how much resources
    SOMEONE ELSE required to tackle a similar problem; etc."

It also lets me defer committing to *an* implementation (hardware)
until I have *all* of the implementations ready.  I.e., why commit
to a particular PoE PD controller (chip) for "design #1", today
and discover that a better/cheaper PoE PD controller is available
when it comes time to finalize design #6?  If all of the designs are
released at the same time, why not avail yourself of whatever the
LATEST technology supports at the time of release?

[E.g., my "compute resources" are 1GHz, 2GB SBC PC's.  I'm *sure*
that's WAY WAY WAY more than each node needs!  OTOH, with each
new MCU/SoC release, I see how much more I can potentially have
available in a released product so I can just increase the
(artificial) resource quotas that I've imposed in each design
and magically remain "current" with the capabilities afforded by
today's technology, today!]

Quoted text here. Click to load it

No, I think it has to do with the (mistaken) belief that it
"saves time".  Esp the "lets start writing code TODAY cuz we
KNOW we're going to be the longest lead item; having REAL
HARDWARE makes that possible!"  Instead, they should be
focusing on what their ultimate goal (specification) is likely
to be so they don't prematurely commit to a particular
hardware platform, set of software libraries/subsystems/components,

E.g., I develop much of my products in simulators -- just verifying
that the algorithms are implemented correctly:
- does this code correctly decode this data stream to reconstruct
   the audio signal that it was intended to carry?  let's see what
   it actually sounds like (by pushing a file of simulated received
   data through it and capturing the resulting output -- for playback
   on a PC, AIFF, etc. player)
- does this "tone control" implementation do what it's intended to
   do?  Let me push that same raw data through the decoder with
   different "tone control settings" and compare the resulting
   files "with my ears".

I only need *real* hardware when I want to do things that are
difficult to simulate reliably:
- if I push the left channel through this device and the right
   channel through this other device, will the resulting audio
   outputs remain in proper phase relationship?
- if I put lots of competing traffic on the wire, will audio
   packets get lost?  will the recovery algorithms work as
   intended -- or will their be audible artifacts?
- how much resources are *actually* used (vs. PLANNED for use)?

But, this requires a different mindset -- and skillset!

Re: FreeRTOS and newlib - comments requested
On 27/06/2017 15:22, Dave Nadler wrote:
Quoted text here. Click to load it

I get:
Not Found
The requested URL /embedded/draft1_newlibAndFreeRTOS.html was not found  
on this server.
Additionally, a 404 Not Found error was encountered while trying to use  
an ErrorDocument to handle the request.

Mike Perkins
Video Solutions Ltd
We've slightly trimmed the long signature. Click to see the full one.
Re: FreeRTOS and newlib - comments requested
On Thursday, June 29, 2017 at 5:38:39 PM UTC-4, Mike Perkins wrote:
Quoted text here. Click to load it

Sorry, its offline while I correct a few errors found by reviewers.
I'll post when draft2 (or final version) is up.

Re: FreeRTOS and newlib - comments requested
On Tue, 27 Jun 2017 07:22:26 -0700, Dave Nadler wrote:

Quoted text here. Click to load it

I'd like to see it when it comes up.

Does newlib advertise itself as being thread-safe?  I kinda vaguely  
remember the answer is "yes", but dunno.


Re: FreeRTOS and newlib - comments requested
On 6/30/17 11:02 PM, Tim Wescott wrote:
Quoted text here. Click to load it

Newlib does advertise that it CAN be thread safe if configured to be so.  
It has hooks that can provide the needed exclusion primitives from the  
OS and hooks to provide it with Thread Local Storage for the library.

Dave is basically writing part of this layer for FreeRTOS. Part of it is  
already provided in FreeRTOS via a configuration parameter.

Site Timeline