After all these enhancement FlexBasic is now a powerful tool.
I ordered a cheap (equivalent of US$0.75) RTC module or rather 2 of them to play with. Too late to get them tomorrow, but I should have them in Friday.
@pik33 : you did nothing wrong, the type checker was overly aggressive. It's fixed in the latest github source code. A temporary work-around (if you don't want to rebuild with the new changes) is to simply cast the second parameter to cpu to any pointer type.
graphics.common.spin2h:32: warning: mixing tabs and spaces for indentation on same line
But I can't find any tabs in this line. I bet it's my fault but probably the line number displayed is wrong. Where or what is the actual problem? The code is compiled and runs correctly. I just like to get rid of the warnings if possible.
BTW, I just found out that static const initilizers now work in FlexC! This renders the __pasm{} "pseudo DAT" sections unnecessary and allows for much clearer code.
typedef struct {
char name[5];
float min, val, max;
} para_descr;
const para_descr ParaTable[] = {
{"VMAX", 48.0, 390.0, 400.0}, // V max DC bus voltage
{"VMIN", 24.0, 24.0, 140.0}, // V min DC bus voltage
... };
If I remeber correctly, this wasn't supported some years ago which forced me to translate all const declarations to #defines and all tables to DAT sections. Good to know.
@ManAtWork said:
Is it intended that strings can be put after byte... in Spin DAT sections but that this doesn't work in __pasm{} in C? Example
byte "VMAX"
long 48.0,390.0,400.0
byte "VMIN"
long 24.0,24.0,140.0
This works perfectly in Spin/Spin2 but results in an error in C:
error: string too long, expected a single character
warning: only first element of string is used
I'm not able to reproduce this -- the snippet you provided compiles for me with flexspin 4.5.0 when I put it inside a __pasm{ directive in a C file. Do you have a more complete example which exhibits the bug?
@ManAtWork said:
If I compile this code I get the warning message
graphics.common.spin2h:32: warning: mixing tabs and spaces for indentation on same line
But I can't find any tabs in this line. I bet it's my fault but probably the line number displayed is wrong. Where or what is the actual problem? The code is compiled and runs correctly. I just like to get rid of the warnings if possible.
Again, unfortunately, I can't reproduce your exact error message, as the .zip file you provided is missing a number of files. But I do see that on lines 347 and 348 of graphics.common.spin2h there are indeed mixed tabs and spaces. When I compile just that file (with all of the missing objects / includes commented out or stubbed) then the compiler warns about those lines, as it should. I don't know why the wrong line number is printed for you, perhaps something in one of the missing files has confused things, but I can't tell.
Sorry, I've used Jesse's library which consists of hundreds of files and I missed some... Hopefully, I catched them all, this time. And I'll try to put together a complete example code file with the __pasm{} problem, tomorrow.
@ersmith said:
But I do see that on lines 347 and 348 of graphics.common.spin2h there are indeed mixed tabs and spaces.
Ah thanks! That indeed solves the problem. I don't know why it said "line 33" and "34", here.
Eric,
Got one of those somewhat cryptic errors that took me a while to figure out why I'd screwed up. What I'd done wrong was reuse some initialisation lines of cogRAM assembly as variables then later moved that assembly into hubRAM. The error message of such a move was the following: error: Use of immediate hub address in dest requires ##
An example line of code that produced such an error was: shl cmdaddr, #2 ' longword granular
Pnut comes up with a somewhat more applicable message of "Register cannot exceed $1FF", which is oriented differently. I dunno if it's all that easy for you to adjust this in Flexspin or not. Throwing it out there anyway.
@ersmith said:
I'm not able to reproduce this -- the snippet you provided compiles for me with flexspin 4.5.0 when I put it inside a __pasm{ directive in a C file. Do you have a more complete example which exhibits the bug?
Hmm, I also can't reproduce it with a smaller program.
This works perfectly. It must have something to do with the rest of my code. Or maybe it's also an error message with the wrong line number. Yesterday, it happened several times that the compiler had thrown an error message where the actual error was in the line following the displayed line number. But nerver mind, I've found a better solution, anyway.
@ManAtWork : There was a bug in some warnings and errors that caused the wrong line number to be printed if they happened after #include. That should be fixed in the github sources now.
@evanh: Thanks for the feedback. I've checked in changes which improve those error messages, I think.
@ersmith said:
@evanh: Thanks for the feedback. I've checked in changes which improve those error messages, I think.
Ya, that works, thanks.
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:159: error: Destination of rdpin is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:160: error: Destination of rev is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:161: error: Source operand of getnib is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:162: error: Destination of setnib is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:212: error: Destination of shl is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:213: error: Destination of add is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:214: error: Destination of cmp is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:215: error: Source operand of wrfast is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:242: error: Destination of shl is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:243: error: Destination of add is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:244: error: Destination of cmp is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:245: error: Source operand of rdfast is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:275: error: Destination of shl is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:276: error: Destination of add is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:277: error: Destination of cmp is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:279: error: Source operand of mov is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:306: error: Destination of shl is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:307: error: Destination of add is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:308: error: Destination of cmp is not a register
/home/evanh/hoard/coding/prop2/testing/spi_slave_wrfast.spin2:309: error: Source operand of rdfast is not a register
Eric, I know we had that topic before and I'm sure it's my fault. But I have problems with debugging and printf mixed, again. Debug() in spin alone works as expected. But as soon as I add C code with printf strange things begin to happen. I feel like my code isn't executed at all but hangs somewhere during startup. It depends a bit on the timing. Sometimes I can see the "cog0 ... load" message but nothing else. One single time I saw both ouputs of Spin and C but I cannot repeat it.
I think printf() and debug() somehow stomp on each others foot, obviously because they use the same pins. I tried both -g and -gbrk but both don't work. Sometimes the P2 even executes older code stored in the flash instead of what I've loaded into RAM. (I have an OLED display connected and display a message there so I can tell which software version is executed)
Can I avoid the printf/debug mix? Is there a way to call debug() from C or some other print function that is compatible with debug(). Or do I have to strictly avoid this and comment out all debug()s in spin when using printf()?
@ManAtWork : which version of the compiler are you using? I know that in the past debug and printf did not get along well, but in 6.5.0 I think most of those issues are fixed. I've actually used debug() to track down problems in the Parallax file system, while also using printf() to debug the C file system code.
That said, there are some things to watch out for:
(1) debug() uses its own method of setting the baud, which needs to be synchronized with the normal C mechanism. The easiest way to do this is to put something like -D _BAUD=2000000 on the flexspin command line, this will make both debug() and printf() use the specified _BAUD value.
(2) I haven't tried running code with debug() enabled from flash, so there could possibly be some issues there.
(3) -gbrk is more likely to give problems than -g. -g literally translates debug() statements into calls to the functions printf() uses, so they definitely should be compatible.
I had problems with debug inside my drivers that I blamed on the code that is too time critical to insert a debug interrupt in it. The workaround I use in such cases is to wrlong a value I need to look at, somewhere in the hub, and print it from the high level code
Hmm, this is strange. I use 6.5.0. I'm using 4 cogs but I only call debug() and printf() from cog0, I think. But I'll double check. printf() is not multi-cog safe, is it.
I hope I can shrink the code so I can demonstrate the problem on a KISS board without special hardware connected to it. The fact that everything works perfectly as soon as I don't call printf() could also be caused just by space/address issues because the compiler doesn't link the printf() libraries if it's not called, of course.
At least it's good to know that it should work with -g and I don't do something that's forbidden. I already use "-D_BAUD=${config:baudRate}" and both outputs from debug() and printf() are displayed correctly if I use them alone, e.g. comment out the other. And I run from RAM, at least I wanted to. The accidental execution of code from flash happened because the newly loaded code crashed and a reset caused the code from flash to be loaded, I think.
And I'm pretty sure it's not caused by timing, at least not when debug/printf() is called. My main code looks something like this:
PUB main ()
waitms (2000)
disp.Start ()
eth.Start (cfg.pinEMdc, cfg.pinScl)
io.Start ()
vfd.Start ()
disp.PrintStatus (@"Test 2")
InitTrinamic ()
debug (uhex(par.GetParameter(par.numVMIN))) ' debug called here
par.SaveParameters () ' C code, calls printf()
repeat
If it crashes then it crashes before the PrintStatus() to the OLED display is executed. Sometimes, but not always, an older version printing "Test 1" is executed from flash.
Hmm.... The program still hangs and doesn't print anything to the terminal if I comment out the calls to my drivers (eth, io and vfd). SaveParameters() only calls file system functions which should be pretty well tested. So I'm quite sure I don't mess up pointers and corrupt memory. So it must be the display driver that misbehaves. I took that one from Jesse's library. That is a really exemplary collection of all sorts of drivers and utility functions. But unfortunatelly, the clean and strictly modular design comes with the drawback that it consists of hundreds of source files and you easily lose orientation.
If I remember correctly it also has it's own terminal functions (at least it includes a file "terminal.common.spin2h"). I have to investigate what it actually does. I think, there is the option to redirect the printf output to an LCD screen instead of the serial port. Maybe I have accidentally activated that, somehow.
Yes, it seems to be the display driver. No more hangs or crashes if I comment it out. One funny thing I found out is that PNut doesn't display the printf() output although it uses the correct baud rate. The -t or -T terminal of loadp2 does. I thought PNut just extracts the messages with special meaning (including backticks for graphical debug displays) and prints the rest unfiltered. But it seems that it expects a certain formatting ("cogX...") and doesn't display lines that don't mach that criteria.
Anayway, sorry for abusing this thread for problems I can't blame the compiler for. To my excuse I have to say I just remembered that there was a problem with printf() and debug() with older version. We tend to be biased to what we already know before trying something else... Thanks for everyones help.
@Rayman : Thanks for the bug report. Without a reproducer it's a bit hard to be sure if I fixed it, but I did find a problem with processing attributes like "inline" along with "static", and I've checked in the fix for that, at least.
@Rayman: Well, your program compiles with the latest flexspin, although it's quite large (509252 bytes). I don't know if it runs or not, but apparently I did fix the compilation problem.
Comments
settimeofdayfrom sys/time.h, as it seems.I've just added a SETTIME function to BASIC to set the current date and time in the library, and DATE$ and TIME$ functions to read them.
After all these enhancement FlexBasic is now a powerful tool.
I ordered a cheap (equivalent of US$0.75) RTC module
or rather 2 of them to play with. Too late to get them tomorrow, but I should have them in Friday.
What I am doing wrong here? (that was intended to be a simple blinker test)
The result is
D:/programowanie/P2-Retromachine-Basic/asmtest.bas:8: error: Expected pointer to stack as last parameter to coginit/cogidasm shared t drvl #38 p1 drvnot #38 waitx ##340000000 jmp #p1 end asm let cog=cpu(@t ,0)@pik33 : you did nothing wrong, the type checker was overly aggressive. It's fixed in the latest github source code. A temporary work-around (if you don't want to rebuild with the new changes) is to simply cast the second parameter to
cputo any pointer type.Is it intended that strings can be put after byte... in Spin DAT sections but that this doesn't work in __pasm{} in C? Example
byte "VMAX" long 48.0,390.0,400.0 byte "VMIN" long 24.0,24.0,140.0This works perfectly in Spin/Spin2 but results in an error in C:
If I compile this code I get the warning message
But I can't find any tabs in this line. I bet it's my fault but probably the line number displayed is wrong. Where or what is the actual problem? The code is compiled and runs correctly. I just like to get rid of the warnings if possible.
BTW, I just found out that static const initilizers now work in FlexC!
This renders the __pasm{} "pseudo DAT" sections unnecessary and allows for much clearer code.
typedef struct { char name[5]; float min, val, max; } para_descr; const para_descr ParaTable[] = { {"VMAX", 48.0, 390.0, 400.0}, // V max DC bus voltage {"VMIN", 24.0, 24.0, 140.0}, // V min DC bus voltage ... };If I remeber correctly, this wasn't supported some years ago which forced me to translate all const declarations to #defines and all tables to DAT sections. Good to know.
I'm not able to reproduce this -- the snippet you provided compiles for me with flexspin 4.5.0 when I put it inside a
__pasm{directive in a C file. Do you have a more complete example which exhibits the bug?Again, unfortunately, I can't reproduce your exact error message, as the .zip file you provided is missing a number of files. But I do see that on lines 347 and 348 of graphics.common.spin2h there are indeed mixed tabs and spaces. When I compile just that file (with all of the missing objects / includes commented out or stubbed) then the compiler warns about those lines, as it should. I don't know why the wrong line number is printed for you, perhaps something in one of the missing files has confused things, but I can't tell.
Sorry, I've used Jesse's library which consists of hundreds of files and I missed some... Hopefully, I catched them all, this time. And I'll try to put together a complete example code file with the __pasm{} problem, tomorrow.
Ah thanks! That indeed solves the problem. I don't know why it said "line 33" and "34", here.
Eric,
Got one of those somewhat cryptic errors that took me a while to figure out why I'd screwed up. What I'd done wrong was reuse some initialisation lines of cogRAM assembly as variables then later moved that assembly into hubRAM. The error message of such a move was the following:
error: Use of immediate hub address in dest requires ##An example line of code that produced such an error was:
shl cmdaddr, #2 ' longword granularPnut comes up with a somewhat more applicable message of "Register cannot exceed $1FF", which is oriented differently. I dunno if it's all that easy for you to adjust this in Flexspin or not. Throwing it out there anyway.
Hmm, I also can't reproduce it with a smaller program.
#include <propeller2.h> #include <stdio.h> void main() { printf ("Startup OK\n"); char* l= &Label; printf ("String: %s", l); while (1) {} } __pasm{ Label byte "VMAX",0 long 48.0,390.0,400.0 byte "VMIN" long 24.0,24.0,140.0 }This works perfectly. It must have something to do with the rest of my code. Or maybe it's also an error message with the wrong line number. Yesterday, it happened several times that the compiler had thrown an error message where the actual error was in the line following the displayed line number. But nerver mind, I've found a better solution, anyway.
@ManAtWork : There was a bug in some warnings and errors that caused the wrong line number to be printed if they happened after #include. That should be fixed in the github sources now.
@evanh: Thanks for the feedback. I've checked in changes which improve those error messages, I think.
Fix in PR #417 still isn't merged, you've seen it?
Oh yes, thanks for reminding me (and for doing this).
Ya, that works, thanks.
Eric, I know we had that topic before and I'm sure it's my fault. But I have problems with debugging and printf mixed, again. Debug() in spin alone works as expected. But as soon as I add C code with printf strange things begin to happen. I feel like my code isn't executed at all but hangs somewhere during startup. It depends a bit on the timing. Sometimes I can see the "cog0 ... load" message but nothing else. One single time I saw both ouputs of Spin and C but I cannot repeat it.
I think printf() and debug() somehow stomp on each others foot, obviously because they use the same pins. I tried both -g and -gbrk but both don't work. Sometimes the P2 even executes older code stored in the flash instead of what I've loaded into RAM. (I have an OLED display connected and display a message there so I can tell which software version is executed)
Can I avoid the printf/debug mix? Is there a way to call debug() from C or some other print function that is compatible with debug(). Or do I have to strictly avoid this and comment out all debug()s in spin when using printf()?
@ManAtWork : which version of the compiler are you using? I know that in the past debug and printf did not get along well, but in 6.5.0 I think most of those issues are fixed. I've actually used debug() to track down problems in the Parallax file system, while also using printf() to debug the C file system code.
That said, there are some things to watch out for:
(1) debug() uses its own method of setting the baud, which needs to be synchronized with the normal C mechanism. The easiest way to do this is to put something like
-D _BAUD=2000000on the flexspin command line, this will make both debug() and printf() use the specified_BAUDvalue.(2) I haven't tried running code with debug() enabled from flash, so there could possibly be some issues there.
(3)
-gbrkis more likely to give problems than-g.-gliterally translates debug() statements into calls to the functions printf() uses, so they definitely should be compatible.I had problems with debug inside my drivers that I blamed on the code that is too time critical to insert a debug interrupt in it. The workaround I use in such cases is to wrlong a value I need to look at, somewhere in the hub, and print it from the high level code
Hmm, this is strange. I use 6.5.0. I'm using 4 cogs but I only call debug() and printf() from cog0, I think. But I'll double check. printf() is not multi-cog safe, is it.
I hope I can shrink the code so I can demonstrate the problem on a KISS board without special hardware connected to it. The fact that everything works perfectly as soon as I don't call printf() could also be caused just by space/address issues because the compiler doesn't link the printf() libraries if it's not called, of course.
At least it's good to know that it should work with -g and I don't do something that's forbidden. I already use "-D_BAUD=${config:baudRate}" and both outputs from debug() and printf() are displayed correctly if I use them alone, e.g. comment out the other. And I run from RAM, at least I wanted to. The accidental execution of code from flash happened because the newly loaded code crashed and a reset caused the code from flash to be loaded, I think.
And I'm pretty sure it's not caused by timing, at least not when debug/printf() is called. My main code looks something like this:
If it crashes then it crashes before the PrintStatus() to the OLED display is executed. Sometimes, but not always, an older version printing "Test 1" is executed from flash.
Hmm.... The program still hangs and doesn't print anything to the terminal if I comment out the calls to my drivers (eth, io and vfd). SaveParameters() only calls file system functions which should be pretty well tested. So I'm quite sure I don't mess up pointers and corrupt memory. So it must be the display driver that misbehaves. I took that one from Jesse's library. That is a really exemplary collection of all sorts of drivers and utility functions. But unfortunatelly, the clean and strictly modular design comes with the drawback that it consists of hundreds of source files and you easily lose orientation.
If I remember correctly it also has it's own terminal functions (at least it includes a file "terminal.common.spin2h"). I have to investigate what it actually does. I think, there is the option to redirect the printf output to an LCD screen instead of the serial port. Maybe I have accidentally activated that, somehow.
Yes, it seems to be the display driver. No more hangs or crashes if I comment it out. One funny thing I found out is that PNut doesn't display the printf() output although it uses the correct baud rate. The -t or -T terminal of loadp2 does. I thought PNut just extracts the messages with special meaning (including backticks for graphical debug displays) and prints the rest unfiltered. But it seems that it expects a certain formatting ("cogX...") and doesn't display lines that don't mach that criteria.
Anayway, sorry for abusing this thread for problems I can't blame the compiler for. To my excuse I have to say I just remembered that there was a problem with printf() and debug() with older version. We tend to be biased to what we already know before trying something else... Thanks for everyones help.
Next (maybe dumb) question: I haven't found the atof() function. What is the prefered way to convert a string to a float number?
Edit: I found sscanf(). Never used that before...
atof() is defined in stdlib.h:
#include <stdio.h> #include <stdlib.h> char *s1 = "1.2345"; char *s2 = "-4.9e17"; void main() { float f; f = atof(s1); printf("s1[%s] -> %g\n", s1, f); f = atof(s2); printf("s2[%s] -> %g\n", s2, f); }@ersmith Testing out some raytracing codes again...
raycastlib seems to work now, that's great. I don't think it ever did.
small3dlib used to work, then got broke.
Now, I'm getting errors on this saying that things are redefined:
So, in the main .h file, there's a header like line like this:
static inline void S3L_vec3Add(S3L_Vec4 *result, S3L_Vec4 added);
Then, the actual function comes later.
If I remove the "inline", seems to make it OK.
@Rayman : Thanks for the bug report. Without a reproducer it's a bit hard to be sure if I fixed it, but I did find a problem with processing attributes like "inline" along with "static", and I've checked in the fix for that, at least.
I can provide the c9de, just a sec…
This might have all you need. See build.bat
It was too big to post all together. The main code is in the subfolder "Programs".
@Rayman: Well, your program compiles with the latest flexspin, although it's quite large (509252 bytes). I don't know if it runs or not, but apparently I did fix the compilation problem.
@ersmith Thanks! If I remember, some of the 3D model data files are giant and that's most of it...