Linux and new microcontollers.

[Dave Flowerday]

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.

[kmcclary]

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

[ckim]

A pretty easy solution would be to use vmware.

[mikew]

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.

[seanwitte]

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/ap...c16/00851b.pdf

<edit>
I take that back. They include the source for picboot.dll in the install package. Its a VC++ project.
</edit>

[mikew]

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.

[Random Dude]

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)

[mikew]

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...

[Random Dude]

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...

[mikew]

*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?)

[Random Dude]

Bah thanks for reminding me. The pdf is enough for the most part. The differences the IFI uses are:

Erase the Flash: 0F 0F 09 XX 00 02 00 00 YY 04
where XX is the (highest_mem_to_write)/64
and YY is the checksum (see pdf)

I think the remainder of the data in that command is static.

However the method specified in the pdf also works

Restart the User code: 0F 0F 08 40 B8 04

[edited since i submitted by accident]

[mikew]

Ok, I don't want to stuff up the version control thread with off topic posts anymore, so lets continue it here.

I'm gonna write a uploader for Linux if no one else does by the time I need it. (around xmas break) If someone else wants it earlier, they can do it and I'll pitch in later if I can understand the code in 30 minutes. I plan to create an OS agnostic core library that just generates the stuff sent to the serial port, while some wrapper code handles setting up the serial port, sending data, GUI/CLI interface, and whatever else necessary. I guess the parsing of the hex files will be handled by the library, but the wrapper code needs to open the file itself and feed the stuff to the library. Sound like a plan?

I think there's some simple stuff that can be done to make setting up the compiler/linker/assembler toolchain easier. At least some HOWTOs on how to put everything together, and maybe some program/script to automate most of the process. Maybe toss a Makefile in to make things really easy.

I'm not sure if it's possible to use GPUTILS/SDCC instead of the Microchip provided compiler since we need to work with a binary library that communicates with the other microchip inside the controller. I doubt source or specs will be released for that library. I'm not sure if the library is really needed other than to access data from the inputs slowly. Also, SDCC doesn't support the exact chip used in this year's controller, so I don't know if it'll generate working code. GPUTILS works though, you just have to copy the .lnk file (IIRC) since the memory map is slightly different from usual. (can't write to the bootloader region)

The bootloader is the most important part. Let's concentrate on that first. The second most important part is making sure the stuff created by running the toolchain through wine is basically the same as the stuff run natively through windows. My .hex file didn't match the default .hex provided by FIRST, but it may have different code. We need to compare the .hex compiled with mcc on windows, with the .hex provided by first, as well as the .hex generated on linux. Have to be extra careful that the same parameters used on the windows compile is the same in the linux compile. I'll do that this weekend if no one else does it.

[mikew]

Sorry, I've been busy/lazy lately. I just manually compiled the default code through wine with the same commands used by mplab, and the hex files generated are identical. (as I was expecting)

I have access to our robot prototype now, along with the edu-rc. The bootloader is on the bottom half of my list of things to do before the kickoff. I have to get our prototype working, put up a website, and relax before taking on the loader.

I don't think I'll be able to work with sdcc and gputils and see if they're feasible replacements for mcc18. It looks like a LOT of work, and this solution "just works" for me. sdcc and gputils would of course be useful for mac users, or non x86 users in general. I can imagine how cool it would be to edit, compile, and upload code from a zaurus. I'm not likely to get one though.

[rwaliany]

sorry, it's late at night. Read my new thread, it has support using MCC18, seems to work great compiles and links fine. Wine -> MCC18 -> IFI, I'm using codeweavers trial version of wine. Have to use self-made scripts though, check it out.
http://www.chiefdelphi.com/forums/sh...ad.php?t=23254

Also, My LInux HEX
bash-2.05b$ ls -ltra *.hex
-rwxr-xr-x 1 ryan users 24637 Dec 3 17:27 EDU_default.hex
-rw-r--r-- 1 ryan users 24722 Dec 28 02:39 EduCode.hex

vs Windows

root@laptop:/windows/EDU_Default_Code_2003-12-15# ls -ltr *.hex
-rw------- 1 root root 24637 Dec 3 17:27 EDU_default.hex
-rw------- 1 root root 24722 Dec 28 02:09 EduCode.hex

two brand new installs independent of each other

[burNeD]

I've looked thru the FreeBSD ports collection, and google'd endlessly for a PIC C compiler for the series of microcontrollers we're using this year and found nothing. It really sucks its like there is an assembler or compiler for every $@#$@#$@#$@# pic series with the exception of ours. I just have been using wine to run mcc18, and this has worked for me.