I read all other progmem related topics but none of these works for me
I have a pretty big program which should still be uploaded to a mega and in the future to the due. so i hope to have only one source instead of two.
Because my complete menu which is a static list and never change without a new upload i created the menu structure in progmem which i filter out with sscanf_p
Due doesn't have PROGMEM. You can't read flash memory at all, you can only execute
it as code, this is a basic security measure on the chip. From outside the chip you can't
read the flash either, you can only erase it totally then write it I believe.
And because of that, the thread owner is using all those preprocessor macros, to make PROGMEM and the corresponding functions disappear!
And of course, you can read flash memory! You can store constant data there! In the AVR world it is tricky, so PROGMEM was introduced. In the ARM world, such tricks are not needed.
The poster tries now to write compatible code, which can be translated for the AVR world and the DUE, so he needs those macros!
However the thread owner needs to post more of his code, as it looks like just as an preprocessor issue.
When he writes:
All of the mentioned lines start with n=sprintf_P(Tekst, PSTR("
he has cutted of the more important piece with the closing bracket, which is mentioned in the error message.
everything i send to the serial port, log to a file or show on the tft screen is now declared as progmem.
or with the PSTR or with the prog_char command
And because i also want to use this code to upload to a mega i don't want to delete all progmem defenitions from my code.because then i need to write every change , fix or new feature twice.
I understand that if i delete everything and declare it as a normal constants it works but then i cannot upload it to a mega anymore.
if you need more or something else just say it and i will send it.
as far as i know the compiler already change these lines if you compile for a due.
But the PSTR things are the biggest issue .
whatever i try it keep failing on that one
Thanks for the simplified example code, it really does make debugging these problems much easier.
Firstly the PROGMEM compatibility code is already in avr/pgmspace.h which is automatically included, so you don't need most of the big #if block. The problem is that there are two bugs in pgmspace.h:
sprintf_P only works if there are 3 or more arguments. There's not much point using sprintf with only 2 arguments (strcpy is better), however I think for consistency it should work.
sscanf_P isn't there at all!
To work around this, change the #if block to just contain the following:
thanks for that information. Comparing pgmspace.h with the defines posted above, I see only one more difference: #define F(X) (X) should also be included.
I think, that this should be included in pgmspace.h.
I see no advantage of the current define: #define sprintf_P(s, f, ...) sprintf((s), (f), VA_ARGS)
compared to your pragmatic #define sprintf_P sprintf
I added them,
compiling runs without errors
But when i run the program on the due (test code) i only receive one line of text in my output instead of three
The first is perfect but something is still missing in de defines (i think) for the other lines
You are using pgm_read_word to read an address, but pgm_read_word is only 16-bits. That might work on a Mega (and even then only for 'near' addresses) but it won't work on a Due, which uses 32 bit addresses.
The chip does support this security model where the flash cannot be read, but there
is a control bit that enables it - section 9.1.3.5 "Security bit feature" - I clearly rememberd
the description of the mechanism but not that it was optional.
MarkT:
Ah, I am wrong (but right in some weaker sense).
The chip does support this security model where the flash cannot be read, but there
is a control bit that enables it - section 9.1.3.5 "Security bit feature" - I clearly rememberd
the description of the mechanism but not that it was optional.
I think, that you are still wrong with that. This is a mechanism to protect your code from being read out by external programmers, JTAG devices etc., but not from preventing you, to initialize variables in the flash. The ARM architecture is here little bit different from the AVR architecture.