Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24

Well ... strings are only one part of the problem. Any constant tables/arrays, such as:

o state tables o lookup-tables o v-tables

are problematic to most traditional compilers/languages that only understand a single contiguous address space.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
 Click to see the full signature
Reply to
Michael N. Moran
Loading thread data ...

It's that *almost* part that bothers me ;-)

I wish that the C/C++ standards bodies would use the AVR and other "pure" Harvard architecture machines as an example and standardize a set of memory space qualifiers as a part of the type system to address this issue.

That ... along with other systems programming support features such as alignment (for caches, and pages). But that's another thread ...

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
 Click to see the full signature
Reply to
Michael N. Moran

Surely a compiler ought to be able to figure out if data is constant or not, and allocate it appropriately..?

Reply to
Mike Harrison

This has been partly done on the new Embedded extensions TR.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

Mike Harrison schrieb:

and allocate it

The problem is not allocation, but access to variables:

void function (int *something) { return (*something == 1); }

function(ROM_address); function(RAM_address);

To make this work, the compiler would have to generate code that can tell a ROM address from a RAM address at runtime.

Reply to
Andreas Schwarz

LOL, that 2-3K makes a huge difference in products with 16K ROM or less and there are very many of those.

Ian

Reply to
Ian Bell

But surely that is a *compiler* issue not a fault of the underlying architecture?

Ian

Reply to
Ian Bell

Optimization (writing a specialized function instead of using one from the library is nothing but optimization) is done when necessary, and no sooner. If your program with printf & Co. is 14k large and you target a

16k microcontroller, replacing standard functions with specialized code will gain you absolutely nothing, but takes time, is error-prone, makes your code larger and hurts maintainability.
Reply to
Andreas Schwarz

No. To achive true transparency, the compiler would have to generate code that can tell a ROM address from a RAM address at runtime. Otherwise functions that take pointer arguments would not be possible.

Reply to
Andreas Schwarz

used with the upper

In recent parts, there

SRAM), depending on

and skip instructions.

would be better.

jitter...

league on this - you can

really want to.

assembly..?)

within the same product!)

advocates would have

..and you could add

  • No Direct memory opcodes (thus register bottleneck and pointer thrashing)
  • Limited SFR map
  • No Boolean variables/opcodes [well, SOME new devices have a kludge on this.. ]
  • No interrupt priority
  • No register banking, so interrupt switch is clumsy/slow.
  • Poor family portability

But yes, it is better than the '70s 12 bitOpcode PIC cores. (and so it should be). Less of a difference to the newer 16 bitOpCode PICs, and behind the PIC24's.

A key indicator of a good uC, is when you would use it for a NEW design, and the new 32 bit ones, are certainly putting pressure on the larger 8 bit devices.

-jg

Reply to
Jim Granville

In article , Andreas Schwarz writes

printf should NOT be used for debugging at all. some parts only have 2-4 K of program memory.

Only ametures debug with printf on 78 bit micros.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

In article , Andreas Schwarz writes

This is absolute rubbish. A simple function to put a character or two out to a serial line will only be a few bytes long.

As printf has to use this functionality to address the hardware, and you may want to re-direct printf, it is often made available in source form in the library. All you have to do is get the routine. Typically it is only 4-5 lines of C.

Or you could do it yourself but if writing a SIMPLE function like this "takes time, is error prone" should you be programming embedded systems at all?

It will make you code 2-3K smaller and does NOT hurt maintainability at all. IT gains you a lot as it makes the test outputting smaller and faster so it distorts the memory map less than printf and changes the time by a lot less.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

No they don't. Compilers for Harvard architecture understand Harvard architecture very well.

What do you mean by "most traditional compilers/languages"? For embedded use 99% of C programming uses extensions to C and most compilers are specialised.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

Chris Hills schrieb:

Appearantly we have a misunderstanding here. With printf I do not mean a put-everything-on-stdout-C89-printf. Most libraries have a printf variant that takes a function pointer argument for a putc function, or a seperate function to set the printf target. Obviously you have to write this one yourself.

The point I was trying to make is that it is useless to assemble a LCD output by hand (formatting numbers, concatenating strings, padding with spaces) when there is a function like printf that can do it all much easiert, but may take a bit more space.

Reply to
Andreas Schwarz

Chris Hills schrieb:

Some parts have only 512B of memory - so what? Of course there are exceptions.

And what do professionals use?

Reply to
Andreas Schwarz

Printf variants do a lot more than simple printing of constant strings. Otherwise they wouldn't take a few Ks.

Reply to
Andreas Schwarz

Any hardware annoyance can be hidden by a layer of software. Still I think it's fair to think of it as a fault of the architecture.

Reply to
Andreas Schwarz

So it *is* a compiler issue.

Ian

Reply to
Ian Bell

Not true. Library functions are immensely general purpose which largely accounts for their bloat and their inappropriateness in small 8 bit controller products. For simple printing of constant strings a user function is far better.

Ian

Reply to
Ian Bell

Creating a simple putc or put_string is easy.

Creating a custom printf is MUCH better than using a library function many applications do not need

Floats scientific of exponential notation pointer printing long modifiers escape characters (form feed, line feed, bell)

Mnay only need single character or formatted strings with a byte or short (signed/unsigned printing).

To create a custom printf is relatively easy and I have used a few, created and expanded over time to have conditionally compilation for support required (binary, octal, decimal, hex, pointer). Simple formatting for single characters or strings as standard. Some of the conditional assembly for

16bit ranging from 400 bytes to 1000 bytes, depending on the target being developed. Hence code reuse just like using a library, with known overhead.
--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Click to see the full signature
Reply to
Paul Carpenter

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.