Nice MCU for small jobs

tirsdag den 4. september 2018 kl. 03.41.55 UTC+2 skrev snipped-for-privacy@notreal.com:

not really, though I do occasionally program ;)

it was more comparing apples to apples, the STM with the same size flash cost the same as the LPC

Reply to
Lasse Langwadt Christensen
Loading thread data ...

ST gives the choice. The smarter you are, the more you make. Besides, how much abstraction can you stuff into 20 pins? ;-)

Reply to
krw

And what is the problem with peripherals in GCC?

And how a compiler is related to documentation?

--
****************************************************************** 
*  KSI@home    KOI8 Net  < >  The impossible we do immediately.  * 
 Click to see the full signature
Reply to
Sergey Kubushyn

Microchip style. Same diagnosis here. There are just too many alternatives without the silly limitations to waste one's life on something like that.

Best regards, Piotr

Reply to
Piotr Wyderski

Code Red does not use a proprietary fork of gcc. They used to have their own builds (based on the Code Sourcery builds, IIRC), but I believe they have switched to the standard GNU ARM Embedded packages like most other ARM gcc suppliers. They have their own proprietary library, however, as well as Eclipse plugins.

NXP bought Code Red not long ago, and I think their stuff is now integrated in the standard NXP development tools (which also support the Kinetis).

Reply to
David Brown

Those days are long gone.

Reply to
David Brown

NXP owns Code Red, and their current tools - MCUXpresso - are fully free, with no limitations, and use the standard GNU ARM Embedded toolchain. You can also happily use any other version of gcc - including newer versions of GNU ARM Embedded - with the tools.

NXP continues to supply legacy tools that they have picked up along the way - standard Code Red, LXCNEXpressor, Code Warrior (from Freescale) - because there are customers who want to buy new copies of the old tools for consistency. And they continue to charge, because some companies feel happier when they are paying money for the tools.

Reply to
David Brown

These are in the reference manuals, not the datasheets - as has been standard for bigger microcontrollers since I started using them 25 years ago.

The compiler is the compiler - it is not tuned to the specific microcontroller, nor does it have anything to do with the peripherals.

Perhaps you are mixing up "compiler" with "peripheral library" or "microcontroller-specific headers".

NXP - like all microcontroller manufacturers - provides peripheral libraries and headers defining the addresses, structs, bits, types, etc., for their devices. You can question the quality of the library code (I certainly do - but not just for NXP), and you can question the somewhat inconvenient way you get the files these days (with an online package generator). But the files are all available, and cost nothing.

The files concerning the cpu core itself come from ARM, rather than being written by NXP.

No one sane uses assembly on an ARM.

No one sane pays for the microcontroller headers.

Reply to
David Brown

I've been experimenting with not even touching C/C++ for developing simple uP applications, e.g.

which resembles a scripting language like Python, it relies on gcc being pretty efficient at optimization by first transpiling to C++ before compiling and uploading to the target device. There's some overhead generated but ideally what you get is significant reduction in development time.

Reply to
bitrex

As of several years ago at least I recall reading that the IAR compiler for ARM produced more efficient code than gcc, however at that point it was not fully C++1x-compliant it was still more like C++03. That may have changed at this point but either way a commercial license for their toolchain is a couple grand.

I've not done much ARM development but so far for both AVR and ARM gcc has always worked fine for me...

Reply to
bitrex

Long ago, gcc's ARM backend was quite inefficient. Once it got popular, however, it was quickly improved. But commercial ARM compiler companies love to tell you how slow gcc-generated ARM code is, or how limited the compiler is - it's just marketing nonsense. They will happily compare their latest toolchains and optimal flags with an ancient version of gcc with questionable flag choices - and sue anyone who tries to publish their own benchmarks using the commercial compilers.

There can be good reasons for choosing to buy an expensive ARM toolchain such as IAR, Green Hills, Keil, or various others. But performance of the generated code is unlikely to be a sensible reason. The differences in speed are going to be small, and my money would be on gcc winning in most cases. (Performance /measuring/ tools, on the other hand, can certainly be a consideration.)

