Here's your chance to get a SUMP PUMP for free, maybe even a preview unit. We need command line utilities to update the SUMP PUMP FPGA image from Windows, Mac, and Linux. We're currently using a Perl script (http://http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/SUMP%20PUMP%20logic%20analyzer/scripts/pump-loader.pl), but this is too much hassle for end users.
The update is done over a virtual serial port using a simple protocol (http://http://whereisian.com/forum/index.php?topic=270.msg2346#msg2346). Ideally, the utility would load Intel HEX files (http://http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/SUMP%20PUMP%20logic%20analyzer/scripts/Pump.mcs) directly, but we have raw binary blobs (http://http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/SUMP%20PUMP%20logic%20analyzer/scripts/pump.bin) too. The utility must compile on all major platforms (Windows, MacOSX, and Linux). Piotr's (http://http://piopawlu.net/) Pirate-Loader (http://http://dangerousprototypes.com/2010/01/22/how-to-firmware-upgrades-with-the-linux-mac-windows-console/) utility source code (http://http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/bootloader-v4/pirate-loader) should have everything you need to get started.
The winning entry should:
*Run as a native console application (not scripted, no .Net/Mono)
*Compile on Windows, Linux, Mac, and include these compiles
*Be released under an open source license, preferably CC-BY-SA or GPL
*Work in our tests
C code is preferred by not required. We'll leave this open until a satisfactory solution is submitted. In the case of multiple entries, we'll choose one based on compliance with the criteria and possibly a vote.
Original post here (http://http://dangerousprototypes.com/2010/02/03/write-some-an-app-get-a-sump-pump/).
I have written something ... But I don't know how to test the serial communication part. :)
It compiles on windows, and linux, (i don't have mac around here)
Has all the features perl script has, (except for the page number limit), reads writes hex and bin files.
Most of the OS dependent parts are from pirate-loader, so it should work even on windows :)
Here is my work. I have only tested the bin/hex file parser/writers.
There are binaries for Win32 and linux, sourcecode, Makefiles for linux and Dev-C++. The serial part is copied from pirateloader, so it should work.
Can you test it ?
Thanks robots, fantastic work in a short amount of time -- I tested it and had lots of success, but a few errors:
C:Perleg>pump-loader
PUMP loader
pump-loader
parameters:
-p PORT - port of PUMP, needs to be specified
-rH FILE - HEX file to be uploaded to PUMP
-rB FILE - BIN file to be uploaded to PUMP
-wH FILE - HEX file to be downloaded from PUMP
-wB FILE - BIN file to be downloaded from PUMP
-l 0 - send only bytes from file (0-padded) - write only
-l X - send only first X paged
commands:
-erase - erases Flash
-write - writes data to Flash
-read - reads data from Flash
-run - enter run mode after finished
-status - get PUMP stauts
-boot - enter bootloader mode - ignore other commands
When no command specified, program will check FW version, and Flash ID
C:Perleg>
Help menu
C:Perleg>pump-loader -p:COM5
PUMP loader
Opening serial port COM5...OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Found flash: ATMEL AT45DB041D
C:Perleg>
Read PUMP/ROM version strings
C:Perleg>pump-loader -p:COM5 -erase
PUMP loader
Opening serial port COM5...OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Found flash: ATMEL AT45DB041D
Chip erase ... done :)
C:Perleg>
Erase the chip (verified).
C:Perleg>pump-loader -p:COM5 -boot
PUMP loader
Opening serial port COM5...OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Found flash: ATMEL AT45DB041D
PUMP switched to bootloader mode
C:Perleg>
Jump to bootloader works.
---------------------
C:Perleg>pump-loader -p:COM5 -rH:pump.mcs -write
PUMP loader
Opening serial port COM5...OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Found flash: ATMEL AT45DB041D
no input file specified !
C:Perleg>pump-loader -p:COM5 -rB:pump.bin -write
PUMP loader
Opening serial port COM5...OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Found flash: ATMEL AT45DB041D
no input file specified !
C:Perleg>
I think the -wH/B and -rH/B are mislabeled? I get no input file specified when I use -w with -read and -r with -write.
If I do it the other way, I get system errors:
pump-loader -p:COM5 -wB:dump.bin -write
opens the port, gets the FW version string and the ROM version, but then windows pops up an error that pump-loader encountered a problem and needs to be closed.
C:Perleg>pump-loader -p:COM5 -rB:dump.bin -read
PUMP loader
Opening serial port COM5...OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Found flash: ATMEL AT45DB041D
Page 0x0000 read ... OK
Page 0x0001 read ... OK
Page 0x0002 read ... OK
Page 0x0003 read ... OK
Page 0x0004 read ... OK
Page 0x0005 read ... OK
Reading partially works (with the operands switched). It starts out OK, but then it speeds up (bad reads?) and eventually crashes. On another try it read to page 0x800 and crashed. In both cases it never created the output file (dump.bin).
Great work, it looks really close to done. If you have any ideas for bug fixes, I'm happy to test again, though you may need actual hardware to finish the job :)
I have one more minor request: since this is a virtual serial port the speed doesn't really matter. I increased the perl script baud rate to 921600 and got a nice speed increase. Could you please do the same with your program?
I messed up the help:
-r[HB] goes with -read command
-w[HB] goes with -write command
The idea of reading is to: read the whole memory (or specified number of pages) into buffer and then write the buffer to hex or bin file (or both).
Write is done backards. Read hex/bin file (just one) and write the memory.
But when the reading fails, it should at least create file, with zeroes. Unless it fails on buffer overflow :)
Real quick and darn close shot by robots :)
pump-loader.exe works on
- default (no other parameter than port given - pump-loader -p:COMx)
- erase SPI flash (pump-loader -p:COMx -erase)
- switch to bootloader mode (pump-loader -p:COMx -boot)
(http://http://i49.tinypic.com/14o9jqh.png)
- read SPI flash and write image to HEX file (pump-loader -p:COMx -rH: -read)
(http://http://i48.tinypic.com/2yv6ref.png) (http://http://i45.tinypic.com/29yobxv.png)
However, it always fails when writing a HEX file to SPI flash (pump-loader -p:COMx -wH: -write), causing a problem and Windows terminating pump-loader.exe with an error screen:
(http://http://i50.tinypic.com/mwxf6w.png)
Maybe I misunderstood how to use the parameters for the write SPI flash operation properly ... sorry for the German text ... the system I am testing on runs a German Windows XP ...
Could you test this one ?
http://robot.mysteria.cz/pump-loader.exe (http://robot.mysteria.cz/pump-loader.exe)
Should work better, with parameters parsing corrected and lot's of copy-paste problems corrected. :)
For the ':' you can also use '=' or any other non white-space character.
Fantastic work! It works great for me. I did these tests:
Wrote a HEX to the ROM with the console app
Dumped the ROM to a .bin with the .pl script and compared to a known-good dump, they were identical.
Dumped the ROM to a .bin with the console app, another compare was identical.
Programmed a BIN with the console app, dumped and diff'd - identical.
I really like loading the .hex directly, instead of using the 'stupid' HEX2BIN converter I made (stupid because it doesn't really parse intel HEX, it just grabs values from the file).
Could you please look at this bug report on the pirate loader source and see if it applies here?
http://whereisian.com/forum/index.php?t ... 12#msg2412 (http://whereisian.com/forum/index.php?topic=250.msg2412#msg2412)
Could you please set 921600 as the default baud rate and add a configuration option?
Finally, is it feasible to limit writes to the data pages present in the HEX or BIN? Only the first 640 pages of data are used for the FPGA, but the writes continue through all 2048 pages.
Thank you so much for taking on this project. Great work.
C:Perleg>pump-loader -p:COM5 -read -rB:dump4.bin -l:10
PUMP loader
Opening serial port 'COM5'... OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Found flash: ATMEL AT45DB041D
Will read 10 pages
Page 0x0000 read ... OK
Page 0x0001 read ... OK
Page 0x0002 read ... OK
Page 0x0003 read ... OK
Page 0x0004 read ... OK
Page 0x0005 read ... OK
Page 0x0006 read ... OK
C:Perleg>pump-loader -p:COM5 -write -wB:pump.bin -l:680
PUMP loader
Opening serial port 'COM5'... OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Found flash: ATMEL AT45DB041D
Reading BIN file 'pump.bin' ... OK! (binary size = 169216)
Will write 680 pages
Page 0x0000 write ... OK
Page 0x0001 write ... OK
Page 0x0002 write ... OK
Page 0x0003 write ... OK
Page 0x0004 write ... OK
Page 0x0005 write ... OK
Page 0x0006 write ... OK
Finally, is it feasible to limit writes to the data pages present in the HEX or BIN? Only the first 640 pages of data are used for the FPGA, but the writes continue through all 2048 pages.
Doesn't option -l:0 do the job ? :)
I can change the app to do this by default.
Another problem is the speed:
How long does it take to write those 641 pages ? The pirate-loaders serial function polls the serial port every 250 ms, i could change it to 10. This should increase the speed a lot.
New version available, with speedup and "write only what read":
http://robot.mysteria.cz/pump-loader.exe (http://robot.mysteria.cz/pump-loader.exe)
The last version seems not to communicate with the PIC at all ... so it prompts "Opening serial port 'COMx' ... OK" it will do so for any COM port (COM2, COM3, ... COM20 regardless if the COM port exists or not) and then exit ...
It does parse only the pages present in the bin successfully.
I have the same results with reads and writes. Very fast, but it's not actually using the port. I had to register the higher port speed in the perl script, maybe it's not going to be possible without a hassle in the C version.
The Perl script just pauses for 0.02 seconds and then the response byte is there :) I'd guess you're safe with 10ms polling.
I had the debug option on :) I'm sorry, new version is up.
It does parse only the pages present in the bin successfully.
I have tried both hex and bin, and i get 641 pages on both.
Perfect. Passed a full test and looks very professional.
The speed improvement is massive. Writes are good and reads fly by.
Is there a speed config switch so I can test even higher speeds?
Could you please add a usage example to the help menu.
This looks in order, I think you've got it wrapped up. When you're ready, would you please upload the source archive. I'll PM you about the PUMP.
No problem at all (debug option on) ... great job! :)
I did repeated write, read, erase cycles and tested different configuration images. All compares matched.
Switching to run and bootloader mode tested ok.
command -status seems not to be implemented ...
New version:
-t parameter, sets arbitrary baudrate
-status should work
I will clean up the code, and upload it with executables.
Here is the source code, + executables for linux, win32.
I used Dev-C++ to compile for windows (which is essentially mingw-gcc), both project file and make file is provided. I have also included makefile for linux.
Thank you! :)
I recompiled the source with Dev-C++ 5.0 beta 9.2 (4.9.9.2) (9.0 MB) with Mingw/GCC 3.4.2.
-t parameter tested ok
-status failed because
} else if ( !strcmp(argv[i], "-status") ) {
write = 1;
} else if ( !strcmp(argv[i], "-write") ) {
cmd_write = 1;should be
} else if ( !strcmp(argv[i], "-status") ) {
cmd_status = 1;
} else if ( !strcmp(argv[i], "-write") ) {
cmd_write = 1;fixed package attached ... will give it more testing and compile it for Mac OS X later ...
(http://http://i47.tinypic.com/1449xxg.png)
I will send you a patch to make the high speed serial compile and work on a Mac as you can't use cfsetispeed/cfsetospeed to set baudrate over 230400 on a Mac. Also, would you like a compiled universal binary?
pppd, thnx for the offer! Universal binary would be good unless there are issues with high speed serial on PPC because there may still be a few potential users with PPC machines around.
I don't have much experience in programming and compiling on Mac OS X and not much time atm either.
It will help the project to keep it's momentum if you could patch and compile the code for Mac OS X.
Once it compiles and runs under Windows, Linux and Mac OS X I could maintain the package as I have development platforms for all three systems and a SUMP PUMP prototype.
I have modified the makefile to detect operating system with $(shell uname) and add required flags for Mac OS X universal build. The high speed compatibility mode has been added, it should work on PPC Macs too.
Please review the changes before applying the patch. The zip archive also contains compiled universal binary.
I think putting the code into svn would be better :)
[quote author="robots"]
I think putting the code into svn would be better :)
[/quote] True, and generating patches would be easier as well.
Very true! Thank you for your super fast response, robots & pppd! :)
So it appears that I have SVN write/commit access, I'd prefer Ian to commit the code to SVN ... and then to go from there ...
I am off to the books and the web to find out how to generate patches ... ;)
Thanks guys! I'll put it in the gadgetfactory SVN. Is there a latest version I should use?
[quote author="ian"]
Thanks guys! I'll put it in the gadgetfactory SVN. Is there a latest version I should use?
[/quote] I think you should download the last archive modified by IPenguin, and patch it with my Mac patch. I can patch it for you plus build a new mac binary as it was posted before IPenguin fixed that one issue.
IPPenguin should have write access to the Gadget Factory SVN and we can give access to anyone who wants to contribute code as well. Anyone who wants to check code into SVN just needs to create an account and I will give them write access to svn.
Jack.
I added the code linked here:
http://whereisian.com/forum/index.php?a ... attach=318 (http://whereisian.com/forum/index.php?action=dlattach;topic=297.0;attach=318)
to the SVN here:
http://www.gadgetfactory.net/gf/project ... -loader%2F (http://www.gadgetfactory.net/gf/project/butterflylogic/scmsvn/?action=browse&path=%2Ftrunk%2Fpump-loader%2F)
I've attached a patch for the latest revision fixing the Mac OS X incompatibility. I think you don't really need binaries other than Windows executable at this point as all people working on it use Windows, right? I don't think I need SVN access for this project as I am not really contributing anything that can't be posted here.
Thanks. Applied and committed.
Just a tiny correction for the serial.c, I have called tcsetattr twice in the #ifdef MACOSX block. It's not a problem, but could be removed to keep to code clean.
Thanks. I applied the patch and committed it to the SVN.
pppd, thnaks. I have gave your first Mac OS X version a try but it gave an error and terminated ... probably because of the MAc OS X incompatibility you mentioned and fixed in the meantime.
At least I will test the code on a Mac to make sure it works as we have the intention to make the SUMP PUMP available to Windows, Linux and Mac users.
I just verified that the console update application works great for me as well.
Jack.