FlexGUI 4.3.1: Program your P2 in Spin, BASIC, or C
ersmith
Posts: 6,050
The latest version of FlexGUI is available at:
https://github.com/totalspectrum/flexgui/releases/.
Get the "flexgui.zip" file from the latest release, and unpack it anywhere convenient (it should be a location that you have read/write access to, e.g. your desktop, rather than a system folder like "Program Files"). Both Windows and Macintosh binaries are included with this release.
NOTE: FlexGUI is not in any way affiliated with Parallax, and please do not direct any questions about it to Parallax support.
FlexGUI supports programming both the P1 and the P2, in BASIC, Spin, and C, and also comes with interfaces for Python, Forth, and Lisp programming (those last 3 languages rely on an interpreter to run on the P2, rather than compiling the code directly). The Spin support comes in two flavors: Spin 1 with extensions (if the file has a .spin suffix) and Spin 2 with extensions (if it has a .spin2 suffix). Either one can be compiled for either P1 or P2. There's not a lot of difference between them, mostly it's in the operators, e.g. to use the keyword operators like FRAC you'll have to use .spin2.
It's very easy to get started with FlexGUI. Just run flexgui.exe (or flexgui.tcl for the Mac). You'll see a window open. Type something like:
This release has a lot of improvements compared to earlier versions of FlexGUI. The BASIC language has many more operators and built-in functions (thanks in part to contributions by @JRoark ) and now supports multiple assignment and functions which return multiple values. The Spin language supports more of Chip's proposed Spin2 syntax, including method pointers. There have been many bug fixes, especially in the C compiler.
In the GUI, the Help menu has been expanded to allow easy access to language references. It's now possible to set the command output font in the "Editor Options..." menu, and there's also an option there to automatically reload files if they are changed in an external editor (e.g. if you're using the PropTool to edit Spin files but want to program them to your P2). The "Special" menu has options for downloading MicroPython, FORTH, or Lisp programs. The "Serial" menu now has an option for setting the baud rate. Under "Commands" are options for programming the flash; the "Flash program" can also be changed to an SD card loader to allow programming of binaries to SD cards.
Have fun, and please report any problems you run into either here or on the github issues page.
https://github.com/totalspectrum/flexgui/releases/.
Get the "flexgui.zip" file from the latest release, and unpack it anywhere convenient (it should be a location that you have read/write access to, e.g. your desktop, rather than a system folder like "Program Files"). Both Windows and Macintosh binaries are included with this release.
NOTE: FlexGUI is not in any way affiliated with Parallax, and please do not direct any questions about it to Parallax support.
FlexGUI supports programming both the P1 and the P2, in BASIC, Spin, and C, and also comes with interfaces for Python, Forth, and Lisp programming (those last 3 languages rely on an interpreter to run on the P2, rather than compiling the code directly). The Spin support comes in two flavors: Spin 1 with extensions (if the file has a .spin suffix) and Spin 2 with extensions (if it has a .spin2 suffix). Either one can be compiled for either P1 or P2. There's not a lot of difference between them, mostly it's in the operators, e.g. to use the keyword operators like FRAC you'll have to use .spin2.
It's very easy to get started with FlexGUI. Just run flexgui.exe (or flexgui.tcl for the Mac). You'll see a window open. Type something like:
print "hello from the P2"into the window, then press the "Compile & Run on P2" button. It'll prompt you for a name to save the file as (it needs to save the file before compiling); enter something like "hello.bas", since this is a BASIC program. You'll then get a terminal window popping open with the "hello from the P2" message. If you prefer C or Spin, you can also enter those languages instead; just name the file appropriately with a ".c" or ".spin" extension.
This release has a lot of improvements compared to earlier versions of FlexGUI. The BASIC language has many more operators and built-in functions (thanks in part to contributions by @JRoark ) and now supports multiple assignment and functions which return multiple values. The Spin language supports more of Chip's proposed Spin2 syntax, including method pointers. There have been many bug fixes, especially in the C compiler.
In the GUI, the Help menu has been expanded to allow easy access to language references. It's now possible to set the command output font in the "Editor Options..." menu, and there's also an option there to automatically reload files if they are changed in an external editor (e.g. if you're using the PropTool to edit Spin files but want to program them to your P2). The "Special" menu has options for downloading MicroPython, FORTH, or Lisp programs. The "Serial" menu now has an option for setting the baud rate. Under "Commands" are options for programming the flash; the "Flash program" can also be changed to an SD card loader to allow programming of binaries to SD cards.
Have fun, and please report any problems you run into either here or on the github issues page.
Comments
On the FlexBASIC-side of the house, a quick look through the manual shows we have a bunch of new toys to play with.
The new functions available are: BIN$(), COS(), Decuns$(), Delete$(), EXP(), HEX$(), Insert$(), Instr$(), InstrREV$(), LOG(), Oct$(), PinRND(), _Reboot(), SHR aka >>, SHL aka <<, Sin(), Tan(), WaitX(), WRPin(), WXPin(), WYPin()
We also have a new emerging datatype: LongInt and ULongInt (64 bits!, early support)
It's going to be a fun day!...
EDIT: HA! Eric included an "easter egg" in the form of "\include\libsys\stringlibp2.bas". If you INCLUDE this in your code like this: ...then you also get these new functions: LCase$(), LPad$(), LTrim$(), Reverse$(), RPad$(), RTrim$(), Space$(), Trim$(), UCase$()
I recall seeing a starting clock frequency calculator. Basically Chip's idea to give a frequency and have it calculate the dividers and multipliers internally and set it during program startup.
Sorry, yes, I forgot to put that in the release notes -- the Spin compiler in P2 now works like Chip's Spin2, and can calculate a starting mode based on the desired clock frequency and input frequency (the input frequency defaults to 20MHz). Most of the Spin samples have been ported to use that method of setting the clock.
It is supply voltage, temperature, and batch sensitive.
Right, I was referring to the calculation of the PLL mode setting bits. Just as Chip described for his Spin2 compiler, fastspin will take a block like: and figure out the bits to use in hubset to set the clock to the desired frequency (and set this at boot time). If _xinfreq is not given it defaults to 20 MHz.
RCFAST is a different kettle of fish, but calculating the mode value for that is easy since it's just 0x0 .
Any chance of getting a similar functionality in FlexBASIC? This could be very useful.
A 100% chance FlexBASIC has the same feature, but you have to use const instead:
fastspin
- Fixed Spin REV operator to match PNut's Spin2 definition.
- Optimize some P2 moves into BMASK or DECOD instructions
- Allow the word "asm" to be used as a label in Spin
- Allow use of _ in integers in BASIC DATA/READ
loadp2
- Reduced the timeout used when searching for a P2 (if a comm port is explicitly given then the behavior should be the same as before)
flexgui
- Fixed a packaging bug where some demo files were missing
- Fixed a problem with the "Spin" help menu item
In the console: Looking through the Makefile, I don't see anything that produces and copies .html files to the flexgui doc directory. I do see the .md files and something about pandoc. Is that supposed to create the .html's? After installing pandoc, I get an error about pdflatex... Are PDFs supposed to be created? The .md files are copied to flexgui's doc directory, should they be opened when the Help menus are selected? Currently installing MacTeX to see if that solves the problem...
dgately
dgately
The most recent FlexGUI .zip file has Mac binaries, so if you run into a problem building anything you could always install the binary . But it sounds like you have things sorted out now.
dgately
The flexgui.zip file includes both Windows and MacOSX binaries, and is available from my Patreon page or from:
https://github.com/totalspectrum/flexgui/releases
ERROR: timeout waiting for initial checksum: got -1
I had a very solid P2 download when using older tools (my loadp2 was v 0.017 IIRC) prior to using this later version. What's changed with these timeouts since then? It would be good to have a reliable download tool working again. Something is timing out too soon by the looks of it, or the downloader is not starting up correctly every time. Loader baud rate is just the default (i.e. was not setup in loadp2 command string).
Here's the relevant code in the download sequence...the code appears to either not be waiting long enough for the response, the auto baud space character is sent too soon (50ms wait not enough for the COG to be ready?), or received too late, or the P2 reset is not working. Not sure what else would cause it. I think if a wait_drain() is added after the transmission of the "~" and before the 50ms sleep it might be better, so we know that the ~ has been sent out the wire and received by the COG before we send the auto baud char and expect a response. This would remove any serial buffering lag affecting the transaction. It's a better way to go than put in hardcoded 50ms delays etc. Same probably goes for the 10ms sleeps in the retries.
Roger.
First batch is with the loader default download rate, second is with it set to 2000000 which is visibly faster to download.
So maybe the download rate has something to do with it? I noticed that the flexgui defaults only set the operational baud rate (-b) in the command line not the loader rate (-l) so perhaps the default download rate is different now via flexgui. This was without the auto detection variable in play.
Sometimes the errors seem to bunch up and then there are periods where it is not behaving as bad. I wonder if it might be background OS CPU load activity affecting the timeout...though my MAC is about 97% idle. When it kicks in it seems pretty bad.
64 SUCCESS
65 ERROR: timeout waiting for initial checksum: got -1
66 Warning: Unknown version , assuming CHIP
ERROR: got incorrect initial chksum: G
(47 0d 0a)
Raw results:
Is that using the P2 boot loader ?
I see a comment about autobaud, but the P2 boot autobaud is ">" not " " ?
Does change of clock mode also send a new autobaud char ? (should be before any other chars, but after P2 has had time to change speed )
General Chip comments have suggested to use autobaud refresh, but I'm not sure how critical that is, as the P2 oscillators are quite stable ( < 1% short term ?)
Maybe it actually does matter, and the slower downloads mean more time to drift, so have lower yields ?
What size is your download ?
The downloaded image file size in the above cases was 288384 bytes.
Also it's a lot slower but just got 100 resets in a row working fine with -SINGLE and the current 4.1.2 loadp2 codebase without my other wait_drain() modifications. That way uses the inbuilt loader and takes a different path in the software. So it looks like the timeout error is only related to this new protocol invented for new features etc. Something new in the MainLoader1.Spin2 file or the C file has got out of whack and causing timeouts, at least on my Mac, perhaps Linux too though the serial software pipeline in the OS could be different there vs the Mac implementation.
I'm also running on a MacBook Pro, but not seeing any loader failures. This is with loadp2 version 0.042 built on my Mac today (Feb 3 2020)... Your failures may not be caused by loadp2 itself. There may be some other system-related issue that you are seeing? Bad USB cable?
dgately
Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz
Looking at the MainLoader1.Spin2 code in some more detail here is the fix I've found that I now think solves the issue...using it I now have 100% success with the download at both 2Mbps and the default (which I think might be 921600bps). This was with 100 iterations each.
What seems to be happening is that on my machine the two space characters being transmitted from the loadp2 code get buffered together (one space initially then the first one from the retry loop) and are arriving back to back on the P2 and in the PASM code the 8 bit waitx delay after auto baud means that the smartpin rx is not always ready for the 2nd space to arrive and it can get missed. Adding a wait_drain() in the right spot plus a 1ms delay solves it.
A slower machine that introduces longer gaps into the serial transmission between these space characters, or one with no buffering, may not see this problem.
From MainLoader1.spin2:
' automatically detect baud rate
' based on length of shortest 1 or 0
' we see next
autobaud
dirl #rx_pin
waitx ##1000
mov mask, ##(1<<(rx_pin-32))
mov port, #1
test port, #1 wc ' set C to distinguish INA/OUTA
test port, #2 wz ' set Z (match on
setpat mask, #0 ' wait for pin lo (start bit)
waitpat
setpat mask, mask ' wait for pin hi (first 1)
waitpat
getct a
setpat mask, #0 ' wait for pin lo again (following 0)
waitpat
getct b
setpat mask,mask ' wait for pin hi again (end of 0 sequence)
waitpat
getct waitbit
sub waitbit, b
sub b, a
fle waitbit, b
mov a, waitbit
shl a, #3
waitx a
ret