Yet another command line loader / unloader - 0.07-pre1
BradC
Posts: 2,601
Ok, this is the first tentative baby steps at testing some of my cross-platform stuff.
This is nothing special, just another command-line propeller serial loader.
Windows version defaults to COM2 (as I've not looked at more complex detection yet).
MacOS and Linux versions will try a semi-intelligent search for any usb-serial devices and tries to use the first one it finds.
If you show help with -h, it will tell you the device it has defaulted to after its search.
You can specify the device you want to use with -d
So ..
bstl.osx -d /dev/tty.usbserial-xxyyzz demo.binary
bstl.linux -d /dev/ttyUSB1 demo.binary
bstl.exe -d COM3 Demo.binary
Running the program with no parameters will simply try and detect a Propeller chip.
You can use -p1 -p2 or -p3 to load Ram or EEProm (use -h for details).
-f makes it load the prop at double the baud rate.
-u makes it read the Propellers EEPROM and write it out if you've given it a filename. (bstl -u -f fred - would write fred.eeprom / bstl -u -f - will just upload and CRC check)
The MacOS binary is big unfortunately as it's a Universal binary for PPC and Intel.
All files are packed with UPX (if you are interested).
The Linux version has been tested on Ubuntu 8.04 dual and single processor i386 machines. It *should* also work flawlessly on x86_64 as it is a static binary with no lib dependencies.
The MacOS version has been tested on PPC and Intel, both OSX 10.4 and 10.5. I'd be _very_ interested in feedback from MacOS users.
(It has been tested with the standard propeller FTDI stuff, and also a PL2303)
The Windows version has been tested on 98SE and XP on the hardware, and also in a VM on linux. The Windows version has been compiled with the most basic Win32 dependencies only, and in all reality _should_ run on Windows 3.11 with the WIN32 layer installed. It should most certainly run on anything Win95 and up. (If it doesn't, I'd like to know about it please!)
There are no library, runtime or VM dependencies on any of these binaries. They should just work on the most basic install of an OS.
Version 0.02 - Improved propeller detection
0.03 - Fixed the download I broke rushing 0.02 out the door.
0.04 - Properly set return codes / much faster download / detection / double baud rate option
0.05 - Reset timing closer to Propeller Tool
0.06 - Stuff (never really released officially)
0.07 - Unloader (read eeprom back to file) support.
www.fnarfbargle.com/bst/bstl/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Post Edited (BradC) : 4/28/2010 5:25:34 AM GMT
This is nothing special, just another command-line propeller serial loader.
Windows version defaults to COM2 (as I've not looked at more complex detection yet).
MacOS and Linux versions will try a semi-intelligent search for any usb-serial devices and tries to use the first one it finds.
If you show help with -h, it will tell you the device it has defaulted to after its search.
You can specify the device you want to use with -d
So ..
bstl.osx -d /dev/tty.usbserial-xxyyzz demo.binary
bstl.linux -d /dev/ttyUSB1 demo.binary
bstl.exe -d COM3 Demo.binary
Running the program with no parameters will simply try and detect a Propeller chip.
You can use -p1 -p2 or -p3 to load Ram or EEProm (use -h for details).
-f makes it load the prop at double the baud rate.
-u makes it read the Propellers EEPROM and write it out if you've given it a filename. (bstl -u -f fred - would write fred.eeprom / bstl -u -f - will just upload and CRC check)
The MacOS binary is big unfortunately as it's a Universal binary for PPC and Intel.
All files are packed with UPX (if you are interested).
The Linux version has been tested on Ubuntu 8.04 dual and single processor i386 machines. It *should* also work flawlessly on x86_64 as it is a static binary with no lib dependencies.
The MacOS version has been tested on PPC and Intel, both OSX 10.4 and 10.5. I'd be _very_ interested in feedback from MacOS users.
(It has been tested with the standard propeller FTDI stuff, and also a PL2303)
The Windows version has been tested on 98SE and XP on the hardware, and also in a VM on linux. The Windows version has been compiled with the most basic Win32 dependencies only, and in all reality _should_ run on Windows 3.11 with the WIN32 layer installed. It should most certainly run on anything Win95 and up. (If it doesn't, I'd like to know about it please!)
There are no library, runtime or VM dependencies on any of these binaries. They should just work on the most basic install of an OS.
Version 0.02 - Improved propeller detection
0.03 - Fixed the download I broke rushing 0.02 out the door.
0.04 - Properly set return codes / much faster download / detection / double baud rate option
0.05 - Reset timing closer to Propeller Tool
0.06 - Stuff (never really released officially)
0.07 - Unloader (read eeprom back to file) support.
www.fnarfbargle.com/bst/bstl/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Post Edited (BradC) : 4/28/2010 5:25:34 AM GMT
Comments
Thanks for sharing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offence at my writing style
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Post Edited (BradC) : 10/21/2008 8:51:28 AM GMT
I'm interested in using bstl in a project since it doesn't cause some annoying GUI element to pop up.
I have some issues though:
1. I can use bstl from windows command console in WindozeXP except for not finding propeller about 1/3 of the time.
Syntax used: bstl -d com3 -p1 <filename>.binary.· If I don't specify -p1 it's better. Any suggestion on this?
2. If I try collecting the output from stdout/stderr using C#.net when it does load, I never see anything.
Other programs work fine. Propeller is not found in this environment more than half the time.
3. It seems the return code is always non-zero regardless of whether anything was downloaded.
Could you make bstl return 0 if the operation specified by the command line succeeded?
The bstl binary is·from your directory 003 .zip with .exe timestamp 10/21/2008 12:45PM.
Thanks for your efforts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Post Edited (jazzed) : 1/19/2009 6:57:20 PM GMT
In any case, I have made significant changes to the loader code since the last release of bstl, so it's probably better now. I'll see what I can do, but I'm pretty hectic until the second week in Feb so I can't make any promises.
I'll certainly make the changes you suggested anyway.
<edit>
Forgot to ask, what specs are your machine? Processor speed that is? There are some timing dependent things in there and sometimes slower CPU's don't get the delay accuracy just right on windows and I might need to change the way I calculate my delays (Windows has a standard timer resolution of ~10-15ms while OSX and Linux are < 1ms)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Post Edited (BradC) : 1/19/2009 10:28:28 PM GMT
I couldn't get your bst loader to work on my computer, so I used Praxis loader independently.
I've seen Praxis loader and with source it might be more useful.
I'm trying to focus on something else though
I wouldn't know where to begin on the stdout/stderr issues ... always just worked for me in C.
Thanks for considering return code 0 on program success.
Workstaition Details:
WindowsXP Professional 2002 SP3. Intel Pentium 4, 3.4GHz, 2GB RAM. Developing with VSC#2008.
Is Cardinal Fang! a pet?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
Yeah, its odd. I did a quick check this morning and it always returns 0 on linux. I need to get to a Windows machine to try and figure out what is going on and get it fixed.
I've fixed several nasty compiler bugs recently so I need to work out a new release when I get settled..
That's not a *slow* rig by any means, so I should not be seeing timing issues there. I might fire up a VM with SP3 and see if it behaves differently to my SP2 VM I tested with..
..and nary a Monty Python fan to be seen.. Oh well..
@Cluso99
I've just found a Dual core laptop with 4G of ram and Vista Ultimate (What a stupid name for an operating system, it sounds like cheap third world petrol!) on it so I can get some testing done with that. Will keep you posted..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
I've significantly re-written the loader code this time around.
This revision sees all outgoing bitstreams "dense packed" as conceived by Hippy. Both the LFSR and bytecode are sent using the same packing. In the LFSR where we were sending 250 Bytes (One bit per byte), we now send 77 for the same number of bits (Would be 86 using the static 11 bytes per long encoding). With the bytecode I'm seeing an average (tested across ~1500 .binary files) of a 20% saving in sent bytes and therefore download time.
The windows build tends to be quite sensitive to system load on low powered machines as windows seems to have trouble keeping its timer resolution in check.
The loader has also been re-worked to properly set error codes as requested by jazzed (I tested it on Win32 using Cygwin, I'm not familiar enough with Windows to know how to do it the native "windows way").
0 - all good
1 - error loading prop
2 - Can't load specified binary file
3 - Binary checksum is invalid
100 - error detecting prop
There is also now an option (-f) to load the prop at 230400 baud instead of 115200. This shaves anywhere between 25-50% off the total test load time and is quite noticably faster (this is on top of the ~20% gain we already have from "dense packing"). Whoooohooo - TurboProp!
This is pretty experimental, so if you experience problems loading the propeller, try dropping the load speed first! I had trouble with the internal oscillator speed of the propeller dropping when it was warmed up (exceeding 35 Degrees C ambient) so after analysing the booter code I've inserted an extra bit-time space at the end of each long to give the Propeller time to write the long to the hub and return (But only when the baud rate exceeds 200k). This *appears* to have solved all my high-speed reliability issues, but as always your tests may not quite match mine [noparse]:)[/noparse] (I'm pretty sure my hair dryer warmed the prop up enough, without the extra bit I get about a 40% failure rate, but with the extra bit that drops to ~0).
The loader (and only bstl) has a new "undocumented" option (-t).
Basically it takes the name of a text file rather than a binary to load. This file must contain a list of binary files with either absolute or relative paths (relative to the directory that bstl is run from). It will iterate this file and load each binary in sequence, keeping track of the errors it encounters. There is no error checking done on any of this process, the program reports no return error codes, and it's effectively unsupported (I use it for internal regression testing and speed tests).
The test board is a bare USB proto-board with the +5v from the USB socket wired directly to the +5v rail so I can just plug in the USB and perform a test run without worrying about the software I'm loading hitting any pins that should not be hit. The regression suite consists of 1589 binaries, so I get lots of variety. In high speed mode I'm loading the 1589 files in a smidgen over 19 minutes. The full regression test runs that load 20 times with varying OS background loads and takes roughly 6 hours per OS (Windows is a _lot_ slower as its filesystem access over the network is like treacle compared to OSX or Linux). I'm still seeing between 0.5 and 0.01% load/detect errors depending on OS and background workload.
This propeller loader library is shared by bstc and bst, so they get the benefit of this new code also.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Made the Propeller reset timing as close to that of the Propeller tool as possible
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!
I found that highlighting can be changed on OS X to a purple color. This allows highlighting in BST to be viewed in all code blocks. With the default blue, it sometimes blends in, making search results hard to see. System Preferences / Appearance / Highlight Color is where you can set this. I am using 10.5.8, Leopard on a MacBook.
I notice that it is necessary to double click twice to launch a file from Finder. The first double click does launch BST, but the file is not opened. A second double click in Finder makes the file open.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eric
Post Edited (EricR) : 8/29/2009 12:57:00 PM GMT
From 0.18 you can set the highlight colour in the IDE preferences. I did this specifically for OSX users using the blue theme so you could choose your own highlight colour.
The file association thing in OSX is still something I'm getting a handle on. One some machines it works perfectly, on some it works like yours does and on some it does not work at all. With 10.6 out now there is another variable in the mix.. It's something I'm looking into but it's not high up the list I'm afraid.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
I'm having a heck of a time figuring out which version of bst is running. If I double click Applications/bst/bst.app, the about shows 18.4. But then, if I double click some files, it shows 18 pre 3. I tried 'info/open with/change all' to this path, but it sometimes (often) still comes up 18 pre 3. I even re-named the file that I think is 18 pre 3. I think that OS X is doing something nice (but annoying at the moment) by maintaining a link to the old bst.app even if I move and rename it.
I can see the "Override OS Highlight Colour" checkbox when I actually get 18.4 to run, it works great.
The version confusion of OS X also impacts the issue of double clicking. If I have 18.4 running, double clicking a spin file now flashes the bst logo, but does not ever appear in the running 18.4. Strange. I realize this is just probably an issue of my understanding of OS X, so please don't worry about it too much.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eric
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eric
I ventured "and an almost fanatical devotion to the Prop" a wile back ( or is that just so old hat ?)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I've toyed with a number of quotes from python via the goons and even Spike Milligan directly, but it just passes straight by. The humour gap is far wider than the void that separates those countries in the northern hemisphere I'm afraid.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Use -u (with -f to make it go quicker) and it will connect to the prop and suck the contents out. If you put a filename on the command line it will write the contents to the file.
./bstl -u -f gronk
Will read the first propeller it connects to and write gronk.eeprom in the current directory. It will overwrite any existing file with no warning.
I get about 27 seconds here with just -u and about 13 seconds with the optional -f.
The upload is CRC checked at both ends (I've not seen a failure yet, but I'm sure it might happen).
www.fnarfbargle.com/bst/snapshots
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
It won't download directly in this form as the extra stuff in the EEPROM invalidates the checksum.
I wonder if I tried to load something on it at one point that put that stuff in the eeprom directly.
<edit> I checked out propirc. Funny. If you don't have valid settings, even if you've loaded it only into ram it proceeds to set default settings directly into your EEPROM. Nice.
if ((myServerIP + myServerPort + myUser + myPass + myNick + myChannel) <> settingsHash) or (myServerIP == 0) ' hash check failed, init default settings myServerIP := constant((140 << 24) + (211 << 16) + (166 << 8) + 3) myServerPort := 6667 setSettingStr(@myUser, string("username")) setSettingStr(@myPass, string("password")) setSettingStr(@myNick, string("proptcp")) setSettingStr(@myChannel, string("#propeller")) myTimeOffset := constant(60 * 60 * -5) ' CDT (GMT - 5 hours) commitSettings vga.invstr(string("Notice: Default settings were loaded and saved.",13))▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Post Edited (BradC) : 4/28/2010 7:12:15 AM GMT