Thanks. As I tend to be very verbose with code, anyway, I modified that routine like this so it doesn't count on the return variable being preset.
pub enqueue(c) : done
'' Add c to input buffer
'' -- returns true when terminating char encountered
if (c == 0) || (c == tchar) ' end of input?
buffer[bidx] := 0 ' terminate buffer
return true ' let caller know
if (c == 8) && (bidx > 0) ' if backspace and chars in buffer
buffer[--bidx] := 0 ' erase last
return false
if (bidx < BUF_SIZE-2) ' room in buffer
if (alphacase == LOWER) ' case setting?
c := lcase(c)
elseif (alphacase == UPPER)
c := ucase(c)
buffer[bidx++] := c ' add to buffer
return false ' not done
Yes, there was a bug in 6.4.0 (and many previous versions) where case statements confused the compiler variable initialization code. That is fixed in 6.5.0.
In general it's probably best to explicitly initialize variables. The flexspin optimizer wants to initialize them only when it can prove that they aren't set by the user, but it gets it wrong sometimes . I guess we could disable that and always initialize everything to 0, but that's actually somewhat expensive (relatively speaking).
As mentioned above, there is a new release for FlexProp (6.5.0) which comes with the newest Parallax flash file system, a revised loadp2 loader which can pass command line arguments, DATE/TIME functions for BASIC, the new Spin2 REPEAT n WITH i syntax, and numerous bug fixes.
The flash file system is used in the samples/shell sample, which sets up a basic command line and allows you to copy files between SD, flash, RAM disk, and the host PC. By default just the host PC is mounted, you have to explicitly mount and unmount the other file systems (because SD and flash cannot both be used at the same time). The file systems built in to the shell are:
/host - the host PC file system, accessed over serial
/pfs - the flash formatted with the Parallax file system
/sd - the SD card formatted with FAT32
/flash - the flash formatted with ARM's littlefs
/ram - the Edge 32MB RAM formatted with littlefs
You can use different RAMs for the /ram file system, but you'll have to edit shell.c to do so (I've tested the HyperRam module and a 4bit PSRAM; you can also use HUB RAM but there's not much room there).
mcpp/mcpp_support.c:300:18: error: call to undeclared library function 'vsnprintf' with type 'int (char *, unsigned long, const char *, struct __va_list_tag *)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
rc = vsnprintf( mem_buffer, sizeof(mem_buffer), format, ap);
^
mcpp/mcpp_support.c:300:18: note: include the header <stdio.h> or explicitly provide a declaration for 'vsnprintf'
1 error generated.
make[1]: *** [build/mcpp_support.o] Error 1
make: *** [spin2cpp/build/flexspin] Error 2
@"Greg LaPolla" : stdio.h is included by "configed.H", which is included by "system.H" near the top of mcpp/mcpp_support.c. It looks like Apple may have broken their stdio.h. It wouldn't be the first time . I do provide pre-built binaries for MacOS, which are made with an older version of the SDK.
@"Greg LaPolla" : Actually I do get the vnsprintf problem even on an older SDK if I use stricter compilation flags. I don't quite understand what's going on; maybe the Apple SDK treats #include "stdio.h" and #include <stdio.h> differently? Anyway, I've checked in some updated sources that pass when much stricter compilation flags are given and which fix some warnings on different platforms.
@ersmith said:
[...]maybe the Apple SDK treats #include "stdio.h" and #include <stdio.h> differently? [...]
Sorry, but that's the normal way: <systemheader.h>, "usercodeheader.h"
So if "stdio.h" is not in usercode it is not found. Some compilers/preprocessers may search in system folders if not found in usercode, but if not it is your fault.
@ersmith said:
[...]maybe the Apple SDK treats #include "stdio.h" and #include <stdio.h> differently? [...]
Sorry, but that's the normal way: <systemheader.h>, "usercodeheader.h"
I should have been more specific: of course those two are different, but the error isn't that "stdio.h" is not found, it is that the header file is behaving differently in the two cases. (I think virtually every compiler will search the standard system paths in the event of a user header not being found.)
Something is definitely messed up. Anyway, adding an explicit #include <stdio.h> seems to fix it, so whatever.
Sorry for misunderstanding. But doesn't this tell, that <stdio.h> is not included:
@"Greg LaPolla" said:
New Xcode released yesturday.
mcpp/mcpp_support.c:300:18: error: call to undeclared library function 'vsnprintf' with type 'int (char *, unsigned long, const char *, struct __va_list_tag *)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
rc = vsnprintf( mem_buffer, sizeof(mem_buffer), format, ap);
^
mcpp/mcpp_support.c:300:18: note: include the header <stdio.h> or explicitly provide a declaration for 'vsnprintf'
1 error generated.
make[1]: *** [build/mcpp_support.o] Error 1
make: *** [spin2cpp/build/flexspin] Error 2
I agree that most compiler will search in system path, I saw "stdio.h" very often. Personally, I am very accurate about including my own header files or system headers.
@"Greg LaPolla" : which repo are you working with? The flexprop one still points at the old compiler code, so you'll have to manually update the spin2cpp sub-repo of it to get my changes. Or, you could try adding a #include <stdio.h> to the very top of the mcpp_support.c file.
I have an application I am working on that compiles and runs from proptool and spintools. Flexprop compiles clean and uploads to the prop but doesn't run. I am not a compiler guru so I have no idea what is going on. Is there anything I can send you to assist ?
I have an application I am working on that compiles and runs from proptool and spintools. Flexprop compiles clean and uploads to the prop but doesn't run. I am not a compiler guru so I have no idea what is going on. Is there anything I can send you to assist ?
Are you able to send the application source code, in a form that can run without any special hardware? That would be the easiest way for me to debug. Otherwise have you tried disabling optimization? Sometimes that helps if the bug is in the optimizer.
I've uploaded FlexProp 6.6.0 to my Patreon page. This has some new -gbrk debug features (pc_key and pc_mouse) and proper boolean types for C and BASIC.
There's a bug in compiling some method calls in bytecode. It will be fixed in the next version of the compiler. In the meantime the workaround is to add explicit :0 notations on the end of all the function pointer calls in Graphics.spin2, e.g. change
That fixed the compile error but the code still doesn't run. I am not sure if the flexspin compiler is based off the same compiler @macca uses, but he fixed the issue in spin tools and said it was an issue with the object method index address.
I'm having trouble setting a custom _XTALFREQ in cdemo.c. The board I'm using has a 25 MHz crystal. However, no matter what I do, my LED blinks at the same rate. Furthermore, I can only communicate over serial if I set my terminal to a speed of 288_000 (which is 230_400 * 5/4).
The C #define directive does not affect anything outside of the file, and only can define a text substitution macro. That's why we have to use enum to define global constants like the clock frequency.
I'm a bit surprised that the compiler doesn't give a warning when initializing a static structure with index beyond what is declared...
I had this:
#define EveCount 2 //How many screens do we have?
struct EveType Eves[EveCount];
Then, later on this:
//See DisplaySettings.h for info on types
void DefineDisplays() //Call this function to define attached displays
{
//Bottom Left
Eves[0].CS = 27;
...
//Top-Center
Eves[2].CS = 27 + 10;
...
}
Doesn't give an error or warning on Eves[2] even though obviously bad, right?
My Visual Studio editor doesn't flag it as wrong either, so maybe it's just something that can't be given a warning on?
Got some code here that I just had to dial FlexProp back to 5.9.5 to make work...
There are two versions of SPI, cogged (in Spin2) and not-cogged (in C).
The C version still works.
But, the Spin2 version does not with 5.9.20 and on.
Thinking some change in between those broke it, but don't see how.
@Rayman : when you say "does not work" could you be a bit more specific? Does it fail to compile for you? Does it compile but not run correctly? If the latter, what are the symptoms?
The archive you sent did not have helloworld.c in it, so I can't compile exactly what you are compiling, but the individual pieces all seem to compile OK for me with flexspin 6.6.1.
@Rayman said:
I'm a bit surprised that the compiler doesn't give a warning when initializing a static structure with index beyond what is declared...
That's fairly common for C compilers (C actually lets you index wherever you want in an array, and it's up to you to make sure it's within bounds). That said, I will add a warning for this case (it'll be useful for BASIC, where you really shouldn't be trying to reference an array out of bounds).
Comments
Thanks. As I tend to be very verbose with code, anyway, I modified that routine like this so it doesn't count on the return variable being preset.
pub enqueue(c) : done '' Add c to input buffer '' -- returns true when terminating char encountered if (c == 0) || (c == tchar) ' end of input? buffer[bidx] := 0 ' terminate buffer return true ' let caller know if (c == 8) && (bidx > 0) ' if backspace and chars in buffer buffer[--bidx] := 0 ' erase last return false if (bidx < BUF_SIZE-2) ' room in buffer if (alphacase == LOWER) ' case setting? c := lcase(c) elseif (alphacase == UPPER) c := ucase(c) buffer[bidx++] := c ' add to buffer return false ' not doneYes, there was a bug in 6.4.0 (and many previous versions) where
casestatements confused the compiler variable initialization code. That is fixed in 6.5.0.In general it's probably best to explicitly initialize variables. The flexspin optimizer wants to initialize them only when it can prove that they aren't set by the user, but it gets it wrong sometimes
. I guess we could disable that and always initialize everything to 0, but that's actually somewhat expensive (relatively speaking).
As mentioned above, there is a new release for FlexProp (6.5.0) which comes with the newest Parallax flash file system, a revised loadp2 loader which can pass command line arguments, DATE/TIME functions for BASIC, the new Spin2
REPEAT n WITH i syntax, and numerous bug fixes.The flash file system is used in the samples/shell sample, which sets up a basic command line and allows you to copy files between SD, flash, RAM disk, and the host PC. By default just the host PC is mounted, you have to explicitly mount and unmount the other file systems (because SD and flash cannot both be used at the same time). The file systems built in to the shell are:
You can use different RAMs for the
/ramfile system, but you'll have to edit shell.c to do so (I've tested the HyperRam module and a 4bit PSRAM; you can also use HUB RAM but there's not much room there).New Xcode released yesturday.
mcpp/mcpp_support.c:300:18: error: call to undeclared library function 'vsnprintf' with type 'int (char *, unsigned long, const char *, struct __va_list_tag *)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
rc = vsnprintf( mem_buffer, sizeof(mem_buffer), format, ap);
^
mcpp/mcpp_support.c:300:18: note: include the header <stdio.h> or explicitly provide a declaration for 'vsnprintf'
1 error generated.
make[1]: *** [build/mcpp_support.o] Error 1
make: *** [spin2cpp/build/flexspin] Error 2
@"Greg LaPolla" : stdio.h is included by "configed.H", which is included by "system.H" near the top of mcpp/mcpp_support.c. It looks like Apple may have broken their stdio.h. It wouldn't be the first time
. I do provide pre-built binaries for MacOS, which are made with an older version of the SDK.
@"Greg LaPolla" : Actually I do get the vnsprintf problem even on an older SDK if I use stricter compilation flags. I don't quite understand what's going on; maybe the Apple SDK treats
#include "stdio.h"and#include <stdio.h>differently? Anyway, I've checked in some updated sources that pass when much stricter compilation flags are given and which fix some warnings on different platforms.Sorry, but that's the normal way: <systemheader.h>, "usercodeheader.h"
So if "stdio.h" is not in usercode it is not found. Some compilers/preprocessers may search in system folders if not found in usercode, but if not it is your fault.
I should have been more specific: of course those two are different, but the error isn't that
"stdio.h"is not found, it is that the header file is behaving differently in the two cases. (I think virtually every compiler will search the standard system paths in the event of a user header not being found.)Something is definitely messed up. Anyway, adding an explicit #include <stdio.h> seems to fix it, so whatever.
Sorry for misunderstanding. But doesn't this tell, that <stdio.h> is not included:
I agree that most compiler will search in system path, I saw "stdio.h" very often. Personally, I am very accurate about including my own header files or system headers.
@ersmith,
Did a fresh pull from git, still get the same error. Tried to change to <stdio.h> same result.
@"Greg LaPolla" : which repo are you working with? The flexprop one still points at the old compiler code, so you'll have to manually update the spin2cpp sub-repo of it to get my changes. Or, you could try adding a
#include <stdio.h>to the very top of the mcpp_support.c file.@ersmith,
I have an application I am working on that compiles and runs from proptool and spintools. Flexprop compiles clean and uploads to the prop but doesn't run. I am not a compiler guru so I have no idea what is going on. Is there anything I can send you to assist ?
Are you able to send the application source code, in a form that can run without any special hardware? That would be the easiest way for me to debug. Otherwise have you tried disabling optimization? Sometimes that helps if the bug is in the optimizer.
@ersmith
Sent link to download code in PM
I've uploaded FlexProp 6.6.0 to my Patreon page. This has some new -gbrk debug features (pc_key and pc_mouse) and proper boolean types for C and BASIC.
Wasn’t there already bool in your C?
It needed fixed up - https://forums.parallax.com/discussion/comment/1554367/#Comment_1554367
@ersmith,
When trying to compile to bytecode I get the following error:
error: Internal error, unknown type 2 passed to TypeSize
Running version: Version 6.5.2-HEAD-v6.5.2 Compiled on: Oct 21 2023
Compile command:
"%D/bin/flexspin" -2nu -l --tabs=%t -D_BAUD=%r %O %I "%S"
There's a bug in compiling some method calls in bytecode. It will be fixed in the next version of the compiler. In the meantime the workaround is to add explicit
:0notations on the end of all the function pointer calls in Graphics.spin2, e.g. changeto
and similarly for all of the other wrapper functions in that file. This should also work fine with PNut (at least PNut v39 seems to compile these OK).
@ersmith
That fixed the compile error but the code still doesn't run. I am not sure if the flexspin compiler is based off the same compiler @macca uses, but he fixed the issue in spin tools and said it was an issue with the object method index address.
I'm having trouble setting a custom
_XTALFREQincdemo.c. The board I'm using has a 25 MHz crystal. However, no matter what I do, my LED blinks at the same rate. Furthermore, I can only communicate over serial if I set my terminal to a speed of 288_000 (which is 230_400 * 5/4).#define _XTALFREQ 25000000 enum { _clkfreq = 180000000, }; #include <stdio.h> #include <propeller.h> #define PIN 57 void main() { unsigned int pinmask = 1<<(PIN-32); unsigned i = 0; DIRB |= pinmask; // set pins as output for(;;) { OUTB ^= pinmask; waitcnt(getcnt() + _clkfreq/4); printf("Toggle %u\n", i++); } }Edit: Flexprop 6.6.1 on Windows 11
Hehe, haven't seem quite that mistake before.
Try this (without the #define):
enum { _xtlfreq = 25_000_000, _clkfreq = 180_000_000, };If using a buffered crystal oscillator instead of a raw crystal:
enum { _xinfreq = 25_000_000, _clkfreq = 180_000_000, };Setting crystal frequency, like setting clock frequency, must be done with an
enum:enum { _xtlfreq = 25000000, _clkfreq = 180000000 };Note that there is no letter
Ain_xtlfreq.The C
#definedirective does not affect anything outside of the file, and only can define a text substitution macro. That's why we have to useenumto define global constants like the clock frequency.Wow. Thanks @evanh and @ersmith!
I spent so much time on that. Glad it's behind me now.
I'm a bit surprised that the compiler doesn't give a warning when initializing a static structure with index beyond what is declared...
I had this:
Then, later on this:
//See DisplaySettings.h for info on types void DefineDisplays() //Call this function to define attached displays { //Bottom Left Eves[0].CS = 27; ... //Top-Center Eves[2].CS = 27 + 10; ... }Doesn't give an error or warning on Eves[2] even though obviously bad, right?
My Visual Studio editor doesn't flag it as wrong either, so maybe it's just something that can't be given a warning on?
Got some code here that I just had to dial FlexProp back to 5.9.5 to make work...
There are two versions of SPI, cogged (in Spin2) and not-cogged (in C).
The C version still works.
But, the Spin2 version does not with 5.9.20 and on.
Thinking some change in between those broke it, but don't see how.
Any ideas @ersmith ?
I can compile SPI.spin2 with Flexspin v6.5 without any error messages. What is the expected problem?
EDIT: I note it looks a little wonky being in UTF-16 encoding. Maybe re-encoding it might help.
@Rayman : when you say "does not work" could you be a bit more specific? Does it fail to compile for you? Does it compile but not run correctly? If the latter, what are the symptoms?
The archive you sent did not have helloworld.c in it, so I can't compile exactly what you are compiling, but the individual pieces all seem to compile OK for me with flexspin 6.6.1.
That's fairly common for C compilers (C actually lets you index wherever you want in an array, and it's up to you to make sure it's within bounds). That said, I will add a warning for this case (it'll be useful for BASIC, where you really shouldn't be trying to reference an array out of bounds).
@ersmith I may have spoke up too soon. On a different computer with another copy of the hardware, it works with 6.1.1 and 6.4.0.
When it doesn't work on the other computer, it tries to read the FTDI EVE chip ID and gets 0 instead of what it is supposed to be.
So, not sure you can help until I can pin this down some more...