Marc's LPC800 compilation environment+lib

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Sat Mar 01 12:12:59 MST 2014
Hi,

I just made available my environment and library I use for programming LPC8xx devices.
You need Perl, binutils and gcc (arm-none-eabi-*), bash and GNU make.
No IDE, no GUI, no CMSIS, no code-bloat, no redundancy. Just your favourite editor and make.

I don't urge you to use the environment, but I do urge you to look at some concepts of it:
[list=1]
  [*] __stopping_that_excessive_use_of_unneccessary_and_hard_to_type_underscores.
  [*] new/readable approach of defining peripheral register files (lib/c-lpc8/lpc8/*.h)
  [*] use a C dialect, that is powerfull enough: --std=gnu99
  [*] use generators, when the language is lacking features: util/{unionize.pl,slice.pl}
  [*] extract highly re-usable code and put it in library (lib/c-any/*) of its own
  [*] massive use of inline static, if applicable.
  [*] look at programs/multitask/
  [*] under all circumstances, look at c-any/fifo*.h, especially the parsing.
[/list]

You can find it here: lpc8

Any comments are welcome.

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Sat Mar 15 16:31:36 MST 2014

---

Quote: Pacman

Even if you have been moving to a new platform and either rewritten or adapted the earlier code

---

My current approach is: all projects (lpc21, lpc17, .. lpc8, c-linux) share c-any/  as a subversion 'externals' definition. Even my flasher 'mxli' uses that code. So it's literally the same source in all projects.

When thinking about the div10 optimization, I realized another advantage of a human programmer over gcc: the human can estimate 'reasonable' ranges of parameters. gcc does the optimization much better than me, provided the full range of an integer is used. But it the case of the 16.16 bit fixed point decimal output routine, gcc doesn't apply the trick of using the (fast) M0 32x32->32 bit mul for a divide by 10 - which is sufficient for divide 16bit by 16bit. No need to say anything about the speed-up of a single-cycle MUL compared to an emulated UMULL...
I wish, the 'C' languaged provided mechanisms to specify ranges for values and gcc to take advantage of this information.

[lpcware]

Content originally posted in LPCWare by Pacman on Fri Mar 14 14:55:41 MST 2014
Thank you for the nice words. :)

The LPC800 is very impressive when looking at its size and price. It brings new technology to explore. The timers might not be as convenient as other kinds of timers, but they do bring new possibilities, which are worth exploring.

As I see it, you've been using the code mentioned for around 3 years; this means the code has already been tested and improved for a while. Even if you have been moving to a new platform and either rewritten or adapted the earlier code, it means: Improved stability, because you've found better ways to do the tasks, and if you've found bugs along the way, you've also squashed them.

That's worth thinking about as well. ;)

Regarding the M0 optimization; well, there's of course a lot more that can be done. The best you can do, to 'stretch' the processor's instruction set, is to use it in a way you didn't imagine you would use it. :)

GCC is a pretty cool and pretty impressive compiler, when it comes to optimizing.
Sometimes it generates code, which is way over my head.
-But you can still beat the compiler when you invent new tricks yourself.
Fortunately, the compiler-developers also come up with new ways to abuse instructions. :)

-So keep getting crazy ideas; those ideas can make a huge difference.

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Thu Mar 13 14:44:04 MST 2014
@Pacman:  thanks for looking at the code. I appreciate a wise man's time. A few weeks ago I read your blog (M0 optimization) and I was impressed! Unfortunately, my possibilities are limited in this forum, probably because of spam problems adhering to my email address - I can't answer to blogs.

I know I'm using the Microsoft model  ;-)
Even worse, LPC800 ist the latest 'environment', so probably the most error-prone. But I released it, because it's the one I use for implementing new features and because it's the smallest, with the smallest portion of proprietary code (I have to remove). The minimalistic threading approach I posted some time ago is also 'only' a part of lpc8.
And of course the LPC800 family is quite new and some beginners may now be more open to a non-standard alternative, that tries to waste less memory.

I'm sure, there are errors. And (not) extensive testing is probably my weak point :(
However, I'm pretty optimistic about fifo.h .  It's at least 3 years old and heavily used in my programs (and the programs of a commercial company). The fifoPrint* and fifoParse* stuff is much less tested, especially since I optimized some decimal output functions for the M0 (replacing 'div by 10' by a multiply, even if gcc doesn't recogize it's possible (and faster)).

[lpcware]

Content originally posted in LPCWare by Pacman on Thu Mar 13 13:37:32 MST 2014
... Uhm, the only real problem Microsoft has is that none of the good developers wants to work for them. :D

Thank you, also from this end, for releasing code to the public.
I agree on the unit-tests / stress-tests are good. Sometimes you don't need the tests, if the code is short and precisely written, but most of the time, you will need it, due to the complexity of the code.
Anyway, writing a FIFO at random, would not make it worse than most of the FIFO-code I've seen. ;)

[lpcware]

Content originally posted in LPCWare by rocketdawg on Wed Mar 12 16:07:08 MST 2014
yea, I had to write a thread safe double ended STL like queue once.
Not something I wanted to trust without a plethora of unit tests.

I guess my point is, the Microsoft model.
Here is a bunch of good stuff.  It might work, it might not, there is no qualification suite or unit tests.
Use it, and report the problems back to us.

I applaud the guy for releasing his code, I am about to set up a git hub public repo for some of my stuff.
Now I will have to have unit tests.   ;-)

[lpcware]

Content originally posted in LPCWare by Pacman on Wed Mar 12 08:53:33 MST 2014
Unless Marc wrote a test-suite, I do not know of any.
But you can try them from within an interrupt; they will work there.  :)
Most others won't pass that test.
-But one thing you can't do is to use them from both task-time and an interrupt at the same time, without adding atomicity.

[lpcware]

Content originally posted in LPCWare by rocketdawg on Tue Mar 11 08:25:17 MST 2014
are there any unit tests for these routines?

[lpcware]

Content originally posted in LPCWare by Pacman on Mon Mar 10 18:28:13 MST 2014
I downloaded it just to see your FIFO.
This is the first piece of code on the net, I've seen that handles the FIFO correctly.
I would like to recommend people to use Marc's FIFO code, and leave their AVR-stuff where it was. Forget about your old FIFO handler, it's buggy. What is copied and pasted from the AVR TechNotes is buggy. Those FIFOs - they drop characters.

Marc's will not drop characters, as it's written properly and with precision.

Good job, Marc, you certainly know what you are doing!