There's no mention of system clock frequencies. I presume they're somehow preset the same?
The times given are elapsed clock cycles, so they're independent of the frequency. Which raises an important point: the difference in P1 and P2 cycle counts are not the only factor in comparing performance of P1 and P2, since typically the P2 will be clocked 2x or 3x faster than the P1.
I've been testing your program. If I try to compile "primos.c", it returns the following:
C:/flexgui/include/stdlib.h:45: error: syntax error, unexpected __builtin_abs
child process exited abnormally
Spin2GUI compiles fine using similar settings. Please see the screenshot, and use the code attached if you wish to try to replicate the error. The code itself should be OK. I think the problem lies within "stdlib.h", by the looks of it.
Thank you, Samuel. The problem is actually a conflict between math.h and stdlib.h. You can work around it I think by re-ordering the include files so that stdlib.h comes before math.h. I will create a proper fix for the next FlexGUI release.
So, I am attempting to program the P2 ES RevB. with Flex GUI 4.0.3. No joy. "Could not find a P2" P2 is on COM2. I cannot program it with a SD card in the slot. I can on the RevA, but not RevB. This means I cannot program it "on the fly" if the program requires access to a file on the SD Card. I have to copy to the SD card then boot from SD.
It should come with the other files you install from the FastSpin.zip or FlexGUI.zip. And it should be in FastSpin's default include search path. It works as exspected here.
(I'm only using FastSpin without GUI, so there may be glitches in the GUI I'll never see.)
$ cat hello.spin
'' simple hello world program
'' minimalised ... P1 only ... only print 3 times
CON
_clkmode = xtal1 + pll16x
_clkfreq = 80_000_000
baud = 115_200
rx_pin = 31
tx_pin = 30
OBJ
ser: "spin/FullDuplexSerial"
PUB hello
ser.start(rx_pin, tx_pin, 0, baud)
repeat 3
ser.printf("Hello, world!\n")
$ fastspin hello.spin
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
Version 4.0.3 Compiled on: Nov 9 2019
hello.spin
|-FullDuplexSerial.spin
hello.pasm
Done.
Program size is 3140 bytes
So, I am attempting to program the P2 ES RevB. with Flex GUI 4.0.3. No joy. "Could not find a P2" P2 is on COM2. I cannot program it with a SD card in the slot. I can on the RevA, but not RevB. This means I cannot program it "on the fly" if the program requires access to a file on the SD Card. I have to copy to the SD card then boot from SD.
Any ideas?
Does your SD card have boot code on it? That might cause issues (it'll boot from SD rather than looking for serial).
Otherwise I'm not sure what to suggest; perhaps to try a different SD card? Or check the settings of the boot mode selection switches on the ES board? I've got a Sony 8 GB microSD that I leave in my P2 board all the time and it hasn't interfered with using it.
Does programming it work if you manually reset (with the reset button) it immediately before starting the download?
It do not compile, ser.printf is not know by fullduplexSerial.spin
I make:
ser.str(string("Hello, world!",13))
Do you use a special modified fullduplexserial file?
Yes, the version of fullduplexserial in "include/spin/FullDuplexSerial.spin" in the flexgui distribution has a printf method. There's a file, "include/spin/std_text_routines.spinh", that provides a set of standard methods like "str", "dec", "hex", and "printf" and which may be added to any driver that has a "tx" method. The flexgui FullDuplexSerial uses that.
Does your SD card have boot code on it? That might cause issues (it'll boot from SD rather than looking for serial).
Otherwise I'm not sure what to suggest; perhaps to try a different SD card? Or check the settings of the boot mode selection switches on the ES board? I've got a Sony 8 GB microSD that I leave in my P2 board all the time and it hasn't interfered with using it.
Does programming it work if you manually reset (with the reset button) it immediately before starting the download?
The card did have boot code. I deleted the boot file, and even reformatted the card non-quick to ensure it was zeroed out. No dice.
It works as expected on my Rev A. board.
I have tried a manual reset immediately before programming. No change.
There must be some nuance here that I am not "getting". I will try another card. I just hope others with Rev B. chips don't have this issue, because it will make prototyping with anything that reads from SD a huge pain.
I am going to go dig up another SD card and see if it also has the same issue. I hope it is card specific.
I just downloaded the latest fastspin (4.0.3).
I'm trying to figure out what I need to change to go from Rev.A to Rev.B.
The fastspin.md file talks about the FPGA image the "(v32b FPGA images)".
I'm guessing that's out of date...
So, do you just do -2 for Rev.B and -2a for Rev.A?
I tried -2b with an old version of fastspin and it didn't give an error but code didn't work either...
I don't think my code has anything in it that changed with Rev.B, but something is off...
I just downloaded the latest fastspin (4.0.3).
I'm trying to figure out what I need to change to go from Rev.A to Rev.B.
You use "-2a" for Rev A and "-2b" or just plain "-2" for Rev B. But only recent versions of fastspin support Rev B, if you have an older version "-2" and even "-2b" were probably interpreted as Rev A also.
There weren't many instruction encoding changes (the only backwards incompatible one I can remember was a change in encoding of ptra[X] and ptrb[X] when X is negative or bigger than 15) so if you're having problems with old code it's more likely other hardware changes that are affecting you. Most notably the streamer modes (used for video) and some smartpin modes (e.g. for USB) have changed.
@yeti I tested more, my print issue is with the osx build, have to find why.
On windows there is the "printf" function in the bin map of fullduplexserial
The "courier 8" string is the font specification, changing it to "courier 10" or "courier 12" should help. The code is interpreted, so this change will take effect next time you start flexgui, no recompilation required.
@yeti I tested more, my print issue is with the osx build, have to find why.
On windows there is the "printf" function in the bin map of fullduplexserial
The printf function is actually located in the include/spin/std_text_routines.spinh of the Spin2cpp source tree. I'm not sure how that gets included in flexgui-based compiles. Perhaps ersmith can advise.
The printf function is actually located in the include/spin/std_text_routines.spinh of the Spin2cpp source tree. I'm not sure how that gets included in flexgui-based compiles. Perhaps ersmith can advise.
The printf function is actually located in the include/spin/std_text_routines.spinh of the Spin2cpp source tree. I'm not sure how that gets included in flexgui-based compiles. Perhaps ersmith can advise.
Ah, my mistaken assumption was that only SmartSerial.spin included std_text_routines.spinh and not FullDuplexSerial... I see that P1 and P2 can both get printf, with that extension. Either way, on my macOS flexgui installation, I had to add a "-L ~/mySourceDir/spin2cpp/include/spin" to get std_text_routines.spinh to be found.
Thank you, Samuel. The problem is actually a conflict between math.h and stdlib.h. You can work around it I think by re-ordering the include files so that stdlib.h comes before math.h. I will create a proper fix for the next FlexGUI release.
I'm preparing for a 4.0.4 release of FlexGUI, I hope on the weekend. In the meantime I've posted a sneak peek on my Patreon page for my patrons. Many thanks for those who've donated to support FlexGUI and fastspin, with your help I've been able to purchase a digital signing key and I'm saving up for a P2D2 board and other hardware to test with FlexGUI.
Comments
The times given are elapsed clock cycles, so they're independent of the frequency. Which raises an important point: the difference in P1 and P2 cycle counts are not the only factor in comparing performance of P1 and P2, since typically the P2 will be clocked 2x or 3x faster than the P1.
Kind regards, Samuel Lourenço
I've been testing your program. If I try to compile "primos.c", it returns the following:
C:/flexgui/include/stdlib.h:45: error: syntax error, unexpected __builtin_abs
child process exited abnormally
Spin2GUI compiles fine using similar settings. Please see the screenshot, and use the code attached if you wish to try to replicate the error. The code itself should be OK. I think the problem lies within "stdlib.h", by the looks of it.
Kind regards, Samuel Lourenço
Regards,
Eric
Any ideas?
For P1 and example hello.spin fiber.spin.
you use: It do not compile, ser.printf is not know by fullduplexSerial.spin
I make:
Do you use a special modified fullduplexserial file?
FullDuplesSerial was not inside the example folder, it take the obex file.
I just try you code preparing to P2 evolution.
Thank-you
(I'm only using FastSpin without GUI, so there may be glitches in the GUI I'll never see.)
Does your SD card have boot code on it? That might cause issues (it'll boot from SD rather than looking for serial).
Otherwise I'm not sure what to suggest; perhaps to try a different SD card? Or check the settings of the boot mode selection switches on the ES board? I've got a Sony 8 GB microSD that I leave in my P2 board all the time and it hasn't interfered with using it.
Does programming it work if you manually reset (with the reset button) it immediately before starting the download?
Yes, the version of fullduplexserial in "include/spin/FullDuplexSerial.spin" in the flexgui distribution has a printf method. There's a file, "include/spin/std_text_routines.spinh", that provides a set of standard methods like "str", "dec", "hex", and "printf" and which may be added to any driver that has a "tx" method. The flexgui FullDuplexSerial uses that.
Correct.
The card did have boot code. I deleted the boot file, and even reformatted the card non-quick to ensure it was zeroed out. No dice.
It works as expected on my Rev A. board.
I have tried a manual reset immediately before programming. No change.
There must be some nuance here that I am not "getting". I will try another card. I just hope others with Rev B. chips don't have this issue, because it will make prototyping with anything that reads from SD a huge pain.
I am going to go dig up another SD card and see if it also has the same issue. I hope it is card specific.
I'm trying to figure out what I need to change to go from Rev.A to Rev.B.
The fastspin.md file talks about the FPGA image the "(v32b FPGA images)".
I'm guessing that's out of date...
So, do you just do -2 for Rev.B and -2a for Rev.A?
I tried -2b with an old version of fastspin and it didn't give an error but code didn't work either...
I don't think my code has anything in it that changed with Rev.B, but something is off...
There weren't many instruction encoding changes (the only backwards incompatible one I can remember was a change in encoding of ptra[X] and ptrb[X] when X is negative or bigger than 15) so if you're having problems with old code it's more likely other hardware changes that are affecting you. Most notably the streamer modes (used for video) and some smartpin modes (e.g. for USB) have changed.
On windows there is the "printf" function in the bin map of fullduplexserial
Thank-you
There's no way in the GUI yet (sounds like that would be a nice feature). You can edit the src/gui.tcl file and change the text that's near line 847:
The "courier 8" string is the font specification, changing it to "courier 10" or "courier 12" should help. The code is interpreted, so this change will take effect next time you start flexgui, no recompilation required.
dgately
https://www.patreon.com/totalspectrum/posts
Kind regards, Samuel Lourenço