@Rayman said:
So, the command line -D_BAUD now takes the place of what used to be in the code as "_setbaud(_BAUD);".
Is this right? Or, does the old way still work?
The old way still works too, you can call _setbaud(_BAUD) if you'd like. But it's redundant.
Was pulling my hair out a bit trying to figure out why my brand new P2 board wouldn't load with FlexProp, but would with PropTool.
Seems the com port was assigned to COM22, which appears doesn't work with LoadP2.exe.
Changed to COM9 and seems all better.
The docs don't appear to say what the COM# limit is...
@Rayman said:
Was pulling my hair out a bit trying to figure out why my brand new P2 board wouldn't load with FlexProp, but would with PropTool.
Seems the com port was assigned to COM22, which appears doesn't work with LoadP2.exe.
Changed to COM9 and seems all better.
The docs don't appear to say what the COM# limit is...
loadp2 only scans COM1-COM20 by default. But it should take COM22 as an explicit parameter. Also, I think the FlexProp comm port scan should find COM22 as well. Was it showing up under the Ports menu in the FlexProp GUI?
I don't think there's any particular reason for loadp2 to have only scanned com1-com20, other than slowness of the scanning. I think I can speed this up and I'll lift the restriction in the next release.
There's a new release, version 5.4.1, which has an updated loadp2 which should find all COM ports correctly on Windows, and which has a compiler with a few bug fixes and new features:
- Added __DATE__, __TIME__, __FILE__, and __LINE__ macros
- Added documentation for __VERSION__ macro
- Allowed wc and wz on indirect jumps on P2
- Check for gosub commands inside FCACHEd code
- Fixed incorrect common sub-expression elimination after labels
- Implemented some of the missing math functions from propeller2.h
@ersmith While nobody was looking, you seemed to have snuck-in the following disk stuff in FlexBASIC Version 5.4.1:
MKDIR()
CHDIR()
RMDIR()
DELETE()
RENAME()
I've tested this stuff, and it seems to all work. That's a real game-changer for me! And it appears the following are also lurking under the hood, but I haven't played with them yet:
STAT()
GETCWD()
FTELL()
CHMOD()
All of the C folks are probably going "well, yeah... that's just the normal C stuff...", but the real point here is I can get to these things from FlexBASIC! Eric, you sly dog...
I tried this and it compiles, but doesn't seem to work:
//I2C driver from OBEX with minor modifications
struct __using("jm_i2c_rja2.spin2") i2c1; //RJA: Visual Studio will show an error here, but it's OK
struct __using("jm_i2c_rja2.spin2") *pi2c1;
void Setup()
{
i2c1.setup(I2C1_SCL, I2C1_SDA, 100, i2c1.PU_15K); //setup(scl, sda, khz, pullup)
printf("I2C Driver Started.\n");
GetRtcSetSystemTime(pi2c1);
}
and then this:
struct __using("jm_i2c_rja2.spin2")* pi2c;
void GetRtcSetSystemTime(void* p)
{//get system time from RTC and apply to system
pi2c = (struct __using("jm_i2c_rja2.spin2")*) p;
...
Sorry, I haven't followed the discussion since around christmas, so I'm not up-to-date with the current DEBUG features. I just did a quick check in the docs and found
In flexspin, DEBUG statements are accepted only in Spin2 methods, not in PASM (they are ignored in PASM).
Only a subset of the Spin2 DEBUG directives are accepted:
ZSTR, UDEC, UDEC_BYTE, UDEC_WORD, UDEC_LONG, SDEC, SDEC_BYTE, SDEC_WORD, SDEC_LONG, UHEX, UHEX_BYTE, UHEX_WORD, UHEX_LONG
...
DEBUG statements containing backticks are (partially) translated so as to output the correct strings, but FlexProp does not have any way to interpret these strings so no graphical debug capabiliites exist.
So all the fancy graphical debug windows of PNut are not supported, right? I know, supporting them all would be a lot of work but I hoped at least the SCOPE was working somehow. Is there an alternate method to make graphical debugging work? Can PNut capture the debug output of a program downloaded by FlexProp? Or can I download and run a binary compiled with FlexSpin in PNut?
@ManAtWork said:
Sorry, I haven't followed the discussion since around christmas, so I'm not up-to-date with the current DEBUG features. I just did a quick check in the docs and found
In flexspin, DEBUG statements are accepted only in Spin2 methods, not in PASM (they are ignored in PASM).
Only a subset of the Spin2 DEBUG directives are accepted:
ZSTR, UDEC, UDEC_BYTE, UDEC_WORD, UDEC_LONG, SDEC, SDEC_BYTE, SDEC_WORD, SDEC_LONG, UHEX, UHEX_BYTE, UHEX_WORD, UHEX_LONG
...
DEBUG statements containing backticks are (partially) translated so as to output the correct strings, but FlexProp does not have any way to interpret these strings so no graphical debug capabiliites exist.
So all the fancy graphical debug windows of PNut are not supported, right? I know, supporting them all would be a lot of work but I hoped at least the SCOPE was working somehow. Is there an alternate method to make graphical debugging work? Can PNut capture the debug output of a program downloaded by FlexProp? Or can I download and run a binary compiled with FlexSpin in PNut?
There's an effort underway via the P2 Live Forums to translate the graphical debug code to a language that would allow Eric to incorporate it into FlexProp. I believe Roy was working on this, but he may have become too busy to complete it. I will add this topic to the next P2 Live Forum to figure out where the project is at. @"Stephen Moraco" you're most familiar with this discussion topic -- could you comment?
There's an effort underway via the P2 Live Forums to translate the graphical debug code to a language that would allow Eric to incorporate it into FlexProp. I believe Roy was working on this, but he may have become too busy to complete it. I will add this topic to the next P2 Live Forum to figure out where the project is at. @"Stephen Moraco" you're most familiar with this discussion topic -- could you comment?
I'll try... There are two parts to this issue. (1) compiling debug statements which can be present in both spin2 or pasm2 code and generating the proper debug compiled code, and (2) monitoring the debug serial output port for strings that are sent out by this compiled code and interpreting the debug text that appears over that port. As I understand it Roy is working on the 2nd part listener/interpreter rewritten as platform-independent code. Eric will have to address the first part "compiling debug() statements". Then if we are to achieve full debug support, Roy's part would have to be run by Eric's part (possibly) as part of the terminal support he has built in.
@ersmith, @"Roy Eltham" have I stated this properly?
Eric another thought. It seems that there might be an opportunity (like you need/want more) to add this debug() support to all the other languages you currently compile providing there is not a reserved word conflict with the debug() method/function in the target language. This could be a fun win for the P2 community. Just thinking out loud...
As far as flexspin is concerned a Spin2 debug() statement is just like BASIC print or C printf: it's just a way to print things to the serial port. So there's no need to add it to the other languages, they already have it .
Interpreting what's sent over the serial port is the job of code running on the PC, and will require some code to be added to loadp2 and/or whatever GUI is running it (Visual Studio or FlexProp, for example). They have to monitor for backtick escapes and then do the right thing based on those.
@"Ken Gracey" said:
There's an effort underway via the P2 Live Forums to translate the graphical debug code to a language that would allow Eric to incorporate it into FlexProp.
Good to know. This would be less complicated than re-building it from scratch but still a lot of work. Wouldn't it been easier to just add some communication link between the two programs so that FlexProp could compile and download the code and PNut captures the output and displays the debug data? I don't mind installing/running them both. I just fear that some of my applications need the performance of FastSpin and won't run in realtime in interpreted Spin2.
@ersmith said:
So there's no need to add it to the other languages, they already have it .
Almost. The conditional execution of DEBUG could be done with #ifdef in C which could be in turn hidden by a macro. I don't know if that also works in BASIC.
@ManAtWork said:
Good to know. This would be less complicated than re-building it from scratch but still a lot of work. Wouldn't it been easier to just add some communication link between the two programs so that FlexProp could compile and download the code and PNut captures the output and displays the debug data? I don't mind installing/running them both. I just fear that some of my applications need the performance of FastSpin and won't run in realtime in interpreted Spin2.
flexprop is supported on more than just Windows (macOS, Linux)... Adding features to flexprop that would only work with a Windows solution (PNut) just seems wrong.
@Wuerfel_21 said:
The true potential of DEBUG IMO is using it in PASM drivers, since it's difficult to get decent debug prints in that environment.
True. Adding that to flexspin is a whole other issue though and is a significant amount of work, which I do not have time for unfortunately.
What we really need, IMHO, is a stand alone (not integrated into PropTool!) assembly debugger that could single step and examine both COG and HUB memory. Support for symbols and source code display would be a nice added bonus, but even just showing the disassembled code would be fine. Again, not something I have time for, but it seems like the kind of thing Parallax should support.
@ersmith Version 5.4.2 is returning errors after an OPEN. This code demonstrates it:
mount "/sd", _vfs_open_sdcard()
print "1: ";strerror$(geterr())
open "/sd/testfile.log" for append as #3
print "2: ";strerror$(geterr())
The MOUNT() works fine but the OPEN breaks it. The error being returned is "Invalid Argument". Any ideas?
On a different topic, is there any way to tell if an SD card is present? I'd like to use something like sdmmc_is_present(void) as found in sdmmc.c, but it isn't accessible from FlexBASIC. I rewrote it in BASIC, but it doesn't seem to work reliably. Suggestions?
@JRoark said:
@ersmith Version 5.4.2 is returning errors after an OPEN. This code demonstrates it:
I think it's always done that -- in the course of the open several things are tried, some of which fail and leave their error in geterr(). If the open itself failed then it would throw an exception and (if not caught) terminate the program. Edit: no, I guess some of the errors in open() are new. They are internal though and don't cause the open to fail. I'll fix it so _geterr() returns 0 on the next release.
On a different topic, is there any way to tell if an SD card is present? I'd like to use something like sdmmc_is_present(void) as found in sdmmc.c, but it isn't accessible from FlexBASIC. I rewrote it in BASIC, but it doesn't seem to work reliably. Suggestions?
If there's no sd card then the mount would fail. I don't think there's any other reliable way, and indeed I removed sdmmc_is_present() from the file system code a while back because it didn't always work (there may still be a copy in loadp2, but if so you could probably ignore it).
Comments
So, the command line -D_BAUD now takes the place of what used to be in the code as "_setbaud(_BAUD);".
Is this right? Or, does the old way still work?
The old way still works too, you can call _setbaud(_BAUD) if you'd like. But it's redundant.
But, I imagine one could call _setbaud() a second time to change baud at runtime, right?
Sure.
Was pulling my hair out a bit trying to figure out why my brand new P2 board wouldn't load with FlexProp, but would with PropTool.
Seems the com port was assigned to COM22, which appears doesn't work with LoadP2.exe.
Changed to COM9 and seems all better.
The docs don't appear to say what the COM# limit is...
Taking COM9 but balking at COM22 is strange. Usually the limit is COM4 (because that's all the UARTs you can fit on an ISA bus) or nothing.
loadp2 only scans COM1-COM20 by default. But it should take COM22 as an explicit parameter. Also, I think the FlexProp comm port scan should find COM22 as well. Was it showing up under the Ports menu in the FlexProp GUI?
I did try FlexProp and it didn’t find a P2 either
But I didn’t look in the menu for ports
I don't think there's any particular reason for loadp2 to have only scanned com1-com20, other than slowness of the scanning. I think I can speed this up and I'll lift the restriction in the next release.
There's a new release, version 5.4.1, which has an updated loadp2 which should find all COM ports correctly on Windows, and which has a compiler with a few bug fixes and new features:
@ersmith While nobody was looking, you seemed to have snuck-in the following disk stuff in FlexBASIC Version 5.4.1:
I've tested this stuff, and it seems to all work. That's a real game-changer for me! And it appears the following are also lurking under the hood, but I haven't played with them yet:
All of the C folks are probably going "well, yeah... that's just the normal C stuff...", but the real point here is I can get to these things from FlexBASIC!
Eric, you sly dog...
In C, can one pass a Spin2 object around somehow?
I tried this and it compiles, but doesn't seem to work:
//I2C driver from OBEX with minor modifications struct __using("jm_i2c_rja2.spin2") i2c1; //RJA: Visual Studio will show an error here, but it's OK struct __using("jm_i2c_rja2.spin2") *pi2c1; void Setup() { i2c1.setup(I2C1_SCL, I2C1_SDA, 100, i2c1.PU_15K); //setup(scl, sda, khz, pullup) printf("I2C Driver Started.\n"); GetRtcSetSystemTime(pi2c1); }and then this: struct __using("jm_i2c_rja2.spin2")* pi2c; void GetRtcSetSystemTime(void* p) {//get system time from RTC and apply to system pi2c = (struct __using("jm_i2c_rja2.spin2")*) p; ...Shoot, saw the problem as soon as I posted that...
Needed this in Setup():
pi2c1 = &i2c1;Though you should probably
typedefthat so that the filename isn't repeated all over the place.@Wuerfel_21 That sounds good, but I'm not sure how to do that...
typedef struct __using("jm_i2c_rja2.spin2") JMI2C;should typedef it as
JMI2C, didn't test it though.@Wuerfel_21 That seems to work, thanks!
Ok, that is a much better way to do this. Plus, FlexSpin only has to scan the .spin2 file once... And, I can hide the typedef away in a .h file...
@Rayman ,
There's an i2c driver built into flexspin from the P1. Just include simpletools.h and use the documentation from the P1.
Mike
Hmmm... I hadn't really planned on this, but it's useful for these functions to work from FlexBASIC, so I'll try to make sure it'll keep working
.
Sorry, I haven't followed the discussion since around christmas, so I'm not up-to-date with the current DEBUG features. I just did a quick check in the docs and found
So all the fancy graphical debug windows of PNut are not supported, right? I know, supporting them all would be a lot of work but I hoped at least the SCOPE was working somehow. Is there an alternate method to make graphical debugging work? Can PNut capture the debug output of a program downloaded by FlexProp? Or can I download and run a binary compiled with FlexSpin in PNut?
There's an effort underway via the P2 Live Forums to translate the graphical debug code to a language that would allow Eric to incorporate it into FlexProp. I believe Roy was working on this, but he may have become too busy to complete it. I will add this topic to the next P2 Live Forum to figure out where the project is at. @"Stephen Moraco" you're most familiar with this discussion topic -- could you comment?
Ken Gracey
I'll try... There are two parts to this issue. (1) compiling debug statements which can be present in both spin2 or pasm2 code and generating the proper debug compiled code, and (2) monitoring the debug serial output port for strings that are sent out by this compiled code and interpreting the debug text that appears over that port. As I understand it Roy is working on the 2nd part listener/interpreter rewritten as platform-independent code. Eric will have to address the first part "compiling debug() statements". Then if we are to achieve full debug support, Roy's part would have to be run by Eric's part (possibly) as part of the terminal support he has built in.
@ersmith, @"Roy Eltham" have I stated this properly?
Eric another thought. It seems that there might be an opportunity (like you need/want more) to add this debug() support to all the other languages you currently compile providing there is not a reserved word conflict with the debug() method/function in the target language. This could be a fun win for the P2 community. Just thinking out loud...
As far as flexspin is concerned a Spin2 debug() statement is just like BASIC print or C printf: it's just a way to print things to the serial port. So there's no need to add it to the other languages, they already have it
.
Interpreting what's sent over the serial port is the job of code running on the PC, and will require some code to be added to loadp2 and/or whatever GUI is running it (Visual Studio or FlexProp, for example). They have to monitor for backtick escapes and then do the right thing based on those.
Good to know. This would be less complicated than re-building it from scratch but still a lot of work. Wouldn't it been easier to just add some communication link between the two programs so that FlexProp could compile and download the code and PNut captures the output and displays the debug data? I don't mind installing/running them both. I just fear that some of my applications need the performance of FastSpin and won't run in realtime in interpreted Spin2.
Almost. The conditional execution of DEBUG could be done with #ifdef in C which could be in turn hidden by a macro. I don't know if that also works in BASIC.
The true potential of DEBUG IMO is using it in PASM drivers, since it's difficult to get decent debug prints in that environment.
If only the P2 had a proper debug port and singles step support
flexprop is supported on more than just Windows (macOS, Linux)... Adding features to flexprop that would only work with a Windows solution (PNut) just seems wrong.
dgately
True. Adding that to flexspin is a whole other issue though and is a significant amount of work, which I do not have time for unfortunately.
What we really need, IMHO, is a stand alone (not integrated into PropTool!) assembly debugger that could single step and examine both COG and HUB memory. Support for symbols and source code display would be a nice added bonus, but even just showing the disassembled code would be fine. Again, not something I have time for, but it seems like the kind of thing Parallax should support.
@ersmith Version 5.4.2 is returning errors after an OPEN. This code demonstrates it:
mount "/sd", _vfs_open_sdcard() print "1: ";strerror$(geterr()) open "/sd/testfile.log" for append as #3 print "2: ";strerror$(geterr())The MOUNT() works fine but the OPEN breaks it. The error being returned is "Invalid Argument". Any ideas?
On a different topic, is there any way to tell if an SD card is present? I'd like to use something like sdmmc_is_present(void) as found in sdmmc.c, but it isn't accessible from FlexBASIC. I rewrote it in BASIC, but it doesn't seem to work reliably. Suggestions?
I think it's always done that -- in the course of the open several things are tried, some of which fail and leave their error in geterr(). If the open itself failed then it would throw an exception and (if not caught) terminate the program. Edit: no, I guess some of the errors in open() are new. They are internal though and don't cause the open to fail. I'll fix it so _geterr() returns 0 on the next release.
If there's no sd card then the mount would fail. I don't think there's any other reliable way, and indeed I removed sdmmc_is_present() from the file system code a while back because it didn't always work (there may still be a copy in loadp2, but if so you could probably ignore it).