rigel: yet another program loader!

[Shinigami2057]

Well, you're probably all going to roll your eyes at yet another program loader for the FRC, but I hope mine stands out a bit, so please give it a chance

Over the last two months, I've been writing and extensively testing my program loader, which is called rigel. Actually, I'm quite sick of the name (which was temporary in the first place), so if any of you have a better one, I'd be happy to rename it.

The loader and corresponding library is free software, licensed under the GPL. It (hopefully) is worth your time because:

• It is complete. The entire AN851 specification is implemented, including IFI's non-standard additions to it. The INHEX32 implementation includes support for extended linear addresses, allowing for use of the full addressing space of the 2006/2007 FRC.
• It is portable. Rigel runs on any POSIX-compliant platform and Windows.
• It is extensible. If next year they upgrade the PIC18, it is trivial to update the configuration file to reflect the new memory sizes.
• It is robust. Rigel can upgrade the master firmware, read the normal program memory and the boot sector, read EEPROM data to file, capture output from the device, and read/write to HEX, BIN, and raw binary data, in addition to just loading the program.
• It is well-encapsulated (much like pycloader) and has a simple API that can be statically linked against for your own programs and utilities. Some example utilities can be found in the utils/ dir of the source.

At the moment, it is currently command-line only (although very simple to use). I have delegated the task of writing an ncurses front-end to one of our programmers, and I am writing a wxWidgets GUI for it to make life easier for those who don't like the command line.

The only issue is that it probably doesn't yet work on big-endian architectures, but that should be very easy to fix. Just compile it with make and it should be fine on any platform with gcc (mingw32 works fine for windows). I'll build a Windows executable tomorrow and upload it; for now, here is the source and the readme:

http://lights2dx.net/source/other/rigel-0.12.tar.bz2
http://lights2dx.net/source/other/rigel/README

My team has been using it with no issues on slackware/i486 and I've tested it on Fedora 6/x86_64, but if you find any problems with it (or if you hate it), please post them here.

[EHaskins]

Would you be willing to help integrate this into FusionEdit (www.sourceforge.net/projects/fusionedit)?

Edit: Have you tested it for VEX, EDU, 2005 RC?

[Shinigami2057]

Originally Posted by EHaskins

Would you be willing to help integrate this into FusionEdit (www.sourceforge.net/projects/fusionedit)?

Edit: Have you tested it for VEX, EDU, 2005 RC?

I have tested it on the 2005 RC, but I don't have access to a VEX or EDU. What model PIC18 do they use?

And I'd be happy to help integrate it. How easy is it to integrate C and C#?

[EHaskins]

Vex and Edu are both 18f8720.

I believe the easiest way to integrate your code may be to create a windows command line app then run it from the C# app. It should be possible to use a C DLL in C#, but I haven't had to do that before.

[Shinigami2057]

It would be easier indeed to just use a system()/execve() call to run my program directly, but you might want to integrate it more cleanly into your program. Do you intend to make your program multiplatform (i.e. with Mono)? In either case I don't mind helping you build shared objects/DLLs to integrate it. It should be fairly simple in any case

Just give me a PM with all the details.

[Astronouth7303]

The 2004-2005 RC, Vex, and EDUbot all use the PIC18F8520.

I would be interested in this as well. I haven't even gotten to loading master code, yet. (Although I suspect it's pretty easy.)

[ace123]

This may be a little bit unrelated, but do you know the format of the serial console that the "printf" statements go to?

