So, Jifi is a java IFI loader for the 2006/2007 RC. I could not get IFILoader to work in Wine (I program in Linux) so I had to find another alternative. I have had pretty good success with this but do not guarantee that it will work for you. Right now, all I have is a linux package at http://shtylman.com/jifi but will be adding a Windows and Mac version soon.
If you have any comments or suggestions please let me know and I will try to implement them.
P.S. The program is in the early stages and may (will) have bugs. I also plan to at some point release the source as well as an eclipse plugin. Right now it only works with the 2006/2007 RC (The 8722 chip) but can be made to work with others.
It would be really nice if you could help Astronouth integrate this into the FIRSTClipse project. It already uses SWT for the GUI, and if you’re willing to provide the source, it would be really helpful. We already can compile the robotics code in Eclipse without writing makefiles, this would be a really great addition.
BTW, does this work with the pre-06 RCs, the EduBots or the Vex robots?
Although relatively few use the EduBots (aka Robovation), having support for at least the older RCs would be nice. Assuming your program works in the same way that the other loaders on here work, it should just be a matter of changing one value in the code (I think). I’m no expert on it though.
EDIT:
All right, I just tried running it, (I was too excited over seeing a Java version of the IFI loader), and I get an UnsupportedClassVersionError when executing the Jifi executable in the Linux directory. This is with sun’s java5 jdk on Ubuntu Edgy 6.10.
Did you use another loader as a code base? (eg, IFI Reloaded, pycloader, etc.)
How structured and generic is the code? One of the things that I’d like to allow is for creative uses of the loader (eg, EEPROM variables).
As far as integration goes, here’s my opinion (if any of the developers on the project disagree, please tell me):
You may host the code on FIRSTclipse’s Subversion on SourceForge, and you joining the project
I’d like to be able to use the serial library for other uses (eg, dashboard, terminal, camera)
The code must be licensed compatible to the Eclipse Public License (what FIRSTclipse is licensed under) or the GNU GPL (my preferred license)
The code must be able to run under Java 1.4
GUI must be SWT
The last two points may happen after any code import.
As to illustrate my point as to the usage of the libraries outside of this little project, I looked at some Java-base CMUcam2 GUIs, and decided I couldn’t use them. Why? Their code was not structured into separate modules, so I could not easily take their code and use it in mine. Interfacing with the camera and parsing the data isn’t that hard, so I’ll just write my own.
As for the loader, I’d like to see independent and useful libraries to interface with the code, such that each library could be a separate Eclipse plugin. If you borrowed the OOP methods from pycloader, that’d be awesome. If not, I’d like to see the structure first.
The GUI is in SWT*]I Used RXTX, a GNU java library for serial communication.
Because I used RXTX, my program is also GNU/ opensource I guess
The program compiles in java 1.6, and possibly 1.5, I will not drop to 1.4 (I think I may be using generics somewhere).
Beyong the GUI and serial libraries, all of the other code (logic, downloading, hex reading, etc was all done from scratch.
I have my own subversion server I use, but thanks for the offer
The loader has the ability to transfer code faster than the official ifi loader (I can provide technical details, but trust me its true).
The structure is pretty clean and can be expanded upon fairly easily (I think).
The GUI is just a frontend and the program can work without it just fine, the two are not permanently joined (aka I planned to drop it into an eclipse plugin at some point)
Hope that got everything.
As a side note, the point of writing this was to hopefully send it over to the IFI guys and use it as an official loader. I am in the process of trying to get this to happen because I think a platform independent loader would be wise and useful. Until then, I will not open release the source to prevent tampering with the protocol as it can cause the RC to do weird things.
Unfortunately, many GNU/Linux distributions (include slackware and Fedora), ship with a gij version that matches Java 1.4.2, and although it has some 1.5 extensions it doesn’t seem to be able to read the class file version. This is pretty limiting, IMO, but of course, free software nuts who don’t use the Sun JRE may not exactly be your target audience
This is the error I get:
Exception in thread “main” java.lang.ClassFormatError: jifi.Jifi (unrecognized class file version)
at java.lang.VMClassLoader.defineClass(libgcj.so.7rh)
at java.lang.ClassLoader.defineClass(libgcj.so.7rh)
at java.security.SecureClassLoader.defineClass(libgcj.so.7rh)
at java.net.URLClassLoader.findClass(libgcj.so.7rh)
at java.lang.ClassLoader.loadClass(libgcj.so.7rh)
at java.lang.ClassLoader.loadClass(libgcj.so.7rh)
at gnu.java.lang.MainThread.run(libgcj.so.7rh)
Yea, I understand that limitation but as far as I am concerned Java releases their software for free and it is just the choice of people to stick with the GNU stuff that is outdated. I don’t want to start a flamewar about free software or anything like that, but keep in mind that just cause some people don’t want to use software that is closed source but free just because it is closed source, others, myself included, just like the fact that its free. I would look into installing java 1.6 from Sun if I were you and not dwindle on the whole GNU thing. Just my $.02
Understood; It doesn’t matter to me what you use, I was just rambling as usual
Anyway, I’ve also been working on a program loader (in C), and one of the things I’ve just recently started working on is “an851d”, which is just a server that pretends to be a PIC18F8722 with IFI’s boot loader. By connecting my two serial ports together, I’ve been able to test it extensively without having to worry about screwing up our team’s FRC, and have squashed a few bugs I couldn’t have (reasonably) otherwise. If you’re interested in using it to test I’d be glad to release the source before I release it all together (it’s about 95% done).
It basically just responds to any valid bootloader command it gets and prints out information about what commands its received (see picture).
I have now made a windows package for the people that want it. It is found at the same place as the linux package (http://shtylman.com/jifi) except with extension .zip
small tip: in the config tab, change the “chunk size” to something bigger (248 max) and see the effect on download speed.
You do realize that the protocol is documented by Microchip (see AN851) and http://www.astro73.com/wiki/IFI_Loader_protocol (my own documentation)? I’m not sure what you have that 3~4 other developers have missed.
And also, IFI probably will not allow you to open source it. IMHO, you need to make that choice up front.
I was not aware of the microchip documentation, but thank you for that.
As for what IFI decides, I will leave that up to them. I don’t think it is fair to speculate given that I don’t know that anyone has ever offered.
Also, From my previous research into loaders I found just one (picloader I think) that stopped working on the newer larger code size controllers, was only for linux as far as I could tell, and was not very flexible in what I wanted to be able to get out of it. If I missed something, I am sorry, but this loader was also more of an exercise for me in protocol sniffing and implementing, so I don’t mean to offend or belittle anyones efforts.
How hard would it be to integrate a serial console to your program as one of the tabs, like the “debug window” that pops up in IFI’s program?
I know that I can “cat /dev/ttyS0” in Linux or “type COM1” in Windows, but it would be nice to have it integrated if possible.
From what I understand, it involves reading the serial port when not downloading, checking if it is ASCII (to avoid getting garbage data, i.e. line feeds or else values between 32 and 126), and displaying it in a text box.
Also, IFI has a useful checkbox to pause output… I would imagine this might also be relatively simple to add in.
I fixed picloader’s size problem in CVS head. I’ll make a package for it later. I
“inherited” it from Ryan Waliany.
And no, it isn’t very flexible. Which is why I wrote pycloader (a python implementation). It is less complete (doesn’t handle buffering data), but is far more modular.
While browsing your repo, I noticed a bug in your INHEX32 file handling code. You need to handle extended linear addressing directives if you want to support the full size of the 2006-2007 FRC (the HEX file can only fit 2-byte addresses, 0x0000-0xFFFF, but the PIC18F8722 supports up to 0x1FFFF bytes). PM me if you’re interested in a patch.
If not, I’d like to see the structure first.
