At some point could it be put on the roadmap to be able to directly load the program through the P2 eval board, directly to the SD card as a boot file? I think it would necessitate loading a program on the P2 to do that, and then reset the P2 so it can boot from SD. This is a "like to have", but would give a lot of polish!
That's definitely on the road map, and is one of the reasons I added loadp2's multiple file loading mechanism. If you look at how the SPI flash programming is done we can do something very similar to write to an SD card too, and I hope to add that to FlexGUI eventually.
I've uploaded another FlexGUI 4.1.0 beta version to my Patreon page. As requested by patrons, it has support for SD card writing and the BASIC exponentiation operator ^. There are some other improvements too (like method pointers in Spin, BIN$ and HEX$ in BASIC, [] pointer dereference operator in BASIC, and automatic clock setting based on _clkfreq).
I hope there will be a public release of it soon, but I wanted to give those supporting it a sneak preview.
@ersmith .... and in addition to the above, we now have a native COS, EXP, LOG, SIN, LONGINT, ULONGINT, and XOR! Sweet!!!
I'm still trying to find where the support is for SD card writing however. I see the header files and C-lang stuff sitting in the BOARD subdirectory, but nothing in the doc that tells me how to access it from BASIC. If you could point me in the right direction, I'll have an even happier weekend!
BASIC USERS: A new mini-gotcha after upgrading to 4.1.0B(2): The first time you attempt to compile and download BASIC code you will get an error, the text of which I did not catch, but in essence it is a squawk about needing to choose to download to either SD card or flash. To cure this, from the toolbar select "COMMANDS" -> "Choose P2 Flash Program" and select "P2ES_flashloader.bin", or "P2ES_sdcard.bin" as appropriate.
@ersmith .... and in addition to the above, we now have a native COS, EXP, LOG, SIN, LONGINT, ULONGINT, and XOR! Sweet!!!
I'm still trying to find where the support is for SD card writing however. I see the header files and C-lang stuff sitting in the BOARD subdirectory, but nothing in the doc that tells me how to access it from BASIC. If you could point me in the right direction, I'll have an even happier weekend!
Thank, Eric!
I didn't phrase my message well -- the support for SD card writing is only for writing a binary image to SD instead of flash. Obviously we do have code for doing I/O to the SD, but it isn't packaged up nicely for use in BASIC or Spin yet.
BASIC USERS: A new mini-gotcha after upgrading to 4.1.0B(2): The first time you attempt to compile and download BASIC code you will get an error, the text of which I did not catch, but in essence it is a squawk about needing to choose to download to either SD card or flash. To cure this, from the toolbar select "COMMANDS" -> "Choose P2 Flash Program" and select "P2ES_flashloader.bin", or "P2ES_sdcard.bin" as appropriate.
Sorry about that -- it's an error in the command configuration. Selecting P1 or P2a will also fix the error, which is why I didn't notice it before. It'll be fixed in the final release.
@ersmith,
May have found a bug or two in Fastspin when converting spin1 to P2asm...
Fastspin cannot handle multiple line spin operation
if( (dataOutPin <> clockPin) and (dataOutPin <> dataInPin) and (dataOutPin <> chipSelectPin) and {
} (clockPin <> dataInPin) and (clockPin <> chipSelectPin) and (dataInPin <> chipSelectPin) and {
} (writeProtectPin <> dataOutPin) and (writeProtectPin <> chipSelectPin) and {
} (cardDetectPin <> dataOutPin) and (cardDetectPin <> chipSelectPin) and {
} (++cardLockID) and (++cardCogID) and (chipver == 1) )
Is there an alternate way of using multiple lines? If not, I can put all on the one long line.
This one identifies the problem but gives no indication of where the problem is
C:\P2\Propeller II OS2>f406 -w -2 _SD_FAT2.spin2
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
Version 4.0.6 Compiled on: Dec 30 2019
_SD_FAT2.spin2
error: .cog.spin functions may not have more than 8 arguments
C:\P2\Propeller II OS2>
FWIW I can reduce the parameters so a limit of 8 is not a problem for me.
And a typo for you: "mackes"
'' Code to lock access to the PASM COG
'' The idea here is that (in theory) multiple Spin bytecode threads might
'' want access to the PASM COG, so this lock mackes sure they don't step on each other.
'' This method also makes sure the remote COG is idle and ready to receive commands.
Thanks for the bug reports, Ray! I'm working now on trying to get the end of line comment problem fixed; the code for parsing indentation is a little hairy, so it make take me a day or two.
That .cog.spin functions may not have more than 8 arguments is a limit built in to the compiler. We could raise it, but at the cost of increasing the size of every program compiled that way. Given that code produced by -w is intended to be run in a COG that's probably not really something most people would want. It only applies to -w mode, code normally compiled by fastspin (for HUBEXEC) doesn't have the 8 parameter limit.
Thanks for the bug reports, Ray! I'm working now on trying to get the end of line comment problem fixed; the code for parsing indentation is a little hairy, so it make take me a day or two.
There were only 4 such lines and I made them a single long line each. There isn't a need to fix it but I thought you'd like to know.
That .cog.spin functions may not have more than 8 arguments is a limit built in to the compiler. We could raise it, but at the cost of increasing the size of every program compiled that way. Given that code produced by -w is intended to be run in a COG that's probably not really something most people would want. It only applies to -w mode, code normally compiled by fastspin (for HUBEXEC) doesn't have the 8 parameter limit.
Again, doesn't need a fix although an error with the line number would be helpful as I had to track it down the long way. There was only one such call.
For converting spin to hubexec code, what options do I need to compile that?
For converting spin to hubexec code, what options do I need to compile that?
That's the default for fastspin, so no options are required. In fact fastspin always produces a .p2asm (or .pasm for P1) file containing the hubexec code (LMM for p1).
If you're really keen on translating Spin to PASM, spin2cpp is probably the better tool, because it has more control over the options (under the hood fastspin and spin2cpp are the same, but they have different emphasis in the command line options they have). So for example you can do something like:
to translate foo.spin into hubexec ASM code for P2. You can change where the code and data go explicitly with "hub" or "cog" options (beware, --data=cog hasn't been thoroughly tested).
But I definitely would suggest just compiling it to binary first with fastspin and making sure it runs on the P2 before trying to convert it to P2ASM.
At some point could it be put on the roadmap to be able to directly load the program through the P2 eval board, directly to the SD card as a boot file? I think it would necessitate loading a program on the P2 to do that, and then reset the P2 so it can boot from SD. This is a "like to have", but would give a lot of polish!
What if we had a Propeller program which would turn the Popeller and the SD card into a mass storage class device via USB? Then, we could address the SD card as a disk drive.
Received the following error when compiling my p2asm code?
C:/Program Files (x86)/Parallax/P2/CM2302/CM2302.spin2:245: error: Changing hub value for symbol temp
temp is defined:
temp long 0
That looks like there may be multiple definitions for temp.
Also when using Jon's simple_serial object I cannot get the cursor to HOME?
I believe he's using a different terminal emulator than the one in FlexGUI. FlexGUI uses standard ANSI, but some Prop terminals use a different standard.
I believe he's using a different terminal emulator than the one in FlexGUI. FlexGUI uses standard ANSI, but some Prop terminals use a different standard.
Yes, I am using PST which has control codes for moving the cursor around. This is in the code -- I will add a comment to indicate that special codes only work with PST.
Thanks for all the help. I will look at the ANSI commands and see if I can get that piece working. The temp definitions is a bit puzzling as the code is stable on the P1.
Again, Alex and Jon - Thank you...
I just got done watching the youtube video and all I can say is WOW! I am really impressed! Multi platform, open source, produces efficient running and human readable code, multi language. I have been out of the space, and just lurking from time to time, and this looks like the platform I need to get back to playing on the P2.
@ersmith I have a few questions:
1. Do you have Bitcoin Cash address so that I can send you some support? If you don't have a wallet go to bitcoin.com and get one, please.
2. Is there a way to call words in TAQOZ from spin2/c/bas code and receive back part of stack or a read a chunk of memory?
3. How much memory does FlexGUI use? I know this is a bit far out, but is it possible to get this ported to the Prop2 with some external ram for self-hosting or Prop2 to Prop2/Prop1 hosting?
@ersmith I have a few questions:
1. Do you have Bitcoin Cash address so that I can send you some support?
Right now I'm just set up to receive donations via Patreon and PayPal (see links in my signature).
2. Is there a way to call words in TAQOZ from spin2/c/bas code and receive back part of stack or a read a chunk of memory?
I think @msrobots has experimented with this, so I believe it's possible but it is a bit of work. Perhaps he'll chime in. It would definitely be cool to have a standard TAQOZ interface object!
3. How much memory does FlexGUI use? I know this is a bit far out, but is it possible to get this ported to the Prop2 with some external ram for self-hosting or Prop2 to Prop2/Prop1 hosting?
Self-hosting isn't going to be practical, I'm afraid, even for just fastspin (let alone flexgui, which is much bigger). The memory usage is reasonable by modern PC standards, but it's in the many megabytes range. Even if you could do an XMM version it'd likely be very slow.
Small but annoying gotcha:
1. open a blank editor tab (file - new file)
2. type several pages of text
3. open another existing file before saving what you have typed
The file will be opened in the existing editor tab instead of a new one. All entered text is lost without warning, undo doesn't help.
1) is @"Peter Jakacki" - - you need to hit a running target since he is changing TAQOZ constantly and as soon as something works it is already obsolete.
2) is the memory layout of TAQOZ. It needs the first 64K of HUB (ROM-Version) or the first 128K of HUB (current Version).
3) one has to change the console I/O of TAQOZ from serial to a mailbox in HUB.
so how far am I?
1) is a non solvable 'problem' - Peter is as productive as @ersmith.
2) seems to be unsolvable with the SPIN2 interpreter, but I might be wrong there since SPIN2 is supposed to be relocatable code.
Fastspin and loadp2 allow you to compile (at least pure PASM) to say HUB $1008 use $1000 and $1004 as mailbox and combine the TAQOZ BLOB as binary file and the Fastspin created binary file together.
I am not sure if this still works and if it will work with BASIC,C and Spin too. I think it should.
3) is basically solved, alas Peter changed the way his vectoring of console I/O works so my approach in the thread mentioned above might not work with the current TAQOZ anymore.
Small but annoying gotcha:
1. open a blank editor tab (file - new file)
2. type several pages of text
3. open another existing file before saving what you have typed
The file will be opened in the existing editor tab instead of a new one. All entered text is lost without warning, undo doesn't help.
Whoops! Sorry about that. That's fixed in github now.
If I press return when the cursor is behind a closing curly bracket that is indented less than 4 spaces the bracket is deleted.
I guess this is meant to have some purpose if I followed the classical style of 4-spaces-per-tab formatting. But I think the auto-formating should not delete printable characters in any case.
If I press return when the cursor is behind a closing curly bracket that is indented less than 4 spaces the bracket is deleted.
I guess this is meant to have some purpose if I followed the classical style of 4-spaces-per-tab formatting. But I think the auto-formating should not delete printable characters in any case.
I think this should be better now in the 4.2.5 release.
There are many bug fixes and optimizations in this version. There is also a new menu option to enable extra warnings, specifically to catch compatibility differences between fastspin and "standard" Spin/Spin2. This may help in porting code from fastspin to other compilers.
I am checking this out out replace simpleIDE, but after running the flexgui.tcl in DEBIAN10... I didn't see an option to scan or upload to a WX esp8266 device, however I do not have my device connected to my wifi at the moment.
Would it show up in the list if it was connected?
Or is that not coded into this gui programmer?
So I was just curious has anyone attempted this?
Does the parallax wx device show up in the ports list when you have it connected?
I am checking this out out replace simpleIDE, but after running the flexgui.tcl in DEBIAN10... I didn't see an option to scan or upload to a WX esp8266 device, however I do not have my device connected to my wifi at the moment.
Would it show up in the list if it was connected?
Or is that not coded into this gui programmer?
So I was just curious has anyone attempted this?
Does the parallax wx device show up in the ports list when you have it connected?
Hey Clock Loop, YES, the parallax WX esp8266 device does work.
Glad I could help you, you can make donations to me at any time, if you like my help and work.
(just kiddin, keep it, and buy another WX or donate to FlexGUI.)
Not kidding about the WX esp device working with FlexGUI. It really does show up.
Make sure your firewall isn't blocking the port (32420) and flexgui program.
I use TERMINATOR as my default terminal program...
I also use the P1 defaults for the commands.
FlexGUI used to work, then one day it stopped.
I suppose I can try to get a new git of it... and see if it happens again.
It sounds like your terminal program doesn't understand the "-fs 14" argument (which sets the font size in xterm). Just remove that from the command lines.
It sounds like your terminal program doesn't understand the "-fs 14" argument (which sets the font size in xterm). Just remove that from the command lines.
Comments
That's definitely on the road map, and is one of the reasons I added loadp2's multiple file loading mechanism. If you look at how the SPI flash programming is done we can do something very similar to write to an SD card too, and I hope to add that to FlexGUI eventually.
I hope there will be a public release of it soon, but I wanted to give those supporting it a sneak preview.
I'm still trying to find where the support is for SD card writing however. I see the header files and C-lang stuff sitting in the BOARD subdirectory, but nothing in the doc that tells me how to access it from BASIC. If you could point me in the right direction, I'll have an even happier weekend!
Thank, Eric!
I didn't phrase my message well -- the support for SD card writing is only for writing a binary image to SD instead of flash. Obviously we do have code for doing I/O to the SD, but it isn't packaged up nicely for use in BASIC or Spin yet.
Sorry about that -- it's an error in the command configuration. Selecting P1 or P2a will also fix the error, which is why I didn't notice it before. It'll be fixed in the final release.
May have found a bug or two in Fastspin when converting spin1 to P2asm...
Fastspin cannot handle multiple line spin operation
if( (dataOutPin <> clockPin) and (dataOutPin <> dataInPin) and (dataOutPin <> chipSelectPin) and { } (clockPin <> dataInPin) and (clockPin <> chipSelectPin) and (dataInPin <> chipSelectPin) and { } (writeProtectPin <> dataOutPin) and (writeProtectPin <> chipSelectPin) and { } (cardDetectPin <> dataOutPin) and (cardDetectPin <> chipSelectPin) and { } (++cardLockID) and (++cardCogID) and (chipver == 1) )Is there an alternate way of using multiple lines? If not, I can put all on the one long line.This one identifies the problem but gives no indication of where the problem is reports FWIW I can reduce the parameters so a limit of 8 is not a problem for me.
And a typo for you: "mackes"
'' Code to lock access to the PASM COG
'' The idea here is that (in theory) multiple Spin bytecode threads might
'' want access to the PASM COG, so this lock mackes sure they don't step on each other.
'' This method also makes sure the remote COG is idle and ready to receive commands.
That .cog.spin functions may not have more than 8 arguments is a limit built in to the compiler. We could raise it, but at the cost of increasing the size of every program compiled that way. Given that code produced by -w is intended to be run in a COG that's probably not really something most people would want. It only applies to -w mode, code normally compiled by fastspin (for HUBEXEC) doesn't have the 8 parameter limit.
For converting spin to hubexec code, what options do I need to compile that?
That's the default for fastspin, so no options are required. In fact fastspin always produces a .p2asm (or .pasm for P1) file containing the hubexec code (LMM for p1).
If you're really keen on translating Spin to PASM, spin2cpp is probably the better tool, because it has more control over the options (under the hood fastspin and spin2cpp are the same, but they have different emphasis in the command line options they have). So for example you can do something like: to translate foo.spin into hubexec ASM code for P2. You can change where the code and data go explicitly with "hub" or "cog" options (beware, --data=cog hasn't been thoroughly tested).
But I definitely would suggest just compiling it to binary first with fastspin and making sure it runs on the P2 before trying to convert it to P2ASM.
I'll give it a try later as I don't have the time to follow thru today
C:/Program Files (x86)/Parallax/P2/CM2302/CM2302.spin2:245: error: Changing hub value for symbol temp
temp is defined:
temp long 0
con
HOME = 1
.
.
.
term.tx(HOME)
What if we had a Propeller program which would turn the Popeller and the SD card into a mass storage class device via USB? Then, we could address the SD card as a disk drive.
Adafruit already does this for many of their Circuit Python based microcontrollers. It works very nicely
That looks like there may be multiple definitions for temp.
I believe he's using a different terminal emulator than the one in FlexGUI. FlexGUI uses standard ANSI, but some Prop terminals use a different standard.
Yes, I am using PST which has control codes for moving the cursor around. This is in the code -- I will add a comment to indicate that special codes only work with PST.
con { pst formatting } HOME = 1 CRSR_XY = 2 CRSR_LF = 3 CRSR_RT = 4 CRSR_UP = 5 CRSR_DN = 6 BELL = 7 BKSP = 8 TAB = 9 LF = 10 CLR_EOL = 11 CLR_DN = 12 CR = 13 CRSR_X = 14 CRSR_Y = 15 CLS = 16Again, Alex and Jon - Thank you...
@ersmith I have a few questions:
1. Do you have Bitcoin Cash address so that I can send you some support? If you don't have a wallet go to bitcoin.com and get one, please.
2. Is there a way to call words in TAQOZ from spin2/c/bas code and receive back part of stack or a read a chunk of memory?
3. How much memory does FlexGUI use? I know this is a bit far out, but is it possible to get this ported to the Prop2 with some external ram for self-hosting or Prop2 to Prop2/Prop1 hosting?
Thanks,
hinv
I think @msrobots has experimented with this, so I believe it's possible but it is a bit of work. Perhaps he'll chime in. It would definitely be cool to have a standard TAQOZ interface object!
Self-hosting isn't going to be practical, I'm afraid, even for just fastspin (let alone flexgui, which is much bigger). The memory usage is reasonable by modern PC standards, but it's in the many megabytes range. Even if you could do an XMM version it'd likely be very slow.
Regards,
Eric
1. open a blank editor tab (file - new file)
2. type several pages of text
3. open another existing file before saving what you have typed
The file will be opened in the existing editor tab instead of a new one. All entered text is lost without warning, undo doesn't help.
https://forums.parallax.com/discussion/169620/hijacking-the-p2-eval-rom-now-hijacking-current-taqoz/p1
There are the three major problems.
1) is @"Peter Jakacki" -
2) is the memory layout of TAQOZ. It needs the first 64K of HUB (ROM-Version) or the first 128K of HUB (current Version).
3) one has to change the console I/O of TAQOZ from serial to a mailbox in HUB.
so how far am I?
1) is a non solvable 'problem' - Peter is as productive as @ersmith.
2) seems to be unsolvable with the SPIN2 interpreter, but I might be wrong there since SPIN2 is supposed to be relocatable code.
Fastspin and loadp2 allow you to compile (at least pure PASM) to say HUB $1008 use $1000 and $1004 as mailbox and combine the TAQOZ BLOB as binary file and the Fastspin created binary file together.
I am not sure if this still works and if it will work with BASIC,C and Spin too. I think it should.
3) is basically solved, alas Peter changed the way his vectoring of console I/O works so my approach in the thread mentioned above might not work with the current TAQOZ anymore.
Enjoy!
Mike
Whoops! Sorry about that. That's fixed in github now.
I guess this is meant to have some purpose if I followed the classical style of 4-spaces-per-tab formatting. But I think the auto-formating should not delete printable characters in any case.
I think this should be better now in the 4.2.5 release.
There are many bug fixes and optimizations in this version. There is also a new menu option to enable extra warnings, specifically to catch compatibility differences between fastspin and "standard" Spin/Spin2. This may help in porting code from fastspin to other compilers.
Would it show up in the list if it was connected?
Or is that not coded into this gui programmer?
So I was just curious has anyone attempted this?
Does the parallax wx device show up in the ports list when you have it connected?
Hey Clock Loop, YES, the parallax WX esp8266 device does work.
Glad I could help you, you can make donations to me at any time, if you like my help and work.
(just kiddin, keep it, and buy another WX or donate to FlexGUI.)
Not kidding about the WX esp device working with FlexGUI. It really does show up.
Make sure your firewall isn't blocking the port (32420) and flexgui program.
I use TERMINATOR as my default terminal program...
I also use the P1 defaults for the commands.
FlexGUI used to work, then one day it stopped.
I suppose I can try to get a new git of it... and see if it happens again.
Ok I will try that, thanks.
Ok, that worked, thank you.