C historically relied on binary operators to handle bits within an integer (The CPU's register size). Mirroring the fact that general CPUs don't have bitwise instructions either.
@ersmith I just hit a snag in making my HyperRAM driver compile with both Fastspin and PNUT. This was the last thing I need to sort out before release.
Chip's SPIN2 documentation shows this information about how to method pointers:
Method pointers are then used in the following ways to call methods:
LongVar() 'no parameters and no return values
LongVar(Par1, Par2) 'two parameters and no return values
Var := LongVar():1 'no parameters and one return value
Var1,Var2 := LongVar(Par1):2 'one parameters and two return values
Var1,Var2 := POLXY(LongVar(Par1,Par2,Par3):2) 'three parameters and two return values
I pass a callback method into my programFlash and when I try to call it, Pnut seems to want to know the number of arguments it will return. It needs the :1 on the end in order to compile in PNut.
PUB programFlash(addr, srcHubAddr, byteCount, callBack, flags) : r | size, burst, origCount, written, eraseAddr
...
if callback(0, origCount):1
return ERR_CANCELLED ' we can still cancel erase if done by sectors
but Fastspin wants this syntax without the :1 on the end and won't compile with the :1
if callback(0, origCount)
return ERR_CANCELLED ' we can still cancel erase if done by sectors
Think I’m seeing that loadp2 only works with low number com ports. Can that be?
No, loadp2 can work with any port, but it only auto-detects ports less than 20. For ports higher than that you'll have to use the -p option to give the port, as evanh described above.
@rogloh: The parsing of ":" in Spin2 is *highly* context dependent and very nasty, e.g. consider the fragment
lookup( a ? b():1 ...
Does that ":" go with the lookup, the ? : operator, or is it a marker of the number of results returned by b()? The current fastspin yacc parser got completely confused by things like this and I had to disable the number of results option.
I've taken a stab at re-enabling it, you can try the binary in the attached .zip. Parsing of ":" is still very fragile though, I recommend keeping it to no more than one per line.
@Rayman: the .zip also fixes the nested struct problem you found in C.
It was with the number of results returned by b() not the ? : operator. Thankfully I found a workaround and didn't need it in the end, but it would be good to allow the same syntax to work on both systems. I agree it is confusing.
Doesn't appear to be any way of redefining the uSD pins used in FlexC, is this right?
BTW: Are you still calling it FlexC?
Looks like I have to include a separate copy of the FatFs files with variable pin defines.
Maybe that's the way to go anyway since I want to expand on the types of drives later...
It's not a compile time known therefore requires runtime smarts to handle. To do that in C you'd be malloc()ing and using pointers. Ie: Handcrafted or a support library. And C++ can make it look tidy.
Interpreted languages could do it. Compiled languages with garbage collection can probably handle it. I've always avoided those for realtime work so don't really know.
@ersmith What kind of C compatibility are you aiming for?
Is it C89, C99, C99 with some c++?
Eventually C99 with a few C++ extensions.
If you get C99 compatibility that could eventually allow a native Micropython compilation too. Though a Makefile compatible build sequence would be preferable there if you don't have a separate linker. I don't imagine hundreds of files on the one command line.
I've got one FTDI EVE2 example code working in FlexC (Yeh!)
Trying this "Jackpot" example and getting "error: too many initializers for struct or union" errors on several array initializers.
I'm not sure if they are using C++ stuff here or if it's a bug...
Eric, I think Chip's Spin has the redirected SEND restored at the end of each method call back to that of the caller. Fastspin's SEND seems to take effect globally after it is called. This is a key difference, which if remedied, may impact performance as I could see that checking/restoring it after every function call could be slow and consume more memory too, particularly once it is a per COG setting as intended. What's your plan for SEND and the new RECV with Fastspin?
@Rayman: Thanks for the various bug reports -- you're really givinig this a good workout! Some points:
- Most of the initialization problems stem from FlexC being too strict on initializers; it wants arrays inside of structs (and structs inside arrays) to always be enclosed in {}. The C standard allows this to be relaxed in some cases. I'll try to fix this. In the meantime whenever you get an error like that look at the structure and try to make the initializer layout fully match the logical layout of the structure, with each sub-array or sub-structure delimited by {}.
- The strlen problem is a missing #include of <string.h>
Eric, I think Chip's Spin has the redirected SEND restored at the end of each method call back to that of the caller. Fastspin's SEND seems to take effect globally after it is called. This is a key difference, which if remedied, may impact performance as I could see that checking/restoring it after every function call could be slow and consume more memory too, particularly once it is a per COG setting as intended. What's your plan for SEND and the new RECV with Fastspin?
I can't guarantee anything, but I'll try to make SEND in fastspin work with any real world objects that use it.
On the subject of variable length arrays, I do plan to support them eventually, but not in this release. Just replacing the array declaration with an alloca() would be straightforward, but the C standard requires that the memory be reclaimed when the array goes out of scope, and that part will need some work.
Comments
C historically relied on binary operators to handle bits within an integer (The CPU's register size). Mirroring the fact that general CPUs don't have bitwise instructions either.
Chip's SPIN2 documentation shows this information about how to method pointers:
I pass a callback method into my programFlash and when I try to call it, Pnut seems to want to know the number of arguments it will return. It needs the :1 on the end in order to compile in PNut.
PUB programFlash(addr, srcHubAddr, byteCount, callBack, flags) : r | size, burst, origCount, written, eraseAddr ... if callback(0, origCount):1 return ERR_CANCELLED ' we can still cancel erase if done by sectorsbut Fastspin wants this syntax without the :1 on the end and won't compile with the :1if callback(0, origCount) return ERR_CANCELLED ' we can still cancel erase if done by sectorsIf I include it I get this Fastspin error:
memory.spin2:2126: error: syntax error, unexpected ':'
Is this something that will be resolved or is there no way to use method pointers returning results in both PNut and Fastspin?
No, loadp2 can work with any port, but it only auto-detects ports less than 20. For ports higher than that you'll have to use the -p option to give the port, as evanh described above.
No. The C99 name for a boolean type is "_Bool", and the C++ name for a boolean type is "bool" (which C99 also defines in <stdbool.h>).
I've taken a stab at re-enabling it, you can try the binary in the attached .zip. Parsing of ":" is still very fragile though, I recommend keeping it to no more than one per line.
@Rayman: the .zip also fixes the nested struct problem you found in C.
Is it C89, C99, C99 with some c++?
Just wondering what I can look for in c codes description to know if they should work or not...
A lot say either c89 or c99...
BTW: Are you still calling it FlexC?
Looks like I have to include a separate copy of the FatFs files with variable pin defines.
Maybe that's the way to go anyway since I want to expand on the types of drives later...
Not yet; it's something that would be nice to have (some parameter to the _vfs_open_sdcard() function, or something like that).
Yes. I'll probably rename the whole system + GUI "FlexProp" or something like that so the compilers can stay "FlexC", "FlexBASIC", and "FlexSpin".
Your Marketing Dept approves.
Where camResX and Y are inputs to the function. Says "Unable to determine size of array".
Is this a bug or are you not allowed to do this in C?
That's a C99 special feature, variable-sized local arrays... If it doesn't work like that, try replacing it with I think fastspin supports alloca...
Interpreted languages could do it. Compiled languages with garbage collection can probably handle it. I've always avoided those for realtime work so don't really know.
Trying this "Jackpot" example and getting "error: too many initializers for struct or union" errors on several array initializers.
I'm not sure if they are using C++ stuff here or if it's a bug...
Anyway, here's an example that errors out:
bet_lines_index linePosition[] = { {'t','t','t','t','t'}, //0 {'t','t','t','m','b'},//1 {'m','m','m','m','m'},//2 {'m','m','m','m','t'},//3 {'b','b','b','b','b'},//4 {'b','b','b','m','t'},//5 {'m','t','t','t','t'},//6 {'t','m','b','m','t'},//7 {'b','m','m','m','m'},//8 {'t','m','m','m','m'},//9 {'m','m','m','m','b'},//10 {'b','m','t','m','b'}//11 };Where the type is defined like this:
typedef struct bet_lines_index_t { char8_t line[5]; }bet_lines_index;Also, there's this in a .h file:
Should this work?
char linePosition[12][5]= {And, changing references from this:
if(linePosition[i].line[j] == 't'){to this:
if (linePosition[i][j] == 't') {Two more worked without the need for workarounds...
But, (sorry to do this to you), I found a couple hiccups in this keyboard editor example...
This gives the error: Expected integer type for parameter of operator
Where buffer is defined like this:
struct Notepad_buffer { char8_t *temp; char8_t notepad[MAX_LINES][80]; }Buffer;But, the strange thing is that if I break it up like this, it doesn't give an error:
int x= strlen(Buffer.notepad[Line]); // load into temporary buffer Buffer.temp = Buffer.notepad[Line] + x; // load into temporary bufferThe bottom line gives "incompatible types in assignment" error...
It's OK with this:
Good News is that it does seem to work with those workarounds...
That one is just terrible. NULL is the value for an invalid pointer, not necessarily zero. If you want to set an integer to zero, just use zero...
/* Arrawy used for custom fonts */ S_LiftAppFont_t G_LiftAppFontArrayNumbers[1] = { //font structure { /* Max Width */ 80, /* Max Height */ 156, /* Max Stride */ 80, /* format */ L8, /* Each character width */ 80, 80, 80, 80, 80, 80, 80, 80, 80, 80, 80, 80, } };Where the type is defined like this:
typedef struct S_LiftAppFont { uint32_t MaxWidth; uint32_t MaxHeight; uint32_t Stride; uint8_t Format; uint8_t Width[LIFTAPPMAXCHARS]; }S_LiftAppFont_t;Gives: error: too many initializers for struct or union
on "Max Width" line.
You shouldn't be using NULL with non-pointer types.
abs() would be in math.h
This code seems to have worked with a variety of other compilers...
I agree that it's not good style though..
- Most of the initialization problems stem from FlexC being too strict on initializers; it wants arrays inside of structs (and structs inside arrays) to always be enclosed in {}. The C standard allows this to be relaxed in some cases. I'll try to fix this. In the meantime whenever you get an error like that look at the structure and try to make the initializer layout fully match the logical layout of the structure, with each sub-array or sub-structure delimited by {}.
- The strlen problem is a missing #include of <string.h>
- As @Wuerfel_21 noted abs() is in <math.h>
I can't guarantee anything, but I'll try to make SEND in fastspin work with any real world objects that use it.
Thanks Eric.