Catalina 2.8
RossH
Posts: 5,519
I have just uploaded a new beta (BETA_2) of Catalina 2.8 to sourceforge (here). If you downloaded the previous beta, I suggest you replace it with the BETA_2 release.
This release is NOT finished, and it has not been tested as thoroughly as I would like - so you download and use it at your own risk. However, I have promised the new graphics driver to a few people, and it just seemed easier to upload the whole of Catalina 2.8 (as it currently stands) rather than try and isolate out just the new graphics driver.
Here is a quick summary of what's new in 2.8:
For more details on the low level file access support, see the catalina_fs.h file and the test_catalina_fs.c example in the demos subdirectory.
For more details on the multithreading support, see the catalina_threads.h file and the examples in the demos\multithread subdirectory. There is also a README in that directory.
For more details on the graphics library, see the catalina_graphics.h file and the example in the demos\graphics subdirectory. There is also a README in that directory. I have attached two working versions of the graphics demo in C, both compiled for the Hydra:
Ross.
This release is NOT finished, and it has not been tested as thoroughly as I would like - so you download and use it at your own risk. However, I have promised the new graphics driver to a few people, and it just seemed easier to upload the whole of Catalina 2.8 (as it currently stands) rather than try and isolate out just the new graphics driver.
Here is a quick summary of what's new in 2.8:
- The new graphics library and plugin. This is functionally equivalent to the Parallax Graphic object in the OBEX. Currently only TV output is supported - I will add VGA output to the full 2.8 release. You include the plugin by specifying -D GRAPHICS on the command line, and the library by specifying -lgraphics.
- The new multithreading kernel and library. You can now run kernels on multiple cogs, with each kernel running multiple threads. You can also dynamically swap threads between kernels running on different cogs.
- The new SMM mode, which uses a two-phase load technique to allow up to twice as much program code to be loaded into a standard Propeller. The new loader has been implemented in Catalyst, and is activated by simply adding the option -D SDCARD to the command line. However, to tell Catalyst that this is an SMM program and not an XMM program, the program must also be given an extension of .smm. To make thing perfectly orthogonal, I also now allow programs to be called .xmm and .lmm, and Catalyst will use the appropriate loader. For non-SMM programs, you can still stick to the normal extension (i.e .bin) if you prefer.
- The new Catalina file access functions, which allow SD card access from much smaller programs, since they do not pull in the whole of the normal stdio C library functions. They also have managed and unmanaged versions of the standard file functions, with the unmanaged versions not requiring any dynamic memory management (so programs don't need malloc).
- A Catalina code generator fix for a bug that I found while testing the graphics driver.
- New RESERVE_COG functionality to allow a cog to be reserved for use by a support program. This cog will be loaded by Catalina at the start of the load process (before any XMM RAM is accessed), and will be left running throughout the loading and execution of the C program. This could be used (for example) to load an XMM RAM access cog (if the XMM RAM access cannot be fitted into the XMM kernel).
For more details on the low level file access support, see the catalina_fs.h file and the test_catalina_fs.c example in the demos subdirectory.
For more details on the multithreading support, see the catalina_threads.h file and the examples in the demos\multithread subdirectory. There is also a README in that directory.
For more details on the graphics library, see the catalina_graphics.h file and the example in the demos\graphics subdirectory. There is also a README in that directory. I have attached two working versions of the graphics demo in C, both compiled for the Hydra:
- graph_0.binary is an LMM program which will run on any Hydra. However, space limitations mean I have had to reduce the normal TV driver resolution from the usual 256* 192 to 240 * 160.
- graph_2.eeprom is an XMM program that requires the HX512 SDRAM module, and it must be programmed into EEPROM. While it is slower than the LMM version, it can do the usual 256 * 192 resolution graphics.
Ross.
Comments
i will download it as soon as i'm home from work and give it a try.
Unfortunately it is not possible for me to start coding till monday but i will play arround a little.
Greetings from austria
wuut
It´s been a while since i did something on my Hydra, mainly because of many stuff i´ve currently to do but now I have to move on :P
Regards
i have tried out your "graph_0.binary" and loaded it to my Hydra without problems
but if i try building the graphics demos with "build_all hydra" it doesn't work..
any suggestions?
Also i did not quite get the thing
actully what workflow do i need to do to get a bmp visible on the tv :<
sry for that dumb question
Greetings wuut
Catalina (like everything to do with C) is case sensitive. Try:
or (for double buffering, which looks much smoother)
If that doesn't work, please send me the output of the command.
As for your second question, I'm not sure I understand it. The graphics library is a 100% functional equivalent of the Parallax graphics object (and TV driver). You should do things in exactly the same way you would do them with those drivers. I have provided routines to give you access to all the underlying bitmaps (including the double buffer bitmap), the color values and the screen tile map.
I would encourage you to look at the C version of the Parallax Graphics demo, and compare it with the SPIN version.
Ross.
I have just uploaded a new beta (BETA_2) of Catalina 2.8 to SourceForge.
This release fixes a couple of problems with the previous beta (e.g. some code was accidentally omitted to do with serial communications between cogs on multi-prop platforms, and some of the "build_all" batch files had some bugs).
But the main reason for this release is to add the new RESERVE_COG functionality. This allows a cog to be loaded at the start of the load process (e.g. before any XMM RAM is accessed) and this cog will not be disturbed during the remainder of the load process. This is intended to allow things such as a dynamic RAM refresh cog to be loaded and left running throughout the process of loading and starting a C program.
The example program provided (Catalina_Reserved_Cog.spin) simply toggles an I/O pin as proof that it is started and left running. The reserved cog is currently set to be a single cog (cog 6). If more than one reserved cog is required, this can be set in Catalina_Common_Input.spin by reducing the value of LASTCOG. Note that it is the responsibility of the user (or the target) to ensure that only cogs 1 to 5 are loaded (e.g. by plugins) during the load process if the RESERVE_COG option is specified.
To compile an individual program to include the RESERVE_COG, simply compile it with that option on the command line. For example:
However, it is more important that (depending on what the reserved cog actually does) the RESERVE_COG be specified on ALL loaders and also on the various Catalina utility programs -
e.g. for the HYBRID:
cd catalyst build_all HYBRID RESERVE_COG cd ..\utilities build_all HYBRID RESERVE_COG cd ..\ram_test build_all HYBRID RESERVE_COG cd ..\demos build_all HYBRID RESERVE_COG ... etc ...See the file Catalina_Reserved_Cog.spin for more details.Ross.
Cheers.
--Steve
I just downloaded it. I am running on an AMD64 bit platform and bought a Gadget Gangster to avoid wiring while testing under Linux.
I modified the code to accept BSTC and to compile correctly for lmm compiles (it does now, the fixes are nearly trivial); I also fixed the major warning list in the blackbox debugger compile (longs are being scanf'd/printf's as ints ... not so good) -- and after that, I am left with one error which I am not sure what to make of:
blackbox_y.y:528.3-542.1: warning: rule useless in parser due to conflicts: var_type: '*'
That's not apparently a show stopper, for blackbox does run and brings up main from the "hello world" program in demos that I compiled.
catdbgfilegen has a couple of problems: I noticed that the actual file was a wrapper bash script under linux to launch the application under the program "mono". I modified the path to work with my account install; but my library is version 2.0, and it is looking for dll version 1.0; of course being under linux a recompile isn't possible directly for catdbgilegen is visual studio (windows) -- and the amount of work isn't worth it, so I just sym linked it and the program runs. The second problem is peculiar to BSTC, possibly, the list file extension is ".list" not ".lst" and there is a peculiar assumption made in catdbgfilegen code that the extension will be three letters long (DOS legacy) ... so it incorrectly renames ".list" as ".ldbg" (it's overwriting the extension with 3 letters, leaving the "l"); again I just rename it manually (or change the extension in blackbox to .ldbg -- as a KLUDGE) but that is a bit of a hassle.
After all of that, which is good enough, ... I am having serious trouble with the serial loaders (both payload and BSTL)
BSTL, at least, will detect the propeller (Gadget Gangster USB platform) and download to it, claim that it verified something, and exit gracefully.
But when I use payload, the following happens:
...
andrew3@Rocky:~/src/propeller/demos$ payload hello_world.binary 15
Using Propeller (version 1) on port /dev/ttyUSB0 for first upload
Segmentation fault
andrew3@Rocky:~/src/propeller/demos$
...
It is correct in its identification of the propeller port.
The program debugger blackbox can't operate the serial port, and even though BSTL does -- the spin program appears to be reset immediately upon loading -- for I am unable to get a simple serial program written in spin to send characters back to a serial terminal:
This is what I am trying to run as a simple test (no led, just the serial).
Spacing is of course messed up by the thread host....it is correct in the program.
When I try and run payload under gdb to locate the segfault, I am given a different error message:
... (gdb) ...
Starting program: /home/andrew3/.local/bin/payload "hello_world.binary"
Using Propeller (version 1) on port /dev/ttyUSB0 for upload
Error: No response received
Program exited normally.
...
I haven't recompiled it for -ggdb3, but even so -- I don't understand why it would be different, and it consistently succeeds under gdb and segfaults on the command line. I am not sure how to attack this problem, and ideas?
--Andrew.
You can ignore the blackbox error - I'll fix it one day, but it does not currently affect the use of that program. Send me details of the other fixes you've made and I'll include them (with appropriate credit) in the next release of Catalina.
I deliberately left bstc support in Catalina (but disabled it) because I do mean one day to add it back in. The reason I disabled it was that bstc was fine for LMM but could not (at the time) also do the XMM modes. I keep meaning to get in touch with Brad Campbell and sort this out, but finding the time is my main problem. I'd be happy for you to take this on if you want.
catdbgfilegen is a utility written by Bob Anderson for his BlackCat debugger. I "borrowed" it for use with BlackBox, and it works for me because I use homespun, not bstc. If you want Bob to add bstc support to BlackCat, then there is a thread about his BlackCat debugger here - I'm sure if you post your issues in that thread he'll respond. But it sounds like you got it (mostly) working anyway.
As to the payload problems - I'll help out if I can. But if you are having problems with bstl as well, it might point to a problem with your machine and/or configuration. You should probably also contact Brad Campbell directly about any bstc/bstl issues.
So, to progress this we need to follow up on a couple of things:
- Details of your OS and version (I presume you are using some Linux variant?).
- Can you successfully use the Parallax loaders (e.g. the propellent loader) on your system? I don't actually know if propellent can be made to run under some emulation mode such as Wine, but it may be worth a try.
- What is the "15" you are including in the payload command? Is this a file name?
- The program you are attempting to debug is a SPIN program. Neither BlackCat nor BlackBox can debug SPIN programs, because the required blackcat support is not being included (see BlackCat_DebugCog.spin in the target directory). Even if it were included it would not be able to do much (it could maybe examine memory, but it could not insert breakpoints or display the source). There are other debuggers intended for SPIN - BlackCat and BlackBox are both source level debuggers intended specifically for Catalina C programs.
Ross.Thanks for the links. The "15" is a typo -- but it doesn't matter if it is there or not, the result is the same.
1) How would you like the "diff" files for blackbox and catbind? diff -bu ? I'll post/PM them to you and you can review them once I know your preference.
2) You're correct, the example program I showed is a spin program -- BUT I wasn't trying to debug it with blackbox -- I was just trying to prove whether or not the Gadget Gangster was properly downloading and running *any* program at all; eg: out of frustration; sorry I wasn't clear.
3) What I was doing with blackbox earlier: I ran: catalina -g3 -ab -b hello_world.c -lc
That worked flawlessly and produced a binary; and doing "bstl hello_world.binary" loaded it; and then I had to "mv hello_world.ldbg hello_world.dbg" and now I am able to start blackbox starting happily; (detour, I'll return to this in a minute)
4) I am on a machine running Ubuntu 10.10 (not my own machine). The gadget gangster is /dev/ttyUSB0 (I think it's just a FTDI usb-RS232/422 chip hard-wired directly to the propeller pins P31/P30 without 12V inverters or drivers): The reason I bought the board was
---a) It is fully pre-wired
---b) It is advertised with a linux based package (BST) so I assumed it ought to work out of the BOX
---c) It's rs232 interface is not jury rigged with extra transistors as an "alternate" method of downloading
---d) I had hand wired a proto board 6 months ago with the 40pin dip propeller, and had it working quite well with the windows based Parallax SPIN tools; BUT -- My personal machine, and the host for the robotics server, is a Slackware 13.1 box (32 bit only). I never was able to get a download to work on that machine either -- payload would simply fail to load ("no response") and BSTL would find the propeller but fail to load. I thought the extra transistors and things I had to use because I had a true prolific RS232 dongle might have been causing the failure, so I bought the Gadget Gangster to rule those problems out.
On the present machine -- I re-download all the latest sources for Catalina and binaries for BST; and I made corrections for compile time warnings, and adjustments to allow BSTC to replace homespun; Now that I am trying to do downloads to the Gadget Gangster -- I find myself in the exact same situation as I was with my hand-made proto-board.
5) I changed the /dev/ttyUSB0 to "chmod 666 /dev/ttyUSB0" as an extra precaution, just now, and attempting "blackbox hello_world", I get the same results as always: So, the failure is again at the communications level.
6) Although I know I can download using windows tools -- I need to be able to do remote maintainence in a situation where there will not be enough space to run a virtual box ; and I must be able to re-load the propeller with upgraded software. Payload has source-code, so I figure getting it to work is worth my time & helping the community.
7) Gadget gangster specifications can be found here:
http://gadgetgangster.com/find-a-project/56.html?projectnum=257
http://gadgetgangster.com/scripts/displayasset.php?id=503
Just email me the amended sources. You don't have to diff them (but you can if you want) - email them to me at ross@thevastydeep.com
I'll dig out my version of Ubuntu - I have tested on that platform in the past, but I generally now work on Fedora 12.
Just to confirm - From point 3 it seems you can load programs with bstl and debug them with blackbox, but you can't load them with payload? But in point 4 you can't communicate with the program using blackbox. How did you load it - with bstl again? This is odd, because the underlying comms software is the same for both programs. I don't understand why it would work in point 3 but not in point 4. Can you tell me the exact catalina and load commands (bstl or payload) that you used to produce the outcome in point 4?
I agree it looks like the failure is at the comms level - but if this is the case then I don't understand why blackbox worked at all in point 3.
By the way, is there some reason you can't use homespun? I'd like to see if the same results are produced for binaries compiled with homespun instead of bstc (for example, with blackbox there could be a problem with the debug cog not starting correctly).
Ross.
Hopefully you have the files now. The problems of #4 are mostly from six months ago and are background for what I am trying to do now: I don't know whether bstl works or not ... I can't tell.
BSTL will locate the Propeller, claim that it is downloading (and from bst, it claims that it is verifying), and then return success. So, I would *assume* the program loads correctly using bstl -- however, when I try to run the blackbox debugger the error messages in my previous post appear. The exact command sequence (w/ abbreviated output) is as follows given the source files I sent you. This is all run from a bash shell in the demos directory of the catalina program (latest edition).
catalina -g3 -ab -b hello_world.c -lc
...option -x ignored
...Found a USB Serial Device
...etc
bstl hello_world.binary
...Brads SpinTool Loader v0.05 - ...
...Found a USB Serial Device
...Propeller Version 1 Found!
(YAY!...So, it looks like it succeeded...)
ls hello_world.*
hello_world_1.c hello_world_3.c hello_world.c hello_world.ldbg
hello_world_2.c hello_world.binary hello_world.debug hello_world.list
(Caution/Note .ldbg instead of .dbg extension because of catdbgfilegen's issue, in *my* blackbox
I changed it to load .ldbg so I don't have to keep manually renaming the file ... but that isn't something
I think you would want to release as it is, for it would annoy people using homespun.
The best solution is to contact the author, or have someone with visual studios modify the catdbgfilegen appropriately to work with both kinds of files. Also, the thought occurs to me to just modify the blackbox parser to be able to parse microsoft dbg format, as well as standard unix .stabs (debug) format. Then catdbgfilegen would be optional.
In any event, at this point I can run blackbox:
blackbox hello_world
However, it is not able to communicate with the chip; so it just prints the first line and then fails the moment communication is attempted.
PAYLOAD:
The only difference with using payload is that it segfaults during the load on this particular ubuntu installation (it was completely re-installed from scratch about a week ago, so it is pristine ubuntu 10.10):
I looked at payload's source-code, and watched debug messages during its' run -- so I know that payload obviously *IS* finding the propeller, and opening the serial port correctly. It succeeds in doing the LFSR (linear feedback shift register) algorithm to detect the propeller and begin programming it....
The failure happens on the second step when it attempts to load the software.
I am sure I will be able to trace the segfault down soon, but for some reason it doesn't segfault when using gdb --- therefore, I am injecting code to figure out where the failure is and it will take a few hours.
I can install homespun. I don't have a link to it; or , quicker, if you have a binary compiled on your machine for blackbox of the hello_world.c demo -- you could just email it to me and I can try that code. I suppose BSTC could be malfunctioning.
A second thought occurs to me, and that is the RS232 connection to the propeller is direct from the FTDI chip; That means the signal are not inverted by a 10-12 volt amplifier (True RS232 buffers like the 1488 are inverting amplifiers). In the propeller source code for the full duplex serial, it allows me to use either inverting or NON-inverting mode to communicate. When I run blackbox, it sends a character 'h' and then receives back an unexpected -1 (0xFFFF...) which usually means error. If the polarity of the serial communication of blackbox was mismatched with that of the propeller serial driver -- I would expect that to happen; I don't see a command line switch that I can use to change the polarity for black box, though, to test it: what kind of serial connection does the hydra, etc, that Catalina was developed on have? Do you have a schematic (or link) that I can look at of a system that blackbox has been used to debug on? If so, I can figure it out from that.
P.S. sorry about the long posts ... I am a speed typer and frustrated.
cheers.
--Andrew
I notice a bug which can be causing the segfault in payload. The machine I run on is 64 bit, therefore type u32 is likely 64 bits long (not 32). The pointer arithmetic in the upload routine assumes 32 bits (/4), which really needs to be sizeof(u32) not the constant 4. There are other side-effects of the 64 bit processor, I'll send you the code when I figure out how to fix it.
--Andrew.
I just had a quick look at your code changes - thanks - but as soon as I saw them I realized most of your problems are probably due to you compiling in 64 bit mode - this is something I've never tested as I don't have access to a 64 bit Linux machine. But before I start tackling those (there are probably a few more curly ones buried in various places) I'd like to get you up and running in 32 bit mode so we can identify whether or not the comms failiures are due to that issue alone, or also due to the FTDI chip signal inversions.
Can you try recompiling everything (or at least just payload) as 32 bit (use the gcc -m32 switch) and then re-test?
Thanks,
Ross.
I had to install the 32 bit compiler packages to use -m32; they aren't native on ubuntu gcc;
In any event, the non -m32 sends the same data stream to the sendLong function as -m32 one -- I might have messed it up, but I seldom botch a patch this bad: I'll email you that code and why don't you tell me if my version of payload still works on your 32bit machine for whatever propeller you use -- if it does, at least one porting issue won't be bothering people needlessly any more.
When I load it now, instead of getting a segfault or "no response" I get an actual response:
So, at least that is progress, even if negative.
The serial port .spin code test I listed earlier is pure BST compatible code; BST was already a compiled exeutable 32bit when I downloaded; The upload using payload of that binary fails the same as hello_world from Catalina, so I don't think this is a Catalina issue -- but I'll see if I can figure out how to recompile all of Catalina with the -m32 switch just to compare. Your results with my version of payload may be more helpful time-wise. Also, if you have a guaranteed correct .binary of some program, say the led blink one -- I'd like to try uploading it into the propeller using payload and see if it works if you wouldn't mind emailing/posting it to me.
((( EDIT: I added the CFLAGS= -m32 to the Makefile
the spaces were important for some reason, but then I did a make clean, make all, make install ...
and I can see the -m32 attached to every gcc line, so I assume it worked. After verifying that it did install, I re-ran the tests. Everything fails exactly the same. payload returns the same error message.
I loaded hello_world.binary using bstl, checked the errorcode variable
echo $?
0
And zero is success; so then I tried the -m32 re-compiled blackbox -- but no progress:
So I'm stumped without more help of some kind.
)))
Thanks,
--Andrew
Hi Andrew,
Not so easy, as I don't have a GG board - maybe someone who has one could provide a known working binary? Any binary would do for this test - SPIN, C, PropBasic, Forth, Java or anything else!
Ross.
When did .html start getting appended to files????
Thanks jazzed!
Ross.
Exactly what I have; Just a 5Mhz crystal in a Gadget Gangster board. Thank you! At least I now have a binary to test and retest with and don't have to worry I mis-assembled the binary by a faulty assembler on my system... A VERY handy thing to have.
I am not sure what you mean by .html being attached, did I mis-link something?
I have been using quick reply which doesn't have the "code" tags that I have just found in the "go advanced" post button... if that's what you mean.
I fired up the BST serial terminal which will connect to the serial port at 9600N8,1 default;
Am I correct in assuming that your binary will print to the serial terminal?
I watched it for a while at 9600N8,1 -- but nothing came through. The same is true with respect to 115200 baud. (It will let me choose several). I am too tired to wire my scope up to watch the reset line, but either the bstl doesn't check for a valid download -- or the board is being reset. Nothing comes through on the serial line -- not even break signals, or error signals, but prior to starting the serial terminal, my use of bstl to load the binary returns true (echo $?) as if it did load correctly.
ROSS!
Doooh! I didn't think you had a gadget gangster, I just thought that since you write code that you would have some kind of propeller board, and that you would use "payload" to activate it. If this is the case, then you could check my modifications in a crude go/no go sort of way to see that they don't break the program for normal people with 32bit CPU's and some other propeller board.
That lets me know that my modifications are not an extra problem, rather than a fix.
Otherwise, I need to re-unpack the tar file for payload, (the original), and recompile it with -m32, etc. and I am tired enough that I would do something silly like overwrite the files I have modified over the last two days....
Hi Andrew,
Yes of course I use payload all the time on all my various Prop platforms - I just meant that I couldn't provide you a binary that I could guarantee would work on the GG board since I don't actually have one.
But the one jazzed provided should do the job quite nicely. Did you try it at 57600 as he suggested? Let me know when you have this binary working successfully on your hardware (hopefully this will eliminate the possibility of hardware issues) and in the meantime I'll try out your payload changes on my systems.
I have done some testing, and I can confirm that payload does not work under Ubuntu 10.10, even if I run the 32 bit Intel version of that OS. However, the same executable works under both fedora 12 and debian 5.0 (which are my usual Linux test platforms).
I'm not yet sure what the problem is - presumably some difference in the kernel or the serial device drivers.
However, now that I can reproduce it, I should be able to fix it. I'll let you know how I get on.
Ross.
Sheesh. I seem to be on a machine designed to break everything, every possible way.
Another reason to hate Ubuntu... (it's not my machine, either....but it has cost me over two weeks in lost work already....)
I went to sleep, and now I am able to make sense again.... thank you for your patience.
Jazzed's binary does not produce a result on the BST, View/Serial Terminal, at any speed.
Ross, if you find a hint of what's wrong -- let me know, and I'll work on it too. My kernel hacking skills are quite good; all I need is a hint.
any Idea how i can check if the position is already in use..?
i'm trying to make something like collision-check up..
my english is very bad right now.. i need a sleep sry
i hope you understand what i'm trying to do
Hi Andrew,
I won't get a chance to look at it tonight - but I hope to get a chance to do so tomorrow.
Ross.
Sorry, I'm not sure what "position" you mean. Are you talking about whether a screen position is in use? If so, you can just look directly at the appropriate memory locations in the screen bitmap. Figuring out the correct memory location is a bit of a chore, but if you don't have the Hydra book (which goes into this in great detail) then I seem to recall that somewhere there is an annotated program that explains this in detail - I did a quick search but couldn't find a link. If anyone can help out here I'd appreciate it.
Ross.
If i have for example:
i put a rect. on the screen.
now i put a nother rect on the screen and let it move arround changing the coordinates.
If the second rect hits the first one i want it to stop.
So the question is .. is there an easy way? or do i need to work with the coordinates and lenghts itself..?
If it worked for you, then I am sure the image itself isn't the problem. I think whatever is wrong has to do with my particular setup; and your image will be very helpful in proving that out soon.
One question: which platform did you test your image on? eg: Linux / Windows / using BST, BSTL or payload?
That will help me isolate which variables are causing me trouble.
The following is a list of what I think the possibilities are:
1) a hardware mismatch between the RS232/FTDI driver and the download software (inverting V. non-inverting)
... If you loaded on a GG, this is impossible, and an eliminated problem
2) a glitch in ubuntu 10.10 software (Guaranteed since ROSS can't get it to work under Ubuntu either -- but not necessarily the only prob)
3) an undocumented issue with the serial driver: eg: under linux, if one "closes" the /dev/ttyUSB0 driver -- does it reset the DTR/DSR lines causing the GG to reset the moment the driver is opened or closed? (effectively erasing the downloaded program by reset.)
... again, if you downloaded to the GG using linux -- then either I have to be using a different kernel driver for the serial or back to #2
4) ~~ a possible complication, but just an extension of problem#1: The BST serial terminal might have a bug/not be printing diagnostic bytes (hex mode) when bad data is received.
Thanks again for the binary.
& If you/anyone has a test of it under Linux and/OR (either way) with a GG I would appreciate knowing which combinations worked.
--Andrew