metermannd
- Joined Oct 25, 2020
- 343
The last time I posted some code in a C-related forum I got yelled at for using GOTO...!
https://forum.allaboutcircuits.com/...sing-static-code-analysis.167064/post-1483170The last time I posted some code in a C-related forum I got yelled at for using GOTO...!
Wow. Great minds and all that.Great answers above but:
Some people might get the wrong idea about short shorts.
It wasn't all that long ago that nearly all MCU programming was done directly in assembly. The reason is that, historically, MCUs were extremely resource-starved. For instance, the PIC16C55 had 24 bytes of RAM and 512 words of ROM for the program.Why microcontroller programming is mostly done in low level language like assembly language, c language? why is there no high level language like java dot net.. ?
Does the many compiler support only C and C++ that's why they are used or are there other reasons?
There's a lot of interest and talk about .Net, particularly now that .Net Core has matured and brings huge improvements, simplifications and greater portability.Why microcontroller programming is mostly done in low level language like assembly language, c language? why is there no high level language like java dot net.. ?
Does the many compiler support only C and C++ that's why they are used or are there other reasons?
Floating point arithmetic is very expensive in most embedded processors. Remember, it was enough of a bottleneck that up until the 80486 there were separate (end quite expensive) chips called "math co-processors" whose primary purpose was to perform floating point arithmetic in hardware.Seems there is something called "embedded C" which I've never heard of before:
https://standards.iso.org/ittf/PubliclyAvailableStandards/c051126_ISO_IEC_TR_18037_2008.zip
There's an emphasis on fixed point arithmetic, didn't know that was a big deal in embedded work.
Yes, I recall those, I have an old one too in my little historic chips collection here! I recall when I was working on another compiler many years ago, looking at licensing a floating point library for the Intel 386 family that some firm produced, this was to support floating point math without a coprocessor.Floating point arithmetic is very expensive in most embedded processors. Remember, it was enough of a bottleneck that up until the 80486 there were separate (end quite expensive) chips called "math co-processors" whose primary purpose was to perform floating point arithmetic in hardware.
Since many MCUs can't even multiply and divide, let along do floating point operations, this has to be done in firmware -- often on a platform with a slow clock speed and very limited RAM/ROM resources.
I love APL too, a very under appreciated language. Tom Iverson was primarily interested in "Notation as a tool of thought" and won the Turing prize for this, with a paper of the same title.Two very progressive and innovative languages are Forth and APL.
APL stands as one of my favorite languages.
SPI is dead simple in basic principle but there are a thousand variations on how it's implemented (for max efficiency, highest speed and lowest cpu usage) on each processor and what's the method (software,, hardware polled, interrupt, DMA) of the data interface....
A core goal - speaking personally - is the abandonment of the antiquated and troublesome C grammar, brining a much cleaner syntax that's easily extensible, into the mix.
Other goals might be native language support for common things like SPI and so on, rather than relying on external libraries. Since things like SPI are (often) standardized, that kind of stability means it could be part of the language in principle.
Now touch works but the XY screen origin is reversed, another few lines to fix for this variation of touch-screen.** 01, 02 or 04 for AccuTouch controllers; 81, 82 or 84 for IntelliTouch controllers
I still have a manual on how to implement APL on a microcomputer. I never got around to doing so.I love APL too, a very under appreciated language. Tom Iverson was primarily interested in "Notation as a tool of thought" and won the Turing prize for this, with a paper of the same title.
I was seeking to have the F# language expand its allowed alphabet so we could create functions named after the APL function (using the very same symbols, they are all part of Unicode) you can read a bit about that here.
I just didn't have the time to push this much so its kind of fallen by the wayside. The core point was for me, that many APL operators are truly powerful and don't exist much in either the imperative or functional world.
The lex tools they used were quite difficult for me to fathom too.
This is good, works well if you want to play around:I still have a manual on how to implement APL on a microcomputer. I never got around to doing so.
I did have APL running on a Z80 CP/M system which I used quite extensively in is time.
A very good way to evaluate an idea like a new embedded language is to - initially - generate C code from the input source. This means one can get a basic implementation and run something actually built from the new language.SPI is dead simple in basic principle but there are a thousand variations on how it's implemented (for max efficiency, highest speed and lowest cpu usage) on each processor and what's the method (software,, hardware polled, interrupt, DMA) of the data interface.
https://ww1.microchip.com/downloads/en/DeviceDoc/61106G.pdf
Native language support is a pipe dream for sure.
Some spi driver C code for RIOTOS with DMA and FIFO support.
https://github.com/nsaspook/RIOT/blob/PIC32MZEF/cpu/mips_pic32_common/periph/spi.c
Long term stability is a big problem that C is really good at.
Just today a 30 year old CRT touchscreen system that I converted (wrote new controller firmware to translate the new serial touch protocol to the ancient binary serial touch protocol) to a ELO IntelliTouch LCD 15 years ago was replaced (by the parts managers because of shortages) with a new version of the ELO AccuTouch LCD screen that changed the SmartSet status codes for touch responses.
A one-liner in the C code fixed the problem.
https://myelo.elotouch.com/support/s/article/SmartSet-Data-Protocol
Now touch works but the XY screen origin is reversed, another few lines to fix for this variation of touch-screen.
Handling the infinite variations of standard protocols is what drives you mad, not the language grammar.
I see the C language restriction of adding new keywords as a long term language stability feature. There a plenty of ways to 'add functionality' in the existing C framework using the C pre-processor.Well the grammar can/should strive to make it easier to work in some domain, for example one can do OO in C if they want but languages like Java and C# make it much less effort because they fit the OO domain more closely.
You speak of memory mapping details, I'm not familiar enough with these chips to yet appreciate what you mean, but if this were inherently represented in a language then this could help developers understand the domain better surely?
A huge weakness in the C grammar (and all derivatives) is the inability to add new keywords without braking backward compatibility, of course this is a general feature not domain specific, but being able to add keywords would enable brand new functionality to be added with no backward compatibility issues, so I place a lot of emphasis on this but as I said, its not peculiar to MCU code.
#define two 2
#define times *
int four = two times two;
Adding new keywords does not introduce "instability" unless the grammar has reserved words.I see the C language restriction of adding new keywords as a long term language stability feature. There a plenty of ways to 'add functionality' in the existing C framework using the C pre-processor.
That's not adding a new keyword. A new keyword might be something like:Code:#define two 2 #define times * int four = two times two;
if (a > 100)
activate
{
// stuff pertaining to "activation" some new hitherto unknown, language keyword.
}
That can't be done today because any user created identifier "activate" breaks the compile. The keywords of C are a small finite number and forever fixed, cannot be expanded.
Right, but I have not been and am not advocating OOP, simply arguing that a new language specifically addressing the problem domain of MCU's might have its merits, and explaining why I find C past its use by date in some respects.The embedded programming domain is still filled by people with a hardware engineer mentality that program to make things work. The means most of us see software problems (engineering schools drill this into your brain) as mechanical, with mechanical physics solutions (as a firmware engineer) instead solution based on a hierarchy of artistic prose with things like OOP. The HW engineering brains I work with see the the current push of OOP languages as a waste of good space in your head but we also spend the time to be familiar with the hype just in case there might be a nugget or two buried in the heap of fantastic virtues expounded for using those principles.
You might well be right, I am just speculating for the sake of argument. remember my core complaint is that C is a poor language, with no scope for new keywords and so on. For example adding keywords like "async" or "await" is impossible because the grammar has reserved words.There are plenty of languages that map hardware requirements in formal languages like HDLs but most are very domain specific. The more you know, the less you would think adding things like SPI native language support to a GP computer language is a good idea.
and adding new keywords to C or the existence of reserved works is a problem that doesn't really exist for the vast majority of embedded programmers. A few new reserved words have been added over the years in C99 and C11.Adding new keywords does not introduce "instability" unless the grammar has reserved words.
by Jake Hertz
by Duane Benson
by Jake Hertz
by Jeff Child