Standards compliance is also not a reason for picking IAR or others. IAR does better than most commercial toolchain vendors - it currently supports C11 and C++14. gcc - the build from GNU ARM Embedded with ARM backing and support - is on C11 and C++17 for version gcc 7. If you want a cutting-edge toolchain with less testing and support, you get experimental C17/C18 and C++20 support.

The big commercial toolchain companies give you more testing or certifications, development tools for debugging, profiling, etc., static analysis including MISRA, and the warm fuzzy feeling you get from an expensive box, hardware or software license keys to lose, and someone who has to stay on the telephone support line even when you shout at them.

Reply to
David Brown

David Brown wrote

I have now written thousands and thousands of lines of code in C for ARM (Raspberry Pi), using gcc. Apart from some minor reporting issues i have been unable to find any fault with gcc.

But then again I have.. thou... PIC 18F asm with gpasm and ... never an issue.

Faster ARM C compiler than gcc? Maybe, but if your code is that critical I would look for the bottle necks and fix that, because it likely sucks. All those debugging tools? Who needs them, use printf().

Stability? root@raspberrypi:~/compile/pantel/xgpspc# l xgpspc

-rwxr-xr-x 1 root root 329616 Sep 3 10:38 xgpspc root@raspberrypi:~/compile/pantel/xgpspc# uptime 16:55:36 up 111 days, 8:13, 9 users, load average: 1.64, 1.52, 1.51

xgpspc is multithreaded, has build in servers, build in sensors, complex graphics in X, lots and lots of maaz... GPS, steering control, various alarms, voice messages, radio control, system alert messages via porto, radio remote control via SMS, the list is endless. and I use hardly any libraries apart from libmaaz, libxaw and libjpeg. $(COMPILER) -o xgpspc $(XGPSPC) -lm -lpthread -lXaw -ljpeg

Now those other languages, like boa-constrictor or rattle-snake or whatever was it seepplushplush what's next? Iwant just say (no more typing, soon nobody will be able to read and write anyways in the US, especially when you wear .... shoes...) what you want and the system will write the code, it likely will design the hardware too, and do the layouts, and there you are.

Any idiot can learn to write 'hello mama' in those snake languages, or +- languages.

Programs written by people who do not know how a compiler works, do not know asm, do not know binary. do not know how a computer works, how a processor works, and have no clue about the hardware. For ever victim to advertised bloat by for profit companies some sucking on taxpayer money F35 Face it, its over. :-) Oh, and all you wize cracks, publish your code if you dare. Open source is the way to go, and to learn.

This morning I wanted to stay out of this, and I should, or shoot, whatever,

I like my PICs, and this morning I was thinking if I could write the same xgpspc code in PIC asm, and really, there is a lot you can do with a 32 bit math library (you learn that integer fiddling when programming FPGAs in Verilog), no need for sinking-point or what was it floating-point in most cases if not all cases, done it in scope_pic for Fourier transform, Sometimes IF YOU KNOW WHAT YOU DO asm is simply simpler.

Reply to
<698839253X6D445TD

tirsdag den 4. september 2018 kl. 04.58.43 UTC+2 skrev snipped-for-privacy@notreal.com:

so does LPC, the 16kB is called LPC802 ;)

Reply to
Lasse Langwadt Christensen

C++11 ARM gcc, you can write a circular buffer implementation where you can create a buffer for any fundamental type or object by changing one line (119, 125) and then use it transparently. the compiler generates the appropriate code for whatever type you pick at compile-time, WYSIWYG on the right. with optimization flag about half the lines don't generate any asm at all. Takes about 15 min to write, none of these tools cost any money

Reply to
bitrex

bitrex wrote

Yes, but circular buffer is basics in C, you can set your sizes and types too.

Personally I think C++ is a crime against humanity, operator overloading comes to mind, it is just designed by somebody who did not want to bother to understand the beauty of C ;-)

There is one born every week? That goes for 'puter languages too.

