Linux and new microcontollers.
 

Love the new controllers, using linux, want to program.

Working on building up a software list for them, if there's anyone else interested I thought I'd put it in this fourm, also, for those that have any links to share, here's a thread to post. :)

First thing I've found so far just appears to be fairly basic... no C libs yet.

http://www.brianlane.com/picprg.php

gputils
 

http://gputils.sourceforge.net/

Seems like a good start, though it's just an assembler. The program at http://www.brianlane.com/picprg.php seems to use a parallel port to connect to a programmer, while the RC has a serial port.. which does the programming somehow.

Would be nice to use linux for the dev this year, and I hope there's a way.

Have you used it before? There was support for PBASIC from a few places... heh, some of them developed by robotics teams. :)

worst comes to worst I'll be downloading my IDE of choice for windows... gVIM. ;)

Anyways, also came accross this for the C stuff:
http://massmind.org/techref/microchip/language/cs.htm

I don't have the experience with microcontrollers to tell how useful it is... but it looks promising.

PBASIC support was just some code wrapping the binary library parallax provided. In other words, it sucked. (well, more specifically, they didn't update the library when they were releasing their ide betas)

PICs on the other hand, are a bit more standard, so even with less support from the people who make things, there's a chance we'll get decent support. (that is, if you ignore the serial port programming issue, which I'm not sure about.) For assembly anyway. Getting a C compiler maybe pushing it. ;)

I hope I'm wrong about the C compiler though.

It appears you might be.

http://www.yty.net/pic/enindex.html

Nice little walkthrough.

Also, I think I saw some scattered links to serial programmers too.

Im a little fuzzy on what you mean by 'using' Linux with the new controllers.

MicroChip has a complete integrated SW development tool set, which you would install and run on a PC (like you did with the basic stamp editor)

I dont know if the Microchip development SW will run on a Linux system, if thats what you mean

I cant think of any reason why you would want to have Linux run on the robot controller itself (if that is what you are talking about) - since the RC doesnt have a disk drive or network, or video... there really is no need to have an operating system running on the PIC chip inside the robot.

I'm pretty sure they're talking about using Linux as a development environment.

The problem with this is that source and libraries are compiler specific, generally (speaking of embedded systems, uPs and uCs), so using a compiler other than what we're provided might be rather difficult. This is not to say that it's impossible to port the software, itself, but I think it would just be more trouble than it's worth.

Also, Linux-based assemblers, simulators, and programmers (software) are fairly common. Here's what I got from a query of apt (Debian), just now:
I don't think any of them are applicable to our situation, though.

The assembler that comes with gputil should be compatible with mpasm stuff, I think. There is no apparent free (as in source) compiler for linux so compatibility with the compiler is a problem we'd like to have.

Or, if you use the shareware compiler from http://www.picant.com/c2c/c.html , compatibility is a problem you already have.

Anyone wanna try using WINE? (I'll run it through wine once we get the edu-rc kit and software)

When the time comes, if that doesn't work I'll also nab winex (CVS version) and try that. Also, if you do get it running, could you post your datestamp for the release? Wine frequently experiences regression...

You guys might want to take a look at this page: http://www.piclist.com/techref/micro...anguage/cs.htm

[edit] Nevermind, this page is the same as one posted above, I guess....

Although that's not what this thread is about, there is a nice set of tools for the Lego RCX called BrickOS. This suite runs a stripped down Linux kernel on the Lego RCX.

If you have a full-up OS running on your embedded system, you have access to tools and hardware abstractions which may make your life easier.

If we stick with this new PIC for many years, I suspect that someone will inevitably port the BrickOS (or some such) over to it. Although that will depend on how much memory and storage the system has (relative to the RCX).

One of the neat things about BrickOS is the Lego Network Protocol (LNP), which allows TCP/IP networking to be done over the serial IR tower link. Can you imagine running TCP/IP over the radio modem through the dashboard to a wireless ethernet appliance. People from all over the world could log into a competition robot while it competes!

The advantage to using an embedded Linux would be to use the execi abstraction. This allows you to set up event driven interrupt handlers from inside your C program.

The scheduler is a built in part of the OS. Otherwise, you have to write your scheduler yourself.

To stay on the topic of this thread, CCS says they have a development suite for the PIC which runs under Linux. I have not dug down to the point that I have actually found this product or seen how much it costs.

http://www.ccsinfo.com/picc.shtml

Although this year is probably going to have a lot of people dreaming up cool stuff to do with the new features of the modern RC, I suspect that we're going to have to wait a couple of years before the full potential of this new programming power comes through.

Well, I have been looking into this for a while now, and it seems that all PIC programming projects for linux/unix are assembly and for earlier chips than the one in our RC's. Most are for 16F series, while ours is 18F. As far as I can tell, everyone should get their dual boots working as soon as they can... (myself included, with an empty 5 gig partition just waiting for a W2K boot...)

Wha? Give in that easily? The only apparent problem right now is the conversion from C to assembly. <s>The free C compiler I saw only does 16f, but someone might just add 18f support by the time we get to January.</s> If not, then wine might do the job. Hopefully, we can just make a sort of wrapper around the compiler that sets things up and runs wine.

And if all else fails, assembly doesn't look that hard. ;)

I don't dual boot, I just have two hard drives with windows on one and linux on the other. It's annoying to switch around so I have a good reason to hold on to my uptime. Last year, I just wrote most of the code on my laptop, moved it over to the engineer's laptop and finished things there.

Edit: I just checked again, and it looks like the SDCC does support 18f. I dunno if it does 18f8520, but it's that much more likely to work now. Now the problem is that SDCC probably uses a different C than the "official" compiler.

I'm using SDCC for a chip in my High Tech class (www.pjrc.com), and it seems to be pretty easy to use, even on Windows (yeah, it's pretty weird using Linux commands on Windows :p). I can't say I'm experienced with it, but what I've done has been pretty easy. And it's all happy CLI :).

PIC and C, on Linux
 

I've been programming PIC 18F452 for almost a year and have a pretty good understanding of the chip now. The 18F8520 is so new, I haven't found any development/evaluation boards for it yet.

The MPLABS IDE is a simple IDE, but eventually I switched to Komodo as it works with CVS (concurrent versioning system). For programming, I've been using the Melabs EPIC programmer.

Hi-Tech sells a C compiler for the PIC which will come with a Windows version and a Linux version, but is expensive. C2C is cheaper. The CCS compiler is a popular choice, but isn't fully 100% ANSI C.

No SDCC or GCC port yet, but I'm still hoping this will change soon as the incentive is there. The 18F now has enough of a stack to make this possible now. A GCC port would make BrickOS on the PIC possible.

Each compiler accesses the PIC hardware with different semantics, so changing compilers means you have to rewrite the code.

As for an IDE, you have many choices besides VI (vim) and Emacs/Xemacs such as Eclipse, Kate, KDevelop, Komodo (ActiveState.com) and Kylix. I probably missed a few, but these are the ones I'm familiar with. Most of these can be extended to support the compiler and a download utility.

For programming a PIC, there's PonyProg and PP06, neither of which I've tried yet as I haven't yet completed my Windows to Linux conversion on my last Windows box.

There is no Linux port to the PIC chip. It just isn't possible, but the smallest 16 bit Linux is ELKS for the 8086 and takes up 32K. Don't know if there are any real-time embedded operating system for the PIC yet, particularly of the open source variety. Unless somebody is porting eCos this very minute.

Oh, and I've been programming my Lego Mindstorms in NQC, which is a subset of the C language, on Linux.

Btw, check this out: http://www.penguicon.org

Linux rocks! Windows sucks. Why pay the Microsoft tax on your computer?

The evaluation board for the PIC18F8520 is part number DM183020. The demo board comes with a different part, but its supposed to work with the 18F8520. Its out of stock at digi-key, but normally $49.00. The chip itself is $11.28. Its a companion to the MPLAB ICD-2 so I'm not sure whether you can program it without that.

The microchip page refers to a serial bootloader. I would assume that this is how you program it in the demo board (and probably how we do it in the control system also).

The demo board does not include the 13V power supply needed to program the chip. The pins used by the ICD modular jack are well documented, so you can probably modify the board to work without the debugger.

the only thing that makes me apprehensive about using these tools are that FIRST has said (or maybe it was innovationfirst) that microchip is providing a modified version of the C18 libraries to work with the IFI controllers...so i'm not sure these compilers would have the right libs/directives needed to properly compile a program for the new controllers.

i'm not saying these tools WON'T work, im just saying it's a possibility...i'd hate to get familiarized with an IDE/compiler and then not be able to use it :(

Then just copy the libraries over and link to them. No one said you had to use the libraries included with the compiler (sdcc).

Not to say there won't be any work getting files distributed by IFI to work with SDCC/MPASM/etc. We'll see.

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.

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 :)

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

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.

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.

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

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

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]

Re: Linux and new microcontollers.
 

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.

Re: Linux and new microcontollers.
 

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.

Re: Linux and new microcontollers.
 

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

Re: Linux and new microcontollers.
 

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.

Re: Linux and new microcontollers.
 

It runs pretty much the same speed, if not faster using wine due to the lack of mplab. Hm, my loader I made is available on downloads if you want to try using that code and upload it to the PIC.

Re: Linux and new microcontollers.
 

Thanks to rwaliany's scripts I was able to use linux as my development platform again this year (2 years out of two) and look forward to seeing it improve.

However today I noticed that sdcc had made it's way into gentoo's package management system. Perhaps a solution for next year?

http://sdcc.sourceforge.net/

Looks like they're slowly getting PIC 16 & 18 compatability... anyone tried it lately?

Re: Linux and new microcontollers.
 

I've just been able to read a bit of the thread, our team is interested in using linux for programming, but we're having problems. So far, we've got the gputils asm compiler, and the picloader and reader.

What else do we need to get this going? I'm assuming we'll need a C compiler that will convert it to Intel syntax?

I found a link earlier in the thread linking to a page with a list of links, one of them being pico-C, has this been tested? Does it work?

When we get all of this working togther, we'll be able to use emacs as our environment won't we? So long as we set the compiler command to something that will convert the C to asm and compile it, it could be one program couldn't it?

-Thanks in advance. :)

Re: Linux and new microcontollers.
 

Running mcc18 through wine is your best bet at the moment. mcc18 comes with the linker and everything, so gputils isn't needed.

Yes, you'll be able to use any editor you want. vim, however, is clearly the superior editor to use. :p

If you do find a way to get things working through gputils + sdcc, please let us know.

http://sourceforge.net/projects/ifi-picloader/