I used to think I knew how to iterate through an array. Thanks to Padauk I have to learn new stuff!
Usually I would do a for loop with a counter - arrayname[count].
In Mini-C this doesn't work for constant fixed arrays. So new approach!
Arrays are basically pointers right? Yup.
word scale[7] = {1,2,3,4,5,6,7};
word point;
byte output;
point = scale;
output = *point; //output == 1;
point+=2;
output = *point; //output == 2;The above works! Yay!
As soon as I try to save in ROM, everything breaks though :/
const word scale[7] = {1,2,3,4,5,6,7};
word point;
byte output;
point = scale;
output = *point; //output == random garbage :(
point+=2;
output = *point; //output == random garbage :( In "Mini-C" project, the constant data of ROM can be declared as follows:
CONST WORD array_name [] = { 0x1234, 0x5678, 0xABCD };
How do I iterate a fixed array in ROM in "Mini-C"?
When trying this sample code example I get "Syntax error !!!" from *Point$L
// Table -> Buffer
WORD Pnt2;
BYTE buffer [0x20];
Point = Table;
Pnt2 = buf;
while (1)
{
*Pnt2 = *Point$L;
if (A == 0) break;
Pnt2$0++;
*Pnt2 = *Point$H;
if (A == 0) break;
Point++;
}Is this a question for Padauk or does anyone here see something obvious I'm missing? EEVBlog forum is the closest to a Padauk-forum I can think of
$ cat -n pdk.c
1
2 #include <stdint.h>
3
4 int main(void)
5 {
6 uint16_t scale[7] = {1,2,3,4,5,6,7};
7 uint16_t point;
8 uint8_t output;
9
10 point = scale;
11
12 output = *point; //output == 1;
13 point+=2;
14 output = *point; //output == 2;
15 }
16
$ sdcc -mpdk15 pdk.c
pdk.c:10: error 47: indirections to different types assignment
from type 'unsigned-int [7] fixed'
to type 'unsigned-int fixed'
pdk.c:12: error 27: Pointer required
pdk.c:14: error 27: Pointer required
Normally you should get a warning. Use a pointer like "word *point"
I think your code works by accident when you put the array in RAM. If you were to declare another variable before the scale array, it would probably break.
As Eturtle already pointed out, you need to work with pointers to do what you are trying to do. The other way is to index the array like scale where i is [0..6]. Do note that you index positions of the declared size, not bytes in this case.
Thanks for the input!
I don't have the documentation available at the moment, but I'm sure I read "any WORD in Mini-C can be a pointer".. I read that as - they don't have to be declared as pointers to be pointers.
The Padauk IDE is a lot of fun.
At least, that's what I get from the sample code I pasted. In the Help -> "Refer source" menu in Padauk IDE (0.85)
// Table -> Buffer
WORD Pnt2; //See this pointer declaration?
BYTE buffer [0x20];
Point = Table; //See this pointer declaration?
Pnt2 = buf;
while (1)
{
*Pnt2 = *Point$L;
if (A == 0) break;
Pnt2$0++;
*Pnt2 = *Point$H;
if (A == 0) break;
Point++;
}
What would the "normal" way of referencing a "const uint16_t[7]" array look like?
Here is my complete testing code. Reading from RAM works, reading constant array from ROM doesn't. Maybe it's a bug - the $L, $H and $W byte selectors don't work either(syntax error). I added the example code from the "get rolling code" example, in the beginning.
//.CHIP PMS150C
#include "extern.h"
word junk;
const word Table[5] = {101,102,103,104,105};
word Table2[5] = {106,107,108,109,110};
WORD Point1;
WORD Point2;
void FPPA0 (void)
{
.ADJUST_IC SYSCLK=IHRC/2 // SYSCLK=IHRC/2
// Insert Initial Code
WORD Point, L_Roll, H_Roll;
Point = _SYS(ADR_ROLL); // Use the built-in constant _SYS(ADR_ROLL) to obtain
// the address. Generally, the space should be in xxxA
// L_Roll = *Point$W; //C:\Users\Anders\ArrayTest\ArrayTest.C(23): Syntax error happen !!!
L_Roll = *Point; //L_Roll == 0 in ICE
Point$0++; // hence, it¡¦s not necessary to add High Point
// H_Roll = *Point$W; // Syntax error happen !!!
H_Roll = *Point; //H_Roll == 0 in ICE
Junk = 0x1234; //Adding random data to RAM
Point1 = Table;
Point2 = Table2;
WORD test;
WORD test2;
WORD test3;
WORD test4;
test = *Point1; //Test == 0 (Fail)
test2 = *Point2; //test2 == 106d (Success)
Point1+=2; //Increment pointers one word
Point2+=2;
test3 = *Point1; //test3 == 17d (Fail)
test4 = *Point2; //test4 == 107d (Success)
while (1)
{
// ...
// wdreset;
}
}Compile ...
C:\Users\Anders\ArrayTest\ArrayTest.PRE
C:\Users\Anders\ArrayTest\ArrayTest.C
Link ...
memory 0x0 ~ 0x3F are free
Use 30 memory, Remain 34 unused memory
Check Sum is 0x6616CA
PMS150C : ROM Size : 0x3F0
PMS150C : Last use Code : 0xBD , Remain Free-Code : 0x333 [+37]
0 error(s), 0 warning(s)
I think I figured it out. PMS150C which I've been using in my test doesn't have the ldtabl and ldtabh instructions *SIGH*
I guess this means I can store data in ROM, but I can't read it out this way. In fact I don't see any instructions in the datasheet for reading out ROM at all.
Is there a way of getting around this? What's the most efficient and practical way of storing and iterating through a sequence of fixed/constant data?
This sounds very much like the old 12 and 14 bit PICs where there was no way to directly read program memory. For const arrays in program memory you had to store a bunch of "retw x" instructions where x was one 8 bit array value, and then perform a call followed by a calculated jump into the array of retw x instructions.
The PIC compilers used to do this automatically, you could use normal array index notation, but perhaps the Padauk compiler is a bit less advanced. There is some more information on
this thread with a possible code sample.
Great info! I'm not sure it's the best way, but it looks like it works better than what I'm doing now.
Macros are another way of getting around this - Padauk IDE supports for loops with values like this:
.FOR octave, <O4, O5, O6, O7>
tm2s = octave;
.FOR note, <Cn, Dn, En, Fn, Gn, An, Bn>
tm2b = note;
.delay(800000);
.ENDM
.ENDM
While there might be some challenges in working around the limitations of Mini-C, I'd suggest to just use the free toolchain instead. You get a proper C compiler, and it works well on various host systems.
AFAIK, the only real advantage left on the Mini-C side at this point is support for the pdk16 architecture and support for more devices (but I don't expect the latter point tolast for long).
As Eturtle already pointed out, you need to work with pointers to do what you are trying to do.
Separately from the ROM-vs-RAM question... while this may "work", it's bad practice at best and dangerous at worst. You really DO need to explicitly declare something as a pointer to use it as one. Just because the compiler is weak enough to allow you to get away with it - this time - doesn't mean you can rely on that behavior going forward. What if an update to a given compiler makes it more compliant with the language standard?
You're incrementing the variable "point" by 2 because YOU know you're using it to address words. The compiler doesn't know that. Things could get weird, fast.
The inverse of what you're doing here is far more safe: You can treat a pointer like a variable. Declare "word* point;" and do whatever you want with it. Now the compiler knows what you're doing, you don't have to (remember to) adjust its value by 2 instead of 1, if you change the size of the array elements (say you realize a byte is sufficient, or a dword is needed) you don't have to go back through your code and hope you found all the places where you manually accommodated the size of a word, you're immune from compiler updates, etc. And if you need the actual value of the pointer? Just use it without the leading asterisk.
If you absolutely must use a non-pointer as a pointer, at least give the compiler (and the next human that reads your code) a hint with an explicit cast: "*((WORD*) point)". Compilers do support what you're trying to do, though it's definitely less desireable than declaring the pointer as a pointer.
I'm not being critical, just trying to help you navigate the minefield. Hope this helps!
As Eturtle already pointed out, you need to work with pointers to do what you are trying to do.
Separately from the ROM-vs-RAM question... while this may "work", it's bad practice at best and dangerous at worst. You really DO need to explicitly declare something as a pointer to use it as one. Just because the compiler is weak enough to allow you to get away with it - this time - doesn't mean you can rely on that behavior going forward. What if an update to a given compiler makes it more compliant with the language standard?
You're incrementing the variable "point" by 2 because YOU know you're using it to address words. The compiler doesn't know that. Things could get weird, fast.
Wait, what? I interpreted the code Eturtle posted as "here is the code you had, but somewhat compiling" but the important bit is the last sentence in his post - "
Use a pointer like "word *point"".
Unless one has very special reasons to do so (and can articulate these reasons) you should of course always use pointers with the correct data type so that the compiler understands what you are doing. That goes without saying. If my previous post is misread as implying anything else, that is a mis-interpretation.
If my previous post is misread as implying anything else, that is a mis-interpretation.
Nope, you and I are in complete agreement. I quoted you, quoting eTurtle, to give both of you credit. I was trying to help the OP understand the point you were both making, that it's better to make things clear to the compiler as opposed to exploiting/relying upon some workaround (or perhaps partial/imperfect implementation of the language).
I completely understand the point - in C, declaring pointers correctly is a must and you must be careful working with them.
In Padauk Mini-C though - declaring pointers as pointers is a syntax error. I think the compiler know's from the way you reference them though.
The MiniCRef has nothing to do with Padauk Mini-C - it's a "mini" C-reference, not at "Mini-C" reference.
#include "extern.h"
word test[5];
void FPPA0 (void)
{
.ADJUST_IC SYSCLK=IHRC/2 // SYSCLK=IHRC/2
// Insert Initial Code
byte testcounter;
testcounter = 5;
do {
test[testcounter] = 0; //Syntax error: C:\Users\Anders\Desktop\ProjectNy\ProjectNy.C(17): Here need a value !!!
} while (testcounter--);
while (1)
{
// ...
// wdreset;
}
}
Above produces a syntax error.
Compile ...
C:\Users\Anders\Desktop\ProjectNy\ProjectNy.PRE
C:\Users\Anders\Desktop\ProjectNy\ProjectNy.C
C:\Users\Anders\Desktop\ProjectNy\ProjectNy.C(17): Here need a value !!!
PMS150C : ROM Size : 0x3F0
PMS150C : Last use Code : 0x80 , Remain Free-Code : 0x370 [+37]
1 error(s), 0 warning(s)
What that means is - you can't index it that way.
The correct way is using pointers. Which have funny declarations in Padauk Mini-C...
The MiniCRef has nothing to do with Padauk Mini-C - it's a "mini" C-reference, not at "Mini-C" reference.
No, it is not a mini C-reference. It is a reference for MiniC. Not sure if that is exactly what Padauk uses but it isn't a C reference.
The MiniCRef has nothing to do with Padauk Mini-C - it's a "mini" C-reference, not at "Mini-C" reference.
No, it is not a mini C-reference. It is a reference for MiniC. Not sure if that is exactly what Padauk uses but it isn't a C reference.
It's an
educational compiler used by a universities computer science department, not related to Padauk micros in any way.
Hi Padauk Experts
I am writing a code which again needs to iterate through constant values. ( array)
I checked the assembly mnemonics and could not find any instructions which can pick data from ROM.
Basically looking for similar in padauk for MOVC A, @A+DPTR in 8051.
best solution till now i see is
.FOR lv_i, <0x00,0xAA,0x00,0x55>
PA = lv_i;
.delay(1000);
.endm
I need to do this for 50 different arrays. and writing loop for all arrays will eat my ROM.
any better solution ?