Long ago there was a magazine, Dr Dobbs IIRC, it had nice examples of code in C. I learned some tricks from that,

Maybe it still exists..

Linked list is something I really like too, this Usenet news-reader is based on that.

formatting link
All C. That was my first big C program, when was it, Linux, 1998?

When programming in C for ARM (or any processor) I do not even want to see the asm. Never had a problem with gcc.

Of course over the years you build your own libraries, I very often fall back on code I wrote maybe years ago, like drivers for various protocols and chips etc. At least you know it has been working OK all those years.. That goes for (PIC) asm too.

I do notice I am not coding for maximum efficiency, I did notice myself using type double for a lot of navigation stuff where I could have used smaller sizes, then later making it back into integer. This is fun, on raspberry, in C, wget

formatting link

Input data is from dump1090 (rtl-sdr) like this: Hex Flight Altitude Speed Lat Lon Track Messages Seen .

--------------------------------------------------------------------------------

4ca4f2 0 0 0.000 0.000 0 1 9 sec 484f7d 9115 0 0.000 0.000 0 5 52 sec 86831e 10654 883 53.265 6.064 237 104 11 sec 4007f5 BAW169 10052 892 53.428 5.442 55 512 0 sec 4851f6 6031 805 52.972 5.766 52 17 31 sec 4ca4f7 RYR286X 11575 824 53.102 5.709 234 186 10 sec 424944 AFL2582 10357 827 53.016 5.453 236 394 0 sec

As soon as 2 data points for teh same plane are in, you can calculate heading, distance, angle, and where to look from your position, say 8 o'clock. On the fields next to the plane in the AVI top one is the flight number, next is altitude heading (calculated) of the plane speed magnetic compass direction to point to it (calculated) followed where to look for it on a 1 to 12 clock dial (calculated) followed by the elevation from your POV (calculated) then true distance (calculated) note the elevation going to 90 degrees when it flies over head of the yellow boat, and the true distance reducing to the altitude. The 'boat' can be my drone, it was basically a collision avoidance code, but the mil planes here do not send position data. Still you can use it to aim your camera or binoculars at the things. I switch north up versus heading up a couple of times to show the difference. Just a few lines of C.

display and some calc root@raspberrypi:~/compile/pantel/xgpspc# l planes.c

-rw-r--r-- 1 root root 24720 Sep 2 09:39 planes.c

great circle and some math I did root@raspberrypi:~/compile/pantel/xgpspc# l navigation.c

-rw-r--r-- 1 root root 23159 Sep 3 09:31 navigation.c

receives, among many things, output ofdump1090, like listed above root@raspberrypi:~/compile/pantel/xgpspc# l udp_server.c

-rw-r--r-- 1 root root 18765 Aug 26 17:10 udp_server.c

'l' is short for ls -rtl in bashrc

All structure based { char *name; char *flight; int altitude_m; int speed_kmh; double latitude; double longitude; time_t update_time; double heading; double distance_to_plane_km; double heading_to_plane; int direction_plane_h; double elevation; double true_distance_to_plane_m; struct plane *prventr; struct plane *nxtentr; };

too much type double, but you get lazy...

Pressing '$' in the interface switches between metric and imperial unuts.. I mean units.

And we play along...

xgpspc (very old version) is here

formatting link

...

Reply to
<698839253X6D445TD

Not sure that "beautiful" is how I'd describe C. It might be best to think of C++ as two languages. The first is a relatively simple C-like statically typed compiled language not that much different than C99, but not entirely compatible (e.g. no variable-length array arguments) which would've been familiar enough to coders in the 1980s. 1970s, even. it compiles to efficient asm same as C does.

The second is a powerful modern meta-programming language used to arrange the C-like stuff into (ideally) zero-overhead abstractions. that's for the purposes of generic-ism and re-use and mostly for the programmer's benefit, a lot of the "magic" is accomplished at compile time.

If one isn't leveraging the second part for effect I can see not much reason to prefer C++ over C. wrapping straight C-style code inside classes is not OOP, nor is even using classes at all, intrinsically, or inheritance or any of that stuff.