Is it as simple as "cat /dev/ttyS0"? (though I'm wondering what happens to all the bytes when the robot serial interface is not outputting anything... are they just null characters?)

Also, how does this compare to the JIFI program in here: http://chiefdelphi.com/forums/showthread.php?t=52546 (though afaik JIFI doesn't seem to be open source)

Anyway, It would be nice to have a GUInterface... I might write a GTK one if I have some free time... (actually I might try using wxWidgets...I heard it's good)

[Eldarion]

This could be interesting!

I have been trying for some time to get the IFI loader to download code to my Vex controller through my homemade programming cable. Since I know exactly where the programming sequence is getting "hung up", maybe I could modify your loader to support a homemade programming cable?

(This would have to be dome some time after build season--I'm kind of busy right now. Something about a robot... )

[Ryan M.]

Thanks a ton for this! I was just looking for a command line loader I could integrate with a project I'm working on, so this works out nicely. (I know about the other ones out there, but they were either possibly out of date or difficult to make work with my needs.)

[Shinigami2057]

Originally Posted by Astronouth7303

The 2004-2005 RC, Vex, and EDUbot all use the PIC18F8520.

I would be interested in this as well. I haven't even gotten to loading master code, yet. (Although I suspect it's pretty easy.)

It's very easy, actually. In the utils/ dir of the tarball is a program "an851d", which is just a program that pretends to be the FRC controller. I used it to see how IFI_Loader would try to load the master firmware without actually having to do it on our bot. All the .BIN file is is a text file that holds a program in a slightly different format from INHEX32 (see ifi_bin_read in src/inhex32.c), which, when loaded and run, will flash the master processor FROM the user processor (as far as I can tell). The only thing my program does when flashing the master is force IFI's "BIN" format and write verification (it would be bad for a flashing error to occur ).

Originally Posted by ace123

Is it as simple as "cat /dev/ttyS0"? (though I'm wondering what happens to all the bytes when the robot serial interface is not outputting anything... are they just null characters?)

Also, how does this compare to the JIFI program in here: http://chiefdelphi.com/forums/showthread.php?t=52546 (though afaik JIFI doesn't seem to be open source)

Yes, just capture the output from the serial port (and change \r to \n where necessary). What happens when you're not getting input depends on whether you opened the serial port with blocking or non-blocking I/O. If it's non-blocking, it will read 0 bytes, if it's blocking, it will wait (usually with a user-set timeout) until it can read something.

I haven't tried JIFI yet because I don't use the Sun JRE, which is (currently) required, but it seems like his is a little earlier in development. His has a GUI, however, which may be more appealing for your purposes. Or, if you'd like to help write one for my library, that'd be fantastic

Originally Posted by Eldarion

Since I know exactly where the programming sequence is getting "hung up", maybe I could modify your loader to support a homemade programming cable?

Go for it! If you need any help, let me know (I hope my API is easy enough to work with )

[wcarr]

Cool on Linux!!!! I have a question though.

Short form: How do I rebuild it on windows?

Long form: I had enhanced the picloader application into a client/server socket application so that an old processor with wifi running on the robot could "push" the reset and programming buttons through the parallel port. Then I ported the hex file processing code to windows (we have those who don't want to leave windows). Anyway, it all worked except the picloader code made no effort to read the handshake messages, and if the serial cable was not connected, the interface would lie about the download completing. I looked into enhancing the picloader when I stumbled upon this thread. (BTW, This is an example of why I fully support your Open-Source FIRST post http://www.chiefdelphi.com/forums/sh...ad.php?t=52633)

I'd like to adapt rigel to the same client server methodology. However, I got hung up in the building of the rigel code on windows. I'd first tried to use MSdev, but figured I was wasting time as you already had it working on windows. I then tried cygwin (it was already loaded). It built, but ran aground with the "cannot execute binary file" error. I then looked up MinGW as you'd alluded to, but really didn't want to go down the path of loading up yet another *nix on windows toolkit.

If you can help me build it once on windows, I can take it from there. Naturally, if you or anyone else is interested, I'd gladly provide, and perhaps you could incorporate, the client/server work into the library (my first Open-Source FIRST contribution)?

Could you consider posting (or adding to 0.14) a quick HOWTO for building the code on windows (preferably, in my case, using MSDev or CygWin)?

Great work! Thanks!

[Shinigami2057]

Hey, thanks for your interest I'd love to see what you've been doing in relation to the client/server idea, that sounds very interesting. I'd definitely consider adding it to librigel, or at the very least include it in utils/.

Today I worked a little bit on the Win32 port of the latest code base for rigel, and with a small tweak (check for __CYGWIN__, which will make it use the same default port as linux) it compiled fine for me under Cygwin. I believe I accidentally packaged the binary for linux-x86_64 in the above tarball, which would explain why the binary wasn't loading on Windows (if you did ./rigel in cygwin's bash). Sorry about that Make sure you're running "rigel.exe".

Tomorrow I will upload the latest version of rigel and include a windows executable.

[Shinigami2057]

I have updated rigel to version 0.13, with some nifty new features and some bugfixes.

Get the source and Win32 executable here (you must have Cygwin installed for now):
rigel 0.13 source

From the ChangeLog:
New features -

• Added --eeprom switch. You can now load small binary files directly to EEPROM.
• Added ANSI terminal sequences to add some color to the UNIX versions.
• Overhauled AN851 code to retry 3 times on a failed handshake with the controller.

Bugfixes -

• Fixed minor compilation issues on Win32 (some warnings)
• Fixed OS X compilation (use select(2) instead of poll(2))
• Fixed bug where code would not run after a download.
• Fixed timeout initialization on POSIX systems.
• Force 8-byte alignment for flash writes (minor fix).

By the way, I have tested updating the master firmware, and successfully updated the 2005 controller to the beta version 14