The point is that to get constant data in flash, you need to go beyond the usual C syntax (such as by using a "flash" keyword or "progmem" macro) - your code is even uglier than standard C. It is also inconsistent between different compilers for the same target. (Some avr compilers misuse "const" to mean flash - that works fine for simple code, but can cause problems for some code.)
ISO/IEC 18037 adds named address space that makes multiple address space access a lot easier. Many non Harvard architectures have multiple address spaces.
The other thing that happens as soon as you use tools that support multiple address spaces is devices on I2C buses suddenly become more accessible and easier to add as part of a design.
Yes, but so far, that has not been a problem, since the AVR has been fast enough and power consumption has been low enough.
Compared to an AVR implementation with a shared bus. The study was done during the design of the AVR core, but it is before my time, so I do not have any details.
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB
I haven't read through the new standard yet, but it will be good to get a single consistent way to handle this sort of issue. Of course, it will probably take a decade or so before it is implemented in enough C compilers to make it a portable solution - there are still compilers on sale that view ISO C90 as the bees knees.
ISO 18037 also seems to standardise hardware access (I've got as far as the contents page), but it does not tackle interrupts - it would have been nice if there were a common way to specify interrupt functions and other non-standard ABI functions.
That can have its good sides and its bad sides. It would certainly be convenient to be able to read and write things like EEPROMs like normal memory. But it can also lead to problems - reading data over an I2C bus, for example, is going to be a lot slower than reading it from local memory, and it could give you conflicts if the bus is shared with other peripherals. I'll read some of the ISO document before commenting further, however.
No doubt they were considered at that time (although I find it hard to believe that a shared bus version would have been made) - but the AVR core was initially designed with slightly different priorities than if one were to design a cpu to take the place of the current AVRs. When the AVR core was designed, things like die space and the simplicity of integrating it in Atmel's ASICs were more important than its convenience for C compilers. If one were to make a new, modern version without requiring binary compatibility, then it would have a single address space (with separate buses for speed, of course - just like most modern cpus), more pointer registers, better stack pointer access, and more
It is not a standard, it is a Technical Report so it can safely be ignored. And I'm sure it will be. Hell, C99 isn't pervasive yet.
The TR doesn't address the issue of what qualifiers you can legitimately use. They will be implementation-defined.
As I said, it codifies only where you place namespace qualifiers, it does not codify what you mean. So it's a free-for-all in the implementation and portability is certainly not assured. I agree with you that C90 is just fine for embedded work, C99 is a standard that should never have been accepted IMHO (sorry if there are any ISO WG members here, it's not personal it's just business as they say).
It tries to standardize and what is inherently non-standard. I see absolutely no value in the I/O "abstraction", it's not portable so why try to make it so?
That would be difficult, IMO. Interrupt controllers are shockingly bad sometimes. I think Motorola had interrupts working pretty well on the MC68000 so long ago.
ISO 18037 has multiple sections. The definition of fract and accum data types was long overdue.
Named address space and user defined address space opens the possibility that applications can place data in slow memory by design and that memory space can be managed by the normal symbol table manager. We have quite a few high volume appliance customers that use this technology to manage unused RAM in many generic LCD controllers for application storage.
The combination of named address spaces and the new data types suddenly made it possible to create portable in C dsp code that didn't by necessity have to be written in asm. There are many portable DSP applications being written in Cell phone and automotive applications.
I buy your comments about standardized interrupt support.
C99 did a number of things that many compilers were implementing independently. // comments and size specific variable types to name two.
ISO/IEC 18037 is important as the first cut to define of fract and accum data types. Named and user defined address spaces and full access in C to processor registers brings C back to its roots.
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.