FYI, I tried this today and ran the "blink1.bas" sample program. It worked fine on the ActivityBoard WX after I changed the PIN number to 26. I only tried a serial download.
I have a WX now, and while I haven't tried it on a Mac on Windows proploader found and used my Wifi module automatically (so spin2gui worked with it out of the box). Nice job on proploader, David -- it was very seamless and easy to use!
I tried my WX Activity Board setup again, it works, using spin2gui, BUT. This is a real big BUT, you can only have one WiFi board on that is transmitting. If you have two units on then chances are that spin2gui will not pick the right board port to use.
The only way around this issue for spin2gui, is to have a port choice column to pick the unit(port) that you are using. Since I will probably have more than one WiFi unit running at all times, at this time this scenario is not very practical.
You may want to consider setting up fastspin(BASIC) to run within SimpleIDE, then that COM choice problem could be resolved. SimpleIDE has the port selection choice, so you just pick the port, and program away.
Now, if you go to a command line process, or use something like Geany, this also becomes not practical. You will then have to figure out what the IP address is, of your WiFi module, and than include that with your method of working with the Propeller chip.
When I think about this now, I have had some problems with the way SimpleIDE works, for handling the port issue. You have to very aware of which port that you are going to use when you hit the program button. I have been caught on this many times having programmed the wrong unit because I did not check the port choice.
When I think about this now, I have had some problems with the way SimpleIDE works, for handling the port issue. You have to very aware of which port that you are going to use when you hit the program button. I have been caught on this many times having programmed the wrong unit because I did not check the port choice.
With Linux I can distinguish boards if the USB UART somehow is individual e.g. by having a unique serial number in its USB descriptor.
This works OOTB with FT232 UARTs which are delivered with a random serial number. CP2102 UARTs come not individualised but their EEPROM contents can be changed.
I tried my WX Activity Board setup again, it works, using spin2gui, BUT. This is a real big BUT, you can only have one WiFi board on that is transmitting. If you have two units on then chances are that spin2gui will not pick the right board port to use.
Ah, OK, I only have the one WX board, so it wasn't a problem for me.
You can always use the "Configure Commands..." menu item to change the proploader command line (for example to include '-i IPADDRESS' to select the board). I realize that's not very user friendly, but it will at least guarantee that you get the right board.
You may want to consider setting up fastspin(BASIC) to run within SimpleIDE, then that COM choice problem could be resolved. SimpleIDE has the port selection choice, so you just pick the port, and program away.
I submitted a pull request for SimpleIDE a while back to support fastspin (just the plain Spin version) but I don't think it's ever been merged. I'm not sure if SimpleIDE is still supported very actively.
I'm not really focused right now on developing the GUI, I'm trying to get the basic compiler finished first. But thanks for pointing out this issue. If I can think of a simple way to provide a board choice for spin2gui I'll add it.
There are new releases of fastspin and spin2gui up on github now. This version should fix the DHTnn_Object problem Ray found, as well as a few other bugs I ran into while testing.
If you haven't updated for a while, this version (3.9.7) also includes the try/catch handling and anonymous functions that were in 3.9.6, and reduces COG memory usage a lot.
I definitely suggest users update to the latest release if they're interested in BASIC support.
Just downloaded the latest spin2gui, and the problem persists.
Ray
rem test_temp.bas
' October 13, 2018
' Test of the CM2302 module on the WX Activity Board
dim cm2302 as class using "DHTnn_Object.spin"
let mscycles = clkfreq / 1000
sub pausems(ms)
waitcnt(getcnt() + ms * mscycles)
end sub
dim temp#,humid#,misc#
cm2302.StartDHTnn(8,22,@temp#,@humid#,@misc#)
do
cm2302.DHTnn_Read()
print "Temp ";(9.0/5.0)*temp# + 32.0;" Humid ";humid#
pausems 3000
loop
G:/fastspin/spin2gui/bin/fastspin -l -O1 -L ./lib G:/fastspin/programs/test_temp/test_temp.bas
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2018 Total Spectrum Software Inc.
Version 3.9.6 Compiled on: Oct 19 2018
test_temp.bas
|-DHTnn_Object.spin
|-|-FloatMath.spin
test_temp.pasm
Done.
G:/fastspin/programs/test_temp/test_temp.pasm(719) error: Unknown symbol Dhtnn_object_dhtnn_read_tmp003_
G:/fastspin/programs/test_temp/test_temp.pasm(771) error: Unknown symbol Dhtnn_object_dhtnn_read_tmp003_
child process exited abnormally
Aargh! Sorry Ray, somehow the wrong fastspin compiler got in the release (it should have been 3.9.7, not 3.9.6). It should be fixed now, could you try it again?
I downloaded the latest spin2gui, new problem has emerged. The program compiles without errors, but there is nothing being output to the terminal screen.
Also, the Compiler Output screen area is doing some kind of jiggling or slow weird updating of that area of the screen. But the main problem is that there is nothing being displayed to the terminal screen.
Ray
rem test_temp.bas
' October 13, 2018
' Test of the CM2302 module on the WX Activity Board
dim cm2302 as class using "DHTnn_Object.spin"
let mscycles = clkfreq / 1000
sub pausems(ms)
waitcnt(getcnt() + ms * mscycles)
end sub
dim temp#,humid#,misc#
cm2302.StartDHTnn(8,22,@temp#,@humid#,@misc#)
do
cm2302.DHTnn_Read()
print "Temp ";(9.0/5.0)*temp# + 32.0;" Humid ";humid#
pausems 3000
loop
Compiler Output
G:/fastspin/spin2gui/bin/fastspin -l -O1 -L ./lib G:/fastspin/programs/test_temp/test_temp.bas
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2018 Total Spectrum Software Inc.
Version 3.9.7 Compiled on: Oct 21 2018
test_temp.bas
|-DHTnn_Object.spin
|-|-FloatMath.spin
test_temp.pasm
Done.
Program size is 8832 bytes
cmd.exe /c start G:/fastspin/spin2gui/bin/proploader G:/fastspin/programs/test_temp/test_temp.binary -r -t -k
Terminal screen
Opening file 'G:/fastspin/programs/test_temp/test_temp.binary'
Downloading file to port 192.168.1.147
8832 bytes sent
Verifying RAM
Download successful!
[ Entering terminal mode. Type ESC or Control-C to exit. ]
I think the problem is that fastspin is *too* fast now . The StartDHTnn method relies on the remote COG reading its pointers from the stack, which is fine in "regular" Spin (where the Spin interpreter is a lot slower than the remote COG) but can be a problem in fastspin. I stuck a small delay after the init, like:
and started getting output. Note that it should be the waitcnt/getcnt combo, not pausems -- pausems is a function call so it may mess up the stack that the COG is still reading.
I always get a temperature of 32 and humidity of 0 from my Activity board. But the same thing happens when I try the regular Spin DHT11_Test.spin (compiled with openspin or fastspin, both give the same results). I don't know what needs to be done to change that.
It sort looks like it has something to do with the Spin object, but I do not know what to do with it. I tried something a little different just see what would happen when I put the 'cm2302.DHTnn_Read()' into a sub, I get some kind of different error. I thought it would just hang, and not print anything to the terminal.
Ray
rem test_temp.bas
' October 13, 2018
' Test of the CM2302 module on the WX Activity Board
dim cm2302 as class using "DHTnn_Object.spin"
let mscycles = clkfreq / 1000
sub pausems(ms)
waitcnt(getcnt() + ms * mscycles)
end sub
dim temp#,humid#,misc#
cm2302.StartDHTnn(8,22,@temp#,@humid#,@misc#)
sub cm2302
cm2302.DHTnn_Read()
end sub
do
'cm2302.DHTnn_Read()
cm2302
print "Temp ";(9.0/5.0)*temp# + 32.0;" Humid ";humid#
'waitcnt(getcnt() + 10_000_000)
pausems 3000
loop
G:/fastspin/spin2gui/bin/fastspin -l -O1 -L ./lib G:/fastspin/programs/test_temp/test_temp.bas
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2018 Total Spectrum Software Inc.
Version 3.9.7 Compiled on: Oct 21 2018
test_temp.bas
|-DHTnn_Object.spin
|-|-FloatMath.spin
G:/fastspin/programs/test_temp/test_temp.bas(5) error: Internal error: unknown type 51 passed to IsArrayType
child process exited abnormally
The "internal error" should be a more helpful error message . The problem is that you used the same symbol name "cm2302" both for the object and for the sub, and so the compiler got confused. If you change the sub name to something like "cm2302_read" it will compile (but not work, for that you need the delay that I mentioned earlier).
I have tried to render some html code from the sdcard. However the input string length appears to be limited to only 127 characters. The other issues is that we do not know the file length at the time of read back, so we can't define s$ length
openfile(3, "test2.txt", "r")
s$ = input$(127, 3)
Your readback code that I have been looking at.
#ifdef TRY_READ
pausems 500
' try reading it back
print "testing read"
openfile(3, "test2.txt", "r")
s$ = input$(127, 3)
if s$ then
print "read back:"
print s$
else
print "got end of file"
endif
close #3
#endif
print "all done"
catch err
print "caught error: "; err
end try
input$(N, handle) reads up to N bytes from the file. I don't think there should be any limit on N, except for memory (and in particular the size of the garbage collected heap, set by HEAPSIZE; if you want to read large files you'll have to add a "const HEAPSIZE = XXXX" declaration, where XXXX is some big number (but not so big that it overflows memory -- sorry, this isn't automatic right now, so you have to do some experimentation).
You can use multiple input$(N, handle) calls and add them together. So for example the read loop could look like:
dim file$
file$ = ""
do
s$ = input$(20, 2) ' read up to 20 characters at a time
file$ = file$ + s$
loop until s$ = "" ' loop until end of file
print file$
At least, that's the theory. I think there are probably bugs in practice
The first issue was HEAPSIZE however the html file was less than 254 bytes. Therefore
s$=input$(254,3) was not full filled before it reached end of file!
Looks like I have to count the chars in a getc loop before I build s$
or is there another way to get the file size ?
I like the idea oft getting s$ by concatenating the s$ blocks in a loop
The first issue was HEAPSIZE however the html file was less than 254 bytes. Therefore
s$=input$(254,3) was not full filled before it reached end of file!
That's OK -- input$() will read as much as it can up to the limit you give it. That is, the 254 is a maximum size, but the string returned by input$ could be smaller. If the file only has 200 characters than input$(254, 3) should return a 200 character string. (The current implementation does actually allocate space for 254 bytes in this case, so there is some memory wasted.)
Looks like I have to count the chars in a getc loop before I build s$
or is there another way to get the file size ?
If you just read small chunks at a time and concatenate the chunks to build a bigger string then there's no need to know the file size. This string concatenation will only work if the file doesn't contain NUL bytes (0). For binary files we'll need another solution, but for text files it should be fine.
Thinking about it, building a string for simply printing a file makes no sense. Printing a ubyte in a getc loop until eof is much better, so will post something to the other thread later for other comments.
Something strange is going on with latest spin2gui program. I used the -p COMxx in Configure Commands, to select a com port. It seems to compile and run, but I am seeing some garbage characters on the terminal screen. Not sure where that is coming from.
It looks like the print string is getting clobbered. I am using a board that does not have any WiFi components.
Ray
rem test1.bas
' Declarations
const pin = 26
let mscycles = clkfreq / 1000
direction(pin) = output
'******************************
'Main
print "will I see something"
do
output(pin) = not output(pin)
pausems 1000
loop
'******************************
'Subs and Functions
sub pausems(ms)
waitcnt(getcnt() + ms * mscycles)
end sub
Opening file 'G:/fastspin/programs/test1/test1.binary'
Downloading file to port COM3
1676 bytes sent
Verifying RAM
Download successful!
[ Entering terminal mode. Type ESC or Control-C to exit. ]
ÇÇÇÇ ÇÇ ÇÇ ÇÇ Ç Ç Ç ÇÇÇ »{Ésomething
Ray: are you using a QuickStart board or something similar? I have sometimes seen boards where there is some noise at the beginning. I get this in any language (not just fastspin). I think it's because pin 30 is floating when the program starts up and so there's a problem syncing the serial port.
On my WX Activity board your program runs without issue.
This started showing up on my WX Activity Board. The latest board, an Activity Board (no WiFi), shows that problem also. I just tried a Propeller Project Board, that also shows the same problem. So, of the three boards, they all show the clobbered print string.
I think that I might have to figure out a different way of working with fastspin(BASIC), this getting to be too unpredictable.
I opened up a command prompt window in Windows 10, and I manually did a proploader command. It sort looks like fastspin(BASIC) is not cooperating with the new proploader.exe program, I could be wrong about this.
For the people that are not using proploader.exe, what is your setup for working with fastspin(BASIC)?
Ray
G:\fastspin>proploader -p COM3 -t g:/fastspin/programs/test1/test1.binary
Opening file 'g:/fastspin/programs/test1/test1.binary'
Downloading file to port COM3
1676 bytes sent
Verifying RAM
Download successful!
[ Entering terminal mode. Type ESC or Control-C to exit. ]
ÇÇÇÇ ÇÇ ÇÇ ÇÇ Ç Ç Ç ÇÇ┘e something
Thanks Ron, but that did not help, still getting a clobbered print string. I would like to see this work because when I debug a program, I use a terminal output to see the debug results.
While looking at the proploader.exe program I noticed it has a command for writing to the SD card, I wonder how that works. Also, I noticed a capability for writing a program to the eeprom, I will probably have to try that also.
Not to step on anybody's toes or to make people upset, I tried the following small program below with the proploader.exe in the Command line window. It seems that the print string in the C program seems to be showing as expected, in the terminal window.
It seems like something changed in the proploader.exe vs the propeller-loader.exe that fastspin(BASIC) was using, originally.
Not sure what to check or verify next.
Ray
/*
Blank Simple Project.c
http://learn.parallax.com/propeller-c-tutorials
*/
#include "simpletools.h" // Include simple tools
int main() // Main function
{
// Add startup code here.
print("This is a test\n");
while(1)
{
// Add main loop code here.
}
}
G:\fastspin>proploader -p COM3 -t -r g:/programs/propeller/load_test/load_test.elf
Opening file 'g:/programs/propeller/load_test/load_test.elf'
Downloading file to port COM3
8284 bytes sent
Verifying RAM
Download successful!
[ Entering terminal mode. Type ESC or Control-C to exit. ]
This is a test
I do have to add a small delay to make Ray's code work.
The 1 ms delay is an arbitrary value at this stage. I am using Windows 10, like Ray.
I use fastspin --fcache=0 -e -O1 %f in a batch file to compile and
propeller-load -e -p3 -r -t %1.eeprom in a batch file to load.
Without a short delay the first character is missing from the output in the command line window.
It is the just the same if I use my terminal software Tera Term Pro after a prop reset.
I have checked this on both my Prop demo board and on my Arty7 FPGA board running P1.
I was suspicious of some ringing (when tthe DIR reg is changed) on my low quality USB cable to the Prop Demo Board but I have high quality USB cable to the FPGA board and the results are identical.
And good quality PSUs for both boards
Ray is using different pin out, whereas I am using the default pin which is probably pre set to out,
I should nave checked that.
Have you tried it without the --fcache=0? That shouldn't be necessary any more, and definitely will affect performance. I also tend to run directly rather than loading into EEPROM, which probably changes the startup timing.
Comments
I have a WX now, and while I haven't tried it on a Mac on Windows proploader found and used my Wifi module automatically (so spin2gui worked with it out of the box). Nice job on proploader, David -- it was very seamless and easy to use!
The only way around this issue for spin2gui, is to have a port choice column to pick the unit(port) that you are using. Since I will probably have more than one WiFi unit running at all times, at this time this scenario is not very practical.
You may want to consider setting up fastspin(BASIC) to run within SimpleIDE, then that COM choice problem could be resolved. SimpleIDE has the port selection choice, so you just pick the port, and program away.
Now, if you go to a command line process, or use something like Geany, this also becomes not practical. You will then have to figure out what the IP address is, of your WiFi module, and than include that with your method of working with the Propeller chip.
When I think about this now, I have had some problems with the way SimpleIDE works, for handling the port issue. You have to very aware of which port that you are going to use when you hit the program button. I have been caught on this many times having programmed the wrong unit because I did not check the port choice.
Ray
The magic is done by UDEV rules which can make symlinks to the real device entry.
$ fgrep -B2 GG /etc/udev/rules.d/99-local-usb-serial.rules SUBSYSTEM=="tty", \ ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A800BSBW", \ OWNER="yeti", GROUP="yeti", MODE:="0660", SYMLINK+="GG-PP-SD-USB-HK-C"Just one piece is missing: Propeller loaders scanning for Propellers on the ports ignore the links. But they work as expected: Are you using something Linux-ish?Or maybe someone knows how to do something similar on other OSes?
You can always use the "Configure Commands..." menu item to change the proploader command line (for example to include '-i IPADDRESS' to select the board). I realize that's not very user friendly, but it will at least guarantee that you get the right board.
I submitted a pull request for SimpleIDE a while back to support fastspin (just the plain Spin version) but I don't think it's ever been merged. I'm not sure if SimpleIDE is still supported very actively.
I'm not really focused right now on developing the GUI, I'm trying to get the basic compiler finished first. But thanks for pointing out this issue. If I can think of a simple way to provide a board choice for spin2gui I'll add it.
Regards,
Eric
If you haven't updated for a while, this version (3.9.7) also includes the try/catch handling and anonymous functions that were in 3.9.6, and reduces COG memory usage a lot.
I definitely suggest users update to the latest release if they're interested in BASIC support.
Eric
Ray
Thanks,
Eric
Also, the Compiler Output screen area is doing some kind of jiggling or slow weird updating of that area of the screen. But the main problem is that there is nothing being displayed to the terminal screen.
Ray
Compiler Output Terminal screen
I think the problem is that fastspin is *too* fast now
I always get a temperature of 32 and humidity of 0 from my Activity board. But the same thing happens when I try the regular Spin DHT11_Test.spin (compiled with openspin or fastspin, both give the same results). I don't know what needs to be done to change that.
Thanks for your help testing this!
Eric
Ray
I have tried to render some html code from the sdcard. However the input string length appears to be limited to only 127 characters. The other issues is that we do not know the file length at the time of read back, so we can't define s$ length
Your readback code that I have been looking at.
#ifdef TRY_READ pausems 500 ' try reading it back print "testing read" openfile(3, "test2.txt", "r") s$ = input$(127, 3) if s$ then print "read back:" print s$ else print "got end of file" endif close #3 #endif print "all done" catch err print "caught error: "; err end tryYou can use multiple input$(N, handle) calls and add them together. So for example the read loop could look like: At least, that's the theory. I think there are probably bugs in practice
I forgot to document it, but if you leave out the h and use just plain `input$(n)` then it reads `n` characters from the default channel.
The first issue was HEAPSIZE however the html file was less than 254 bytes. Therefore
s$=input$(254,3) was not full filled before it reached end of file!
Looks like I have to count the chars in a getc loop before I build s$
or is there another way to get the file size ?
I like the idea oft getting s$ by concatenating the s$ blocks in a loop
Ron
If you just read small chunks at a time and concatenate the chunks to build a bigger string then there's no need to know the file size. This string concatenation will only work if the file doesn't contain NUL bytes (0). For binary files we'll need another solution, but for text files it should be fine.
I think fsrw does have a getfilesize method too.
Regards,
Eric
Thinking about it, building a string for simply printing a file makes no sense. Printing a ubyte in a getc loop until eof is much better, so will post something to the other thread later for other comments.
Thanks again
Ron
It looks like the print string is getting clobbered. I am using a board that does not have any WiFi components.
Ray
On my WX Activity board your program runs without issue.
I think that I might have to figure out a different way of working with fastspin(BASIC), this getting to be too unpredictable.
Ray
For the people that are not using proploader.exe, what is your setup for working with fastspin(BASIC)?
Ray
Ron
While looking at the proploader.exe program I noticed it has a command for writing to the SD card, I wonder how that works. Also, I noticed a capability for writing a program to the eeprom, I will probably have to try that also.
Ray
It seems like something changed in the proploader.exe vs the propeller-loader.exe that fastspin(BASIC) was using, originally.
Not sure what to check or verify next.
Ray
/* Blank Simple Project.c http://learn.parallax.com/propeller-c-tutorials */ #include "simpletools.h" // Include simple tools int main() // Main function { // Add startup code here. print("This is a test\n"); while(1) { // Add main loop code here. } }Did you try the freshest version?
Can you build FastSpin from git sources?
If you put the print in a loop, does the corruption happen every time, or is it only for the first time it is printed?
Does the blinking part of the program work correctly?
I do have to add a small delay to make Ray's code work.
The 1 ms delay is an arbitrary value at this stage. I am using Windows 10, like Ray.
I use fastspin --fcache=0 -e -O1 %f in a batch file to compile and
propeller-load -e -p3 -r -t %1.eeprom in a batch file to load.
Without a short delay the first character is missing from the output in the command line window.
It is the just the same if I use my terminal software Tera Term Pro after a prop reset.
I have checked this on both my Prop demo board and on my Arty7 FPGA board running P1.
I was suspicious of some ringing (when tthe DIR reg is changed) on my low quality USB cable to the Prop Demo Board but I have high quality USB cable to the FPGA board and the results are identical.
And good quality PSUs for both boards
Ray is using different pin out, whereas I am using the default pin which is probably pre set to out,
I should nave checked that.
Hope it helps
Ron
Same result, still need the 1ms pause.
Misses first two chars.
Ron