Back around 2006, I had a PICStart-Plus connected to a
Debian Linux system but I sort of drifted away from PIC's but would like to get things going again. As a computer user who happens to be blind, I much rather use text-based development tools. I had good luck with gpasm and gpsim after getting them installed. Since then, I have upgraded to Debian Lenny so the environment has changed a bit. I am still on the gnupic mailing list, and it still is alive, but it looks like everybody has deserted it. Basically, are there any new versions of gpasm and gpsim that can install under debian and talk to the PICStartPlus? Is there anything like gcc I can install to write C code for PIC's? One of the reasons I drifted off was that I realized that some projects would be much easier under C than they are under assembler. The PICStartPlus worked perfectly the last time I programmed a 16F84 so I hope I can get it going again and do some new projects. Martin McCormick WB5AGZ Stillwater, OK Systems Engineer OSU Information Technology Department Telecommunications Services Group -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Martin,
Two quick recommendations. 1) Take a look at JAL. http://www.casadeyork.com/jalv2 JAL has an active user community, strong library support, and a compiler that works on Linux. For a good sample check out this trivial USB/serial system using a 18K1450 and JALs USB libraries: http://jallib.blogspot.com/2009/07/pic-18f14k50-usb-interface-board-part-2.html JAL is not C. However, it is a high level language that will get your PIC projects going really quickly. 2) Consider upgrading to a PicKit 2. It's USB and Microchip has Linux support for it using pk2cmd. On the Linux side it doesn't do debugging IIRC and also the logic system doesn't work. But it'll program most any PIC and will run on your Linux box. Hope this helps, BAJ On Fri, Dec 31, 2010 at 02:31:39PM -0500, Martin McCormick wrote: > Back around 2006, I had a PICStart-Plus connected to a > Debian Linux system but I sort of drifted away from PIC's but > would like to get things going again. > > As a computer user who happens to be blind, I much > rather use text-based development tools. I had good luck with > gpasm and gpsim after getting them installed. > > Since then, I have upgraded to Debian Lenny so the > environment has changed a bit. I am still on the gnupic mailing > list, and it still is alive, but it looks like everybody has > deserted it. > > Basically, are there any new versions of gpasm and gpsim > that can install under debian and talk to the PICStartPlus? > > Is there anything like gcc I can install to write C code > for PIC's? One of the reasons I drifted off was that I realized > that some projects would be much easier under C than they are > under assembler. > > The PICStartPlus worked perfectly the last time I > programmed a 16F84 so I hope I can get it going again and do > some new projects. > > Martin McCormick WB5AGZ Stillwater, OK > Systems Engineer > OSU Information Technology Department Telecommunications Services Group > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist -- Byron A. Jeff Department Chair: IT/CS/CNET College of Information and Mathematical Sciences Clayton State University http://cims.clayton.edu/bjeff -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
In reply to this post by Martin McCormick-2
On Fri, Dec 31, 2010 at 2:31 PM, Martin McCormick
<[hidden email]>wrote: > Back around 2006, I had a PICStart-Plus connected to a > Debian Linux system but I sort of drifted away from PIC's but > would like to get things going again. > > As a computer user who happens to be blind, I much > rather use text-based development tools. I had good luck with > gpasm and gpsim after getting them installed. > > Since then, I have upgraded to Debian Lenny so the > environment has changed a bit. I am still on the gnupic mailing > list, and it still is alive, but it looks like everybody has > deserted it. > > Basically, are there any new versions of gpasm and gpsim > that can install under debian and talk to the PICStartPlus? > > Is there anything like gcc I can install to write C code > for PIC's? One of the reasons I drifted off was that I realized > that some projects would be much easier under C than they are > under assembler. > > The PICStartPlus worked perfectly the last time I > programmed a 16F84 so I hope I can get it going again and do > some new projects. > Hi. Are you completely blind? Or can you see a *little* bit? -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
In reply to this post by Martin McCormick-2
Byron Jeff writes:
> Martin, > > Two quick recommendations. > > 1) Take a look at JAL. http://www.casadeyork.com/jalv2 > JAL has an active user community, strong library support, and a compiler > that works on Linux. For a good sample check out this trivial USB/serial > system using a 18K1450 and JALs USB libraries: > > http://jallib.blogspot.com/2009/07/pic-18f14k50-usb-interface-board-part-2.html > > JAL is not C. However, it is a high level language that will get your PIC > projects going really quickly. > > 2) Consider upgrading to a PicKit 2. It's USB and Microchip has Linux > support for it using pk2cmd. On the Linux side it doesn't do debugging > IIRC > and also the logic system doesn't work. But it'll program most any PIC and > will run on your Linux box. > > Hope this helps, I appreciate the information. Thanks. Martin -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
In reply to this post by Martin McCormick-2
V G writes:
> Are you completely blind? Or can you see a *little* bit? For all practical purposes, I am completely blind. I use wire wrapping and perphboard for IC projects. By the way, life goes better if you solder the ends of any wires that go to components because the round leads will not bite in to the wire and will gradually loosen with time and unwrap. You will shorts and intermittents. Martin -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
In reply to this post by Martin McCormick-2
> Is there anything like gcc I can install to write C code
> for PIC's? One of the reasons I drifted off was that I realized > that some projects would be much easier under C than they are > under assembler. The C compilers for C30 and C32 are gcc based. At least one of the list members has been involved in taking the source files and getting them to run on Linux. You do loose the Microchip optimization extensions though. In the PIC24 family there are some chips that come in DIP packages if this is a requirement for you to assemble hardware using wirewrap. These use the C30 compiler. -- Scanned by iCritical. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
In reply to this post by Byron Jeff-2
> 2) Consider upgrading to a PicKit 2
My PIC Start Plus gets used occassionally but Microchip have pretty much left it behind. Many/most recent PICs are not supported Also MPLAB now has that 'either programmer or SIM' thing which gets tedious I have 3 of Olin's programmers, which covers every PIC in either ICSP or ZIF, and they work outside of MPLAB http://www.embedinc.com/products/index.htm Joe -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
On Fri, Dec 31, 2010 at 9:43 PM, IVP <[hidden email]> wrote:
> > 2) Consider upgrading to a PicKit 2 > > My PIC Start Plus gets used occassionally but Microchip > have pretty much left it behind. Many/most recent PICs are > not supported > > Also MPLAB now has that 'either programmer or SIM' > thing which gets tedious > > I have 3 of Olin's programmers, which covers every PIC > in either ICSP or ZIF, and they work outside of MPLAB > > http://www.embedinc.com/products/index.htm > > -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
I suppose there are different ways to take this, but I hope you meant it
in jest, as Olin's programmers are better designed than Microchip's. Bob On Fri, 31 Dec 2010 22:13:16 -0500, "V G" said: > How much did he pay you? -- http://www.fastmail.fm - The way an email service should be -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
In reply to this post by ivp
On Fri, Dec 31, 2010 at 09:43:14PM -0500, IVP wrote:
> > 2) Consider upgrading to a PicKit 2 > > My PIC Start Plus gets used occassionally but Microchip > have pretty much left it behind. Many/most recent PICs are > not supported > > Also MPLAB now has that 'either programmer or SIM' > thing which gets tedious > > I have 3 of Olin's programmers, which covers every PIC > in either ICSP or ZIF, and they work outside of MPLAB > > http://www.embedinc.com/products/index.htm Joe, One of Martin's requirements was Linux support. AFAIK, Olin's programmers do not have that. BAJ > > Joe > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist -- Byron A. Jeff Department Chair: IT/CS/CNET College of Information and Mathematical Sciences Clayton State University http://cims.clayton.edu/bjeff -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
> One of Martin's requirements was Linux support. AFAIK, Olin's
> programmers do not have that Ah. I'm probably on shakey ground here, but Olin's can be used with the command line prompt, so would that be a big step to do with Linux ? Joe -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
In reply to this post by Bob Blick-4
> I suppose there are different ways to take this, but I hope you meant
> it in jest, as Olin's programmers are better designed than Microchip's. Damn straight !! Olin knows how to make a programmer -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
In reply to this post by ivp
On Sat, Jan 01, 2011 at 12:56:45AM -0500, IVP wrote:
> > One of Martin's requirements was Linux support. AFAIK, Olin's > > programmers do not have that > > Ah. I'm probably on shakey ground here, but Olin's can be used > with the command line prompt, so would that be a big step to do > with Linux ? Definitely shakey ground. Completely different OS so the software would need to be ported. BAJ > > Joe > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist -- Byron A. Jeff Department Chair: IT/CS/CNET College of Information and Mathematical Sciences Clayton State University http://cims.clayton.edu/bjeff -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Byron Jeff wrote 2011-01-01 07:57:
> On Sat, Jan 01, 2011 at 12:56:45AM -0500, IVP wrote: >>> One of Martin's requirements was Linux support. AFAIK, Olin's >>> programmers do not have that >> >> Ah. I'm probably on shakey ground here, but Olin's can be used >> with the command line prompt, so would that be a big step to do >> with Linux ? > > Definitely shakey ground. Completely different OS so the software would > need to be ported. Or runed using one of the quite common Windows emulators for Linux ? Now, if Olin had written his tools using some more common tool-set then his own Pascal -> C converter, I guess a port to whatever plattform (having a command prompt and a C-compiler) whould have been a bit easier. On the other hand, there are probably enough Windows users "out there" to not give this the highest priority. :-) Jan-Erik. > > BAJ > >> >> Joe >> -- >> http://www.piclist.com PIC/SX FAQ& list archive >> View/change your membership options at >> http://mailman.mit.edu/mailman/listinfo/piclist > http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
In reply to this post by ivp
IVP wrote:
> Ah. I'm probably on shakey ground here, but Olin's can be used > with the command line prompt, so would that be a big step to do > with Linux ? I'm not sure how a Windows emulator running on Linux would deal with the USB device driver. That sounds tricky to me. The low level USB access code is deliberately in a small set of routines designed to be ported, but that's different from it actually having been done. And then the equivalent device driver would need to be created for Linux too. The USBProg can actually be driven via a serial interface. The pads are there for a connector, but it is not installed by default. You would also need a logic level to RS-232 converter is you wanted the USBProg to talk to a PC via a serial port. The host code is all written to a portable layer that has already been to 4 different flavors of Unix, but so far a Linux implementation hasn't been a priority (= paying customer). ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Olin Lathrop wrote:
> IVP wrote: > >> Ah. I'm probably on shakey ground here, but Olin's can be used >> with the command line prompt, so would that be a big step to do >> with Linux ? >> > > I'm not sure how a Windows emulator running on Linux would deal with the USB > device driver. That sounds tricky to me. The low level USB access code is > deliberately in a small set of routines designed to be ported, but that's > different from it actually having been done. And then the equivalent device > driver would need to be created for Linux too. > libusb is quite happy to let apps (running with root privilages) talk to USB devices. > The USBProg can actually be driven via a serial interface. The pads are > there for a connector, but it is not installed by default. You would also > need a logic level to RS-232 converter is you wanted the USBProg to talk to > a PC via a serial port. > > The host code is all written to a portable layer that has already been to 4 > different flavors of Unix, but so far a Linux implementation hasn't been a > priority (= paying customer). > > > ******************************************************************** > Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products > (978) 742-9014. Gold level PIC consultants since 2000. > -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
In reply to this post by Alan Pearce - UKRI STFC
>
> The C compilers for C30 and C32 are gcc based. At least one of the list members has been involved in taking the source files and getting them to run on Linux. You do loose the Microchip optimization extensions though. > > In the PIC24 family there are some chips that come in DIP packages if this is a requirement for you to assemble hardware using wirewrap. These use the C30 compiler. > -- And, there is SDCC, kind of "gcc for small devices". It is not brilliant and you have to get used to it sometimes, but it works for many things. Otherwise, gpasm and gpsim are alive, and you should be able to find most recent versions at their websites or sourceforge. I would recommend getting pickit2, as it works in linux for sure, with pk2cmd tool. It's actually extremely difficult to imagine somebody completely blind playing with electronics, so I think I'm not the only one here wishing you success. And a good year! :) -- KPL -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
On 01/01/2011 15:56, KPL wrote:
> And, there is SDCC, kind of "gcc for small devices". It is not > brilliant and you have to get used to it sometimes, but it works for > many things. > SDCC seems quite useful, but a bit tricky to get started with - just using it to produce code for a soft core 8051 to be run on an Actel FPGA, managed to get there eventually. Comes as part of the Eclipse IDE I think, I intend to give it a try. Not sure if I would recommend it for PICs though as the support for them seems to be still in the early stages of development. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
In reply to this post by Martin McCormick-2
KPL writes:
> Otherwise, gpasm and gpsim are alive, and you should be able to find > most recent versions at their websites or sourceforge. Excellent. I would sure like to still use the stock of older PIC's and the PICStartPlus if I can because they are not exactly land fill material. > I would recommend getting pickit2, as it works in linux for sure, with > pk2cmd tool. That sounds promising, also. > It's actually extremely difficult to imagine somebody completely blind > playing with electronics, so I think I'm not the only one here wishing > you success. And a good year! :) You have to do some things completely differently, obviously. While you could conceivably put schematics in Braille and raised lines, it is not practical because it soon becomes very hard to follow a complex schematic. That, in fact, was why I got interested in PIC's in the first place. You can do a lot with one or two PIC's that would have taken a whole board, printed or wire-wrapped. That way the circuit complexity is in your program which can be documented and managed much more easily. What I do for various IC's is write down the pin-out in Braille after either reading from a text file or having somebody read the pin description if necessary. Most DIP packages have a notch cut between Pin 1 and whatever is the highest pin on the other side. You can usually feel that notch although some chips have a tiny pin prick-like dot and one really has to look for it. I can usually feel those with a tooth pick or the end of a piece of wire. I know some are wondering about getting shocked, etc. I don't like getting shocked or possibly electrocuted any more than anybody else so it is a case of using common sense such as keeping the really hot stuff covered and using an isolation transformer when you can while working on anything that tends to be dangerous such as the primary sides of switching power supplies since most of that circuitry is not isolated from the line. I have a couple of talking multimeters for making measurements and a device that you don't see much called a signal tracer. Mine is early sixties vintage but I have seen solid-state versions of this instrument. It is basically a VTVM with a loud speaker instead of a meter movement. Some have both and the knight-kit signal tracer I have has a tuning eye, sometimes called a "magic eye" tube. This is a vacuum tube with a green circle at the top. With no signal, the circle is open and then it closes when signals are present. Anyway, signal tracers can let you follow an audio signal and they have an RF probe that let you detect signals well in to the VHF range. You can sometimes test it by touching the RF probe and if you hear AM radio stations, the system is working. Finally, a portable AM/FM/SW radio is handy to use as an RF field detector. It is really good on anything with microcontrollers in it because you can listen to the RF hash and sometimes get an idea as to whether anything at all is happening or the device is hung up in never never land. You obviously can't tell what the processor is actually doing, but if you have an interrupt routine that is supposed to run 100 times per second and you hear a buzz that could be in that range, you know it is at least getting that far. Whether it is doing the right thing when it does requires better testing techniques. Well, this has gone pretty far afield so I will end it here for now. Martin McCormick WB5AGZ Stillwater, OK Systems Engineer OSU Information Technology Department Telecommunications Services Group -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
On Mon, Jan 03, 2011 at 09:05:15AM -0500, Martin McCormick wrote:
> KPL writes: > > > Otherwise, gpasm and gpsim are alive, and you should be able to find > > most recent versions at their websites or sourceforge. > > Excellent. I would sure like to still use the stock of > older PIC's and the PICStartPlus if I can because they are not > exactly land fill material. Martin, You may want to take a look around Microchip's current offerings before you make that decision. In short, their current lines especially in the 16F enhanced, the 18F, and the 24F series of chips are fabulous. Consider the 16F1939, which I just sampled, that cost $2.41 in singles from buy.microchip.com: 32 Mhz internal clock 16K words of program memory 1K RAM that can be access both banked and linearly 2 FSR/INDF register pairs with pre/post increment/decrement Extended instruction set with multibyte arithmetic support and true shifts Also added support to eliminate most pesky banking and paging issues EUSART MSSP for I2C and SPI A/D and D/A converters the list just goes on and on. Most importantly the enhanced instruction set much better supports C than the traditional 16F parts. > > > I would recommend getting pickit2, as it works in linux for sure, with > > pk2cmd tool. > > That sounds promising, also. > > > It's actually extremely difficult to imagine somebody completely blind > > playing with electronics, so I think I'm not the only one here wishing > > you success. And a good year! :) > > You have to do some things completely differently, > obviously. While you could conceivably put schematics in Braille > and raised lines, it is not practical because it soon becomes > very hard to follow a complex schematic. That, in fact, was why > I got interested in PIC's in the first place. You can do a lot > with one or two PIC's that would have taken a whole board, > printed or wire-wrapped. That way the circuit complexity is in > your program which can be documented and managed much more > easily. > > What I do for various IC's is write down the pin-out in > Braille after either reading from a text file or having somebody > read the pin description if necessary. Most DIP packages have a > notch cut between Pin 1 and whatever is the highest pin on the > other side. You can usually feel that notch although some chips > have a tiny pin prick-like dot and one really has to look for > it. I can usually feel those with a tooth pick or the end of a > piece of wire. > > I know some are wondering about getting shocked, etc. I > don't like getting shocked or possibly electrocuted any more > than anybody else so it is a case of using common sense such as > keeping the really hot stuff covered and using an isolation > transformer when you can while working on anything that tends to > be dangerous such as the primary sides of switching power > supplies since most of that circuitry is not isolated from the > line. > > I have a couple of talking multimeters for making > measurements and a device that you don't see much called a > signal tracer. Mine is early sixties vintage but I have seen > solid-state versions of this instrument. It is basically a VTVM > with a loud speaker instead of a meter movement. Some have both > and the knight-kit signal tracer I have has a tuning eye, > sometimes called a "magic eye" tube. This is a vacuum tube with > a green circle at the top. With no signal, the circle is open > and then it closes when signals are present. > > Anyway, signal tracers can let you follow an audio > signal and they have an RF probe that let you detect signals > well in to the VHF range. You can sometimes test it by touching > the RF probe and if you hear AM radio stations, the system is > working. > > Finally, a portable AM/FM/SW radio is handy to use as an > RF field detector. It is really good on anything with > microcontrollers in it because you can listen to the RF hash and > sometimes get an idea as to whether anything at all is happening > or the device is hung up in never never land. You obviously > can't tell what the processor is actually doing, but if you have > an interrupt routine that is supposed to run 100 times per > second and you hear a buzz that could be in that range, you know > it is at least getting that far. Whether it is doing the right > thing when it does requires better testing techniques. > > Well, this has gone pretty far afield so I will end it > here for now. Interesting description. Glad you took the time to tell us about it. BAJ > > Martin McCormick WB5AGZ Stillwater, OK > Systems Engineer > OSU Information Technology Department Telecommunications Services Group > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist -- Byron A. Jeff Department Chair: IT/CS/CNET College of Information and Mathematical Sciences Clayton State University http://cims.clayton.edu/bjeff -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Free forum by Nabble | Edit this page |