Many will enter, few will be remembered. I don't really have strong opinions about one language or "style" of programming being better than another, they're just tools use what is appropriate to the job. Some are easier for me to get to grips with than others for some reason C++ seemed to click with me in a way others didn't but that's a personal quirk.

Happily modern C++ compilers produce pretty efficient code even on resource-limited architectures, even 8 bit.

I do know most "desktop guys" in their 20s and 30s who write apps and Web back-ends etc. are mostly entirely ignorant of what these little $1 processors can do in 2018; if they know anything about embedded it's often from a university class on computer architecture where they studied the 6502 and think that micro-controller evolution stopped in

1985. "you're writing C++ for an 8 bit?! you can't do that! it'll be bloated and slow! using templates and virtual methods will ruin you! how can you do anything without an MMU and 6 gigs" etc. all mostly nonsense.

Where I can definitely learn from the "desktop guys" is their computer-science-type knowledge of data structures and algorithms is usually more sophisticated than mine is; the world has moved on quite a bit since the 1980s and 90s wrt containers and stuff.

The linked list is a classic and a good performer for small to medium data sets (thousands to tens of thousands of records) but poops out for large ones (e.g. hundreds of thousands, millions.) at those sizes the vector structure i.e. resize-array, shove down, and insert performs better - the link traversal ends up being a bottleneck on modern architectures.

Reply to
bitrex

Yes it's easy enough to write multiple functions for the primitive types and have circular buffers for char, int, float, etc. But that implementation example works for _anything_. It can just as easily be circular buffer for a user-defined struct, whatever it is, whatever it contains, maybe it holds 20 pointers who knows. or even a whole object, whatever it is.

No need to do any extra work except change one one line and then the compiler decides what needs to happen to create code for your particular use-case.

Reply to
bitrex

bitrex wrote

Na ya, bringing a screwdriver set from size 1 mm to 1 meter every time you need to tighten one small screw is a bit heavy and in increases workload, space used, efficiency, fuel consumption and causes glowball worming I'm sure. It may damage the screws if you pick the wrong tool, and you lose your view of proportion. It is more expensive and slower, ... :-)

Reply to
<698839253X6D445TD

bitrex wrote

Sure, linked list is not the only thing I use in C. An other thing, also used in xgpspc, is the worldwide list of ships, basically ALL ships in the world that have radio are in that list:

-rw-r--r-- 1 root root 31637292 Oct 3 2016 listv.tx

31,637,292

31 MB that looks like this:

203013200 OEX2023 APSYRTE AUT PL MTB W25884 2,30 7 V SRI: VHFDSC

When a radio message is received from a ship it contains the MMSI (the first number on the previous line), and xgpspc has to look it up in the list to get the ship-name, what it is, etc... In that case we first sort the list by number ONCE, and then do a successive approximation search and have the answer in a few ms for every message. No plush plush needed,

Maybe a hundred lines of code..

An other case of big data is the 'ip_to_country' program:

formatting link
It uses a database of all IP addresses in the world.

-rw-r--r-- 1 root root 25410368 Jul 17 16:10 ip-to-country3.csv

25,410,368 Its entries look like this "16778240","16779263","AU","AU","Australia I once sorted the list by number, and from then on successive approximation finds the country in a few ms. ip_to_country looks for illegal server requests (hacking attempts) and can automatically add IPs to the firewall.

Look at the code, just basic libc. latest version not on the website has some more scripting capabilities. Need to update website... maybe in the cold winter days if glowballworming allows those to happen...

,, in the time needed replying to computah language wars I can write a completely new program...

Reply to
<698839253X6D445TD

Slower for the compiler, maybe. Not my problem how hard the compiler has to work that's what all those 8 cores running at 3 GHz or w/e are there for. You can see from the example the compiler doesn't generate any push or pop routines for anything you don't use.

I couldn't tell ya offhand how to implement any given container for any given struct in C and thankfully in 2k18 it's not always required to think too hard about it.

Reply to
bitrex

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.