Does anyone know when this information will be available? I assume we can start this all with the edu-kits once we get them right?
Or do we have to wait until the actual kickoff?
*Originally posted by djcapelis *
**Does anyone know when this information will be available? I assume we can start this all with the edu-kits once we get them right?Or do we have to wait until the actual kickoff? **
i don’t see why you couldn’t start with the edu-kits…they have the same chip, but different default code from what i understand.
Now just to get the insane amount of money we need to apply and get our EDUkit…
Hmmm, sounds like we’ll be applying right around Dec. 14th again this year. :-\
Just got the cd and tried installing the ide through wine. It didn’t work. It wanted IE (just to install), which seems a little overkill…
Anybody got a link for IE?
IFI loader installed successfully through wine (20031016), though I’m not sure if it’ll work. I think it should, but I don’t have the serial ports configured nor have a edu-rc to play with ATM.
I think I’ll be aiming for a IFI Loader+GPASM+SDCC combo for now. I’m really not sure if it’s possible to replace the IFI Loader yet. I also need to consider all the binaries that will run on the controller that they give us, and see which ones can be tossed and which ones are less trivial to replace.
Hopefully, I won’t fry the edu-rc in the process.
Update: MPLAB needs IE 5.0 and up to run, actually… The install prog just makes sure it’s there before trying.
Update: Oh, and the compiler itself installs fine, without any complaints whatsoever from wine. You must use the native, not built in version of msvcrt in order to use the compiler, otherwise it fails to spawn helper programs. Wine’s msvcrt is deficient in this area for some reason.
I’ve successfully compiled the edu_rc default code through wine with some tedious manual compiling. Not sure if the generated .hex actually works.
Just ran the IFI loader now, and it seems less than perfectly stable. Wine spits out a good number of warnings about things not actually being implemented and stubs (not too bad, happens with some apps), and attempting to open a terminal window takes the whole thing down (bad).
Hopefully, it’ll be just the terminal window that kills the thing, since terminals aren’t too uncommon.
Update: Crashes on loading .hex files too. Spits out a 440 automation error (whatever that means) and exits.
darn.
Any idea on WineX? I’ll try a few other builds of Wine when I get the software.
*Originally posted by djcapelis *
**darn.Any idea on WineX? I’ll try a few other builds of Wine when I get the software. **
depends on the version that you will be using. You might be able to modify some versions of WineX but it just depends on the version that you will be using. Crossover has a fairly good list of compatible programs but they are mainly geared to MS Office based programs and some other programs such as Internet browsers and other mainstream windows programs. I haven’t tried it yet on Crossover or Transgaming (hey it could work) but i’ll post what results I get when I get the time.
I would definetly like to not have to use windows this year if possible, and I am sure there are plenty of other too. Lets keep this discussion open as we find out more 
*Originally posted by codeoftherobot *
**depends on the version that you will be using. You might be able to modify some versions of WineX but it just depends on the version that you will be using. Crossover has a fairly good list of compatible programs but they are mainly geared to MS Office based programs and some other programs such as Internet browsers and other mainstream windows programs. I haven’t tried it yet on Crossover or Transgaming (hey it could work) but i’ll post what results I get when I get the time. **
With out using WINE, here are some links to utilities for PIC C development with in linux. http://www.ccsinfo.com/newtopiclinux.html or just a simple google search will show you more tools for developing PIC C in a linux environment.
I think the biggest problem right now is getting something to replace the IFI loader.
The IFI loader program looks like a vb program that acts as a frontend for PICBOOT.dll. Being a frontend makes me think that IFI probably didn’t do much work with making their own bootloader(or whatever it’s called). If the way they upload the hex files isn’t unique, it shouldn’t be as hard to find something that does what we need. Of course, I’m just guessing it’s a frontend since it looks like it uses vb. Anyone smart enough to write a program to program the PIC wouldn’t use VB… hopefully.
http://www.ccsinfo.com/newtopiclinux.html doesn’t seem to add much more new info than what was already found in this thread.
I doubt transgaming will work. Transgaming is also mildly evil. Crossover has a slim chance I guess, but you never know. I don’t think it’s a solution though, due to the fact that we have to buy it. 
Getting the libraries in the cd to work with sdcc and gputils seems possible, though I can’t say I’ve generated a hex file yet. That’ll be the next thing I do, unless we figure out this PICBOOT.dll thing…
*Originally posted by mikew *
Anyone smart enough to write a program to program the PIC wouldn’t use VB… hopefully.
Why do you say that? I’m no VB fan myself, but it’s an easy tool to work with and allows you to bang out a fairly nice GUI application rather quickly, especially for software engineers who are primarily embedded developers.
*Originally posted by mikew *
I think the biggest problem right now is getting something to replace the IFI loader.
FYI, I talked to IFI this week on other subjects.
While I had the tech support person’s ear, I said that there are LARGE linux AND Mac contingents out here that wish runnable copies of their loader under their systems. For example, my entire school DISTRICT is pure MAC House, and I felt IFI needs to insure they don’t cripple the entry of any school that is not a slave to Microsoft.
They said they’d take it under advisement, but don’t expect IFI upper management to react to the demand very soon. The new full RC itself is STILL not ready yet, and they’re up to their elbows in THAT project right now to even CONSIDER other things like this.
I then suggested they at least release the loader spec and/or code, and the CDF participants will port it FOR them. (Hey, it’s only a LOADER for goodness sake. THAT shouldn’t be too hard to port!) The tech support guy thought it sounded good, but had no power to do that. The entire spec is TOTALLY classified “company confidential” right now.
He said to be honest, with all of the other time pressures right now with the RC release, he even doubted that he could even get a release of the loader’s protocol approved, so don’t hold your breath.
Bottom line: Sorry, but I doubt we’ll see loader specs released in time for us to write one before Kickoff. Therefore, if we want/need a new loader before January, SOMEONE will probably have to bite the bullet, dive into it, and either come up with a way to get the supplied one to run under a Windows emulator, or attempt reverse engineering the loader and write a new one.
- Keith
A pretty easy solution would be to use vmware.
VB is fine for the frontend, I just mean the people who do the important backend stuff shouldn’t use VB. But anyway, that’s not the point of this thread.
I’m still hoping the loader code isn’t something unusual, but I guess IFI would tell us to get us off their backs if it was something simple, right?
Maybe.
Running under wine or vmware will probably work (and especially vmware), but a native loader would be best.
Bottom line: Sorry, but I doubt we’ll see loader specs released in time for us to write one before Kickoff. Therefore, if we want/need a new loader before January, SOMEONE will probably have to bite the bullet, dive into it, and either come up with a way to get the supplied one to run under a Windows emulator, or attempt reverse engineering the loader and write a new one.
I think so too. But I prefer the second option since windows emulation isn’t as hard. 
Microchip has a bootloader for the P16 and 18 series that I downloaded as part of a demo board package. Funny enough, the front end of the PC bit is written in VB and the source is included. The component library is also called PICBOOT.dll. Maybe they’re the same? The file sizes do not match:
IFI loader PICBOOT.dll = 44kB
P1618QP PICBOOT.dll = 132kB
http://www.microchip.com/download/appnote/pic16/00851b.pdf
<edit>
I take that back. They include the source for picboot.dll in the install package. Its a VC++ project.
</edit>
w00t! It looks like my guess is mostly correct, I think.
Is the microchip loader available for download?
Looks like the PDF describes how the bootloader works.
If someone can try running the microchip supplied loader to upload some slightly altered default code (maybe to send hello world or something to the serial port), we’ll be able to see if using this info is worth the effort.
Checking the file size or checksum of the two PICBOOT.dll files would also be nice.
I’ve started looking at the communication bettween the IFI and the EDU, what I’ve seen so far appears to match what’s in the PDF linked by sean.
I’ll keep poking and see what i can gather from my sniffing, but if someone could actually test the microchip program (or post a link so I can test it) it would be helpful (since it could save me work)
Wow, those file sizes are way too different… Maybe the IFI one is stripped? (or whatever it’s called in the windoze world…)
Or maybe they just took out some stuff they didn’t need. Dunno.
How are you sniffing the IFI output? Just curious…
I just rigged up a breakout box for the serial and connected in a second comm port (Rx only) to either the Tx or the Rx lines from the computer to the Edu.
I did find that the IFI is basically identical to the Microchip spec. Two notable exceptions:
-There are two undocumented commands, however each is only used once, and the data they send doesn’t appear to change.
-I have found what may be a bug in the code as well. I’m going to test more and confirm it.
Hopefully Sean will come link to the real microchip bootloader (since I can’t seem to find it). If not I might just start working on coding it myself.
[Edit] I’ve determined that that first commands is a bulk erase command, while the second command starts the user code running.
And the “bug” was my fault.
[EDIT 2] Found the Microchip loader. The reason for the file size differences is that the DLL was built with the debug code still in.
Without debug code the DLL is only 32k, which means FIRST added stuff to it.
The loader does appear to work, however the microchip programmer doesn’t restart the user code automatically as does the IFI programmer. (minor point)
Anyway, I’ll clean up all my notes and put them in a organized fashion and post it here in the next day or so. That way anyone who feels motivated to port the IFI loader to linux, Mac, PDA’s, etc can. (And hopefully they will share)
This post is now officially too long…
poke
Still planning to give us your notes? Do we necessarily need your notes to begin work on a loader? (or is the microchip pdf enough?)