| Joseph Woollacott |
| | Jan 26, 2005 at 01:34 AM | Reply with quote | #1 |
|
Ive been looking for a way be able to program Picmicro chips from either osx or linux (ppc) and have been unable to find any programmer w/ the means to do so for OS X or linux (ppc) Suggestions would be appreciated (and unfortunately I cant afford Virtual PC or the likes so I need a native prog) If your wondering how i compile/assemble the code I write w/ mpasm within a dos x86 emulator (dosbox)
Unfortunately dosbox doesnt have the necessary commands to use the hardware of its host so this isnt an option |
| Loading... | |
| Bob Axtell |
| | Jan 26, 2005 at 10:21 AM | Reply with quote | #2 |
|
At the moment I have no mandate to port MicroPRO to Linux.
We might possibly create a DOS version of MicroPRO, as we already have DOS Borland Turbo Pascal. MicroPRO is written in Borland Delphi6, which IS available in Linux, but we don't own the compiler.
Check with us every so often, OK?
--Bob |
| Loading... | |
| George Caswell |
| | Jan 27, 2005 at 12:26 AM | Reply with quote | #3 |
|
Hi,
I have kit 149 (the serial/USB programmer) and because the protocol is available I've been able to write a controller program for the programmer in Python using the serial library. It's still a very hands-on thing (no GUI yet) but it gets the job done. I've only tested it on x86 Linux using the serial port - but in principle it should work just as well on any platform with Python, and on USB as well.
Oh, and I've only used it with a couple chips, too, mainly the 16F84 and '84A.
I'll be posting the code to my Sourceforge space soon. |
| Loading... | |
| Randy Glenn |
| | Jan 27, 2005 at 12:35 AM | Reply with quote | #4 |
|
George, if you do post it, I'd be more than happy to contribute to the project. Getting these programmers working in OS X is something that I've wanted, well, since I started using a Mac again. |
| Loading... | |
| Randy Glenn |
| | Jan 30, 2005 at 03:55 AM | Reply with quote | #5 |
|
| As posted on the PICLIST... http://www.kc8apf.net/pp/ is a C-based program for operating the K150 on Linux and OS X. Compiles fine on my OS X machine, though I've not tested it yet. |
| Loading... | |
| George Caswell |
| | Feb 01, 2005 at 12:39 PM | Reply with quote | #6 |
|
I'm very anxious to see the kc8apf program in action. More options for people using Linux!
I've uploaded mine and checked it into CVS. The ZIP file is at my Sourceforge project page:
http://www.sf.net/projects/tetsujin/
If you'd like to do a CVS checkout to keep up-to-date that way, the necessary information is available on the "CVS" link from that page. |
| Loading... | |
| ialdaboath |
| | Feb 05, 2005 at 02:08 AM | Reply with quote | #7 |
|
Has anybody managed to get either of these working? I'm running on OSX 10.3, with k149D via USB. It's functional under virtual PC so I know the board works.
The kc8apf software compiles, runs, and fails. Pointing it at /dev/tty.usbserial-1B1 I get the start-up response from the k149 (ascii 'B', number 2), as specified in the softprotocol5 doc. But after that, nothing.
I'm a novice with serial port programming, and I'm at somewhat of a loss. How can I be sure the write is getting to the board? Am I using the right /dev, or should I use /dev/cu.usbserial-1B1? Does the serial port need to be set up differently than on linux? Any pointers will be very welcome.
Similar (lack of) results with the python module, I'm just a bit more comfortable with C.
A friend of mine at NYU says anybody who can demonstrate a working pic programmer on the mac will be a hero to the physical computing students. 
az |
| Loading... | |
| George Caswell |
| | Feb 05, 2005 at 07:53 AM | Reply with quote | #8 |
|
It's entirely possible my Python module is out of date. I wrote it last summer and targetted it at the firmware that came with my #149. I'll update my software once the next version of the firmware comes out with PIC18F4550 support comes out.
It's also not a turn-key solution. In the future I'd like it to be, I'd really like my control software to develop into something on par with the Windows Micropro software, with a useful GUI and all that. Right now I'm mostly happy that it's a solution I can use, but even for my own use it's a bit fiddly.
Also note: As I've said, the only PIC I've programmed with my control software is the 16F84 family. There are all kinds of untested things that could go wrong if you're using another PIC.
One positive thing I can say about my software, though, is it's probably a lot easier to diagnose problems in an interactive Python environment than in a C debugger. For instance,
- It's relatively easy in Python to write a wrapper class for the serial port object which will log the traffic that goes both ways.
- If my code is run from a Python interactive session, you have the ability to control every step of the transaction (though this, of course, requires a good understanding of how the PIC programmer communicates and the typical order of operation.) The individual protocol interface functions are pretty strict about the responses they expect from the programmer, so if something goes wrong it should at least be evident what requests are failing. You can also access features like the board's "echo" command to make sure the interface is working.
I'll give my program a try under OS X, though, using USB. Maybe I can make it a bit easier to get started with this thing. If you want to be more specific about what's going wrong with my code I may be able to help you get going with it. |
| Loading... | |
| George Caswell |
| | Feb 05, 2005 at 12:32 PM | Reply with quote | #9 |
|
OK, I verified that my software works on Mac OS X. But it is very fiddly, more fiddly I'll bet than the other program (which I still haven't tried). I'll provide a little more detail on what needs to be done.
First, to use my module right now you need an additional Python module called PySerial (http://pyserial.sf.net). Install it according to the instructions on the site.
Second, right now it's easiest to use my code if you run it from the directory in which it's installed. This is for two reasons. First, it looks for the "chipinfo.cid" file in the current directory. Second, it uses Python's default searching rules to find the other Python files which make up the program. So if those files aren't in your Python Path, then they need to be in the current directory.
Third (of course) if you're using USB you need to make sure you have the FTDI serial driver for the appropriate chip installed.
It's also important to note that certain things are case-sensitive. In particular, the chip name (so say "-p 16F84A" and not "-p 16f84a"). I consider that one a bug, in case you were wondering. It's an incredibly stupid thing to trip the user up with.
So once pyserial and the FTDI driver are installed, and my code is unzipped into a directory somewhere, start up a shell and go to that directory.
From there, you can run a command like this:
./micropro.py -p /dev/tty.usbserial-1B1 --pic_type=16F84A -i ../src/pic/program.hex
The TTY name may vary - but if it's USB on a Mac you can go as far as "/dev/tty.usbserial" and hit TAB and the shell will complete it if there's just one.
You also have the option of specifying fuse values, if you'd like to override the default fuse settings from your input file. The names and possible values of the fuse settings all come from the chipinfo file. So where you'd see this in chipinfo.cid:
LIST1 FUSE1 "WDT" "Enabled"=3FFF "Disabled"=3FFB
LIST2 FUSE1 "PWRTE" "Disabled"=3FFF "Enabled"=3FF7
LIST3 FUSE1 "Oscillator" "RC"=3FFF "HS"=3FFE "XT"=3FFD "LP"=3FFC
LIST4 FUSE1 "Code Protect" "Disabled"=3FFF "Enabled"=000F
You could specify options like --fuse="Code Protect":Enabled or --fuse=Oscillator:RC and these would get patched into your code before it's written to the PIC. It's probably also case-sensitive. It's not a great UI but it gets the job done.
I hope this helps. I'll be trying the other program sometime soon on both Linux and Mac - I'll let you know if I can provide any helpful advice with that. |
| Loading... | |
| antics |
| | Feb 06, 2005 at 09:24 AM | Reply with quote | #10 |
|
I've been trying to get pp to work so 'll throw in my 2 cents. I using a K149D (which uses the k149bc firmware oddly enough) on Fedora Core 2, 2.6.9 kernel. The hardware works fine under Windows. In Linux I can't control the programmer because the Protocol codes don't match up. My board uses diypack22 which seems to point to protocol P016 but pp uses P018. I diffed the 2 and it didn't seem like they were that different. I started playing with the source and changed the PROTO_VERSION definition to '#define PROTO_VERSION P016' hoping to fool the program. That didn't work and I wasn't getting anything back from the error messages so I changed function programmer_proto_check to output the programmer version (read back from the programmer) to hex so I could see what's happening. pp is recieving FEEC8AB8 back from the programmer...any ideas why? these are not ASCII chars so I'm not entirely sure what's going on. i would just comment out the proto check but i'm afraid that if that is returning junk the rest of the functions won't work either. i am going to upgrade my firmware once i can get my hands on 16f628. in the mean time i am going to continue trying to get pp to work with P016.
my error code:
Expecting _P016(50 30 31 36)_, got Version: _FE EC 8A B8_
Error: wrong protocol version |
| Loading... | |
| antics |
| | Feb 06, 2005 at 11:48 AM | Reply with quote | #11 |
|
SUCCESS!
As usual I spoke to soon and it lead to a break thru. I found the bug and was able to read the program off of my pic (16F84A) and it ran fine in gpsim. I will try writing and let you know how that goes.
The problem was 2 incorrect commands and one fudge factor. The commands are the same in P016 and P018 so I'm not sure why this code worked for the author but then again what do i know? (hint: not much)
Change in src/programmer.c:
1 #define PROTO_VERSION "P016" /* Originally P018 - this is a hack */
2 int programmer_chip_in_socket(int port)
command = 22; /* not 21 - this is an error? */
3 int programmer_proto_check(int port)
command = 19; /* not 18 - this is an error? */
Rebuild and you should be all set. Again I am using K149D with diypack22 (protocol P016). Also note that this DOES NOT add the updates from P016 to P018 - it just fools the program into thinking everything is kosher. As far as I can tell it will be ok but don't bet your job on it. |
| Loading... | |
| ialdaboath |
| | Feb 07, 2005 at 11:50 PM | Reply with quote | #12 |
|
Hey, some success for me as well! The python module is working, I've successfully programmed a 16F84A, hooray for blinking lights!
The c program (pp) still isn't working for me, and its the sort of thing that I know I won't be able to stop thinking about. I spent quite a bit of time this weekend struggling with it, comparing it with the python module, reading up on termios (ugh). I'm not sure its useful to spew some of my experience here, but why not.
It seems the serial communication just isn't happening. Stepping through micropro.py, I see that the startup sequence is:
- open connection
- read board version code (eg, B2)
- execute a reset (dtr-off, wait .1 sec, dtr-on)
- read board version code (eg, B2)
A test program to do this from C doesn't work. Opening the connection and reading the board version code is fine, but the reset doesn't seem to go through. The termios flags in the C program are exactly the same as the python version, the flags passed to open, etc. I'm sure there's some obvious thing I'm missing as a novice, some platform difference between linux and BSD/darwin.
In any case, I'm thrilled to have an all-mac toolchain working. Hopefully I can forget about the mystery and just be happy it works.
George, will you accept contributions to the python module? A few obvious things I can see are (1) making the recognize what protocol version it has an enable/disable certain things (I've already upgraded my board to diypack25/P018); (2) adding more command-line options, like reading hex files or erasing a chip; (3) a chipinfo mode, to print out the fuse options available for a particular chip; or as you pointed out (4) making the chipinfo reader case-insensitive. How can we go about helping out?
Thank you very much for the help and tools! This is the first time I've used a message board, and it's been a very pleasant experience. Saved me a heck of a lot of work, that's for sure...
az |
| Loading... | |
| George Caswell |
| | Feb 08, 2005 at 02:19 AM | Reply with quote | #13 |
|
Quote: Originally Posted by ialdaboath
Hey, some success for me as well! The python module is working, I've successfully programmed a 16F84A, hooray for blinking lights!
The c program (pp) still isn't working for me, and its the sort of thing that I know I won't be able to stop thinking about.
A test program to do this from C doesn't work. Opening the connection and reading the board version code is fine, but the reset doesn't seem to go through. The termios flags in the C program are exactly the same as the python version, the flags passed to open, etc. I'm sure there's some obvious thing I'm missing as a novice, some platform difference between linux and BSD/darwin.
George, will you accept contributions to the python module? A few obvious things I can see are (1) making the recognize what protocol version it has an enable/disable certain things (I've already upgraded my board to diypack25/P018); (2) adding more command-line options, like reading hex files or erasing a chip; (3) a chipinfo mode, to print out the fuse options available for a particular chip; or as you pointed out (4) making the chipinfo reader case-insensitive. How can we go about helping out?
I'm not sure what to make of the problems you're having with the DTR line working in C. I'll see if I can find some time to tinker with pp on my home machines.
Does micropro.py really read the board version both before and after the reset? I can't seem to find anyplace where I've called the firmware version/protocol version functions at all... Weird... What's maybe weirder is that, as far as I can tell reading the code, the pp code doesn't touch the DTR line at all... (Am I missing something?) It's possible to get by without messing with the DTR line at all, as long as the firmware doesn't crash or otherwise get into a weird state the controller software isn't prepared to handle. You may also need to patch the pp code as antics described, if you haven't already.
I actually haven't done much serial port programming at the C level... I'm not really sure what to make of the problem you're having with the serial port on the Mac. Could you post your source code test if it's reasonably small?
I'll certainly accept contributions. The main restriction is that contributions have to fit the licensing terms of my module (GPL). I'll certainly give proper credit to anyone who contributes.
The best way to contribute code is to do an anonymous checkout of my module from Sourceforge CVS, edit the code as needed, and use cvs diff -u to create patches for e-mail submission. As the project matures I'll consider giving it its own dedicated project space at SF and giving other developers check-in permissions.
My thoughts on the changes you suggested:
1: Supporting multiple protocol versions is a potential maintenance headache. The differences between protocol versions are usually pretty subtle and don't necessarily fit what's documented. The module can't be written to fit the spec, it has to be written (and tested) against the devices' actual firmware. (I had some back-and-forth with Tony about the protocol doc when I was working on the module. It was very helpful with a lot of problems and questions that came up.) - Of course I would like to make the module reasonably compatible with different firmware versions (so that people can use the tool to upgrade their firmware ) but it's not something I'm prepared to maintain and test on the different firmware versions. There are already quite a lot of combinations of programmer hardware + PIC hardware to support without worrying too much about old firmware versions...
What I may do is tag particular versions in CVS according to what protocol level they're known to work with, and later on print warnings if the protocol level doesn't match what the code expects. Then if someone needs to update their firmware, they may need to fetch an older version of the Python module, program their firmware update, then update to the latest version of the Python code again.
2, 3, 4: I'm all for that. This really is the very first version that I've made even moderately convenient to use. Before I added the command-line support I was accessing all the functions in Protocol_Interface and Chipinfo_Reader by hand in an interactive Python session. I do think that these things (and others) are very important additions. I also want to make it easier to call - removing the expecteation that chipinfo be in the current directory, finding the other Python code in the same place as the micropro.py, etc... I think Python has a module bundling facility of some kind for that.
Another thing that needs to change is the programmer script needs to tell the user where to put their PIC in the socket. The micropro.exe does this visually. The information is in chipinfo, and I know how to translate its representation there into something people can actually use, it's just not been done yet.
If you try other types of PICs, let me know if they work! |
| Loading... | |
| antics |
| | March 03, 2005 at 10:07 PM | Reply with quote | #14 |
|
I'm not sure that anyone is still trying to get a K149D working under Linux but if you are here is a patch to modify the pp source code to use the proper firmware version and commands. I meant to post a while back but was away.
http://www.nervousbot.us/pic/pp-P016.patch.tar.gz
run
$ tar zxfv pathtofile/pp-P016.patch.tar.gz
in the pp-0.1 directory
run
$ patch -i pp-P016.patch
in the pp-0.1/src directory.
to program a 16f84a via the USB cable
$ pp -p /dev/ttyUSB0 -d 16f84a -f -w myPicProg.hex
cheers, antics
|
| Loading... | |
| Bob Axtell |
| | March 03, 2005 at 11:22 PM | Reply with quote | #15 |
|
The DTR signal operates backwards from all other DIY kits. That might help some...To reset the K149 at the APP code:
CLEAR DTR
wait 50mS
SET DTR
Operate all programming with DTR set.
We have discovered significant errors in the protocol released in August of last year. Brandon Fosdick and I have worked on it and the document should be released today or tomorrow.
--Bob |
| Loading... | |
