PIC/Linux

Suppose I want to learn to use a PIC and only have a PC running RH7.1 Linux. In particular, I don't have a PIC development board. I hesitate to get anything until I know exactly what I need and how much it will ultimately cost. If you know exactly what I need to get to do this, and what it will cost, please let me know. I assume I need: (1) A PIC development board. Which one and what will it cost, given that it has to talk to my PC running RH 7.1 Linux? (2) Software, to talk to the PIC development board, that will run on my PC running RH 7.1 Linux. What exactly do I get and from where? (3) Reading materials that will give me certainty of learning to actually use the PIC development board once I have the PIC development board and the software running under RH 7.1 Linux. What exactly do I read and what does it cost?

I am very easily thrown by little details that don't go right, since I don't have time to devote myself completely to solving them. So, I need for this undertaking to be easy and without surprises. Advice such as "read any book for dummies on PIC and make the necessary adjustments for Linux" is likely to lead to failure in my case. Once I've done this once, it will probably be a different story, but I need to suceed in a basic situation and then build on it.

Also, I have very little discretionary capital; that's why I'm using an old PC running RH 7.1 in the first place. So the more inexpensive the solution, the better. (Please don't refer me to ebay, since I can't deal with ebay.)

--
Ignorantly,
Allan Adler 
 Click to see the full signature
Reply to
Allan Adler
Loading thread data ...

Have you tried Googling "PIC on Linux" ?

--
Baron:
Reply to
Baron

have you tried the WINE program for linux ?

--
"I'm never wrong, once i thought i was, but was mistaken"
Real Programmers Do things like this.
 Click to see the full signature
Reply to
Jamie

If you are going to be using microcontrollers, you should become familiar with news:comp.arch.embedded .

With PICs:

formatting link

Reply to
JeffM

Hi Allan,

I dont claim to be any kind of expert, and Im sure someone else have a more experienced answer to this...Im just getting into pics a little too, I am working on a specific project running specific firmware, so I can not suggest any real help for part 3 of your question, however I have built a few pic burner boards from kits.

If you have any soldering skills you can build one very cheaply. Here is one I have built from a kit, it was very easy to assemble:

formatting link

All you will really need is to follow the construction directions on that page, solder the parts on [if you dont know how to solder its not hard and there are a lot of sites with intro information on this]. You will also need to buy a wall wart adapter to suit, a cable to plug it into your PC and some PIC chips themselves. Microchip [the manufacturer] can give you free samples of pics if it is for research for a possible future order, or you can buy them at a lot of electronic stores.

The board accepts a wide variety of pic chips to program and it will plug easily into your pc via the parallel port. It is well documented, there are construction examples, and linux software - see the link at the bottom of the page.

You can buy the kit online from this url:

formatting link

It is the last one on the page and is 13,20 EUR, im sure mike will deliver to USA if thats where you are.

One important thing to know is what pic chip/s you will want to work on, there are a lot. This burner will do two sizes of pic chips, and a massive variety of kinds but im sure not all of them.

Im sure there are millions of sites etc out there on what to do with the pic which you can find, but you will need to have a specific goal in mind, I think the possibilities are endless :}

I hope all this helps you out a bit.

All the best,

John

Allan Adler wrote:

Reply to
dcer10

I have done some soldering. For example, in a thread on this newsgroup on fixing the AC adaptor for my Dell CsX laptop, I managed to repair the damaged cable by soldering it. I've also managed to do some soldering involving components, but I am not very good at it and have a history of destroying components with too much heat. For that reason, I usually prefer to put my chips in special sockets and to solder the sockets. On one occasion I ruined the copper on a printed circuit board by trying to solder something to it. I've been soldering for decades and I don't expect to get much better at it.

Regarding the page you mentioned, I just took a look at it. I'm not yet at the point where I would know why I was building that item. I do have a use for MIDI, though: I have an old Casio CTK 571 keyboard that is supposed to have MIDI capability (but not USB) but which I've never been able to get to talk to any of my PC's. In the case of Linux, that was because the software hadn't been developed and in the case of Windows, which was running on one machine before I installed Linux on it, who knows why it wouldn't talk to the synthesizer, or who wasn't talking to whom?

The page has a note for newbies: "If you are planning to build only a small number of MIOS projects, which are based on the PIC18F452 or PIC18F4620, it's highly recommended to buy (a) preprogrammed PIC(s) from Mike or SmashTV. The MIOS Bootstrap Loader only has to be programmed once into the PIC, you will be able to upload the operating system MIOS, and the applications via MIDI."

Should I ignore this note? If not, when they talk about uploading, are they assuming a Windows environment? These are the kinds of picky details that I tend to get hung up on.

You mean an AC adaptor that plugs into the wall and produces DC current at a certain voltage and with a certain maximum amperage?

Before I would buy this board, I would first have to figure out exactly what chip I would need to buy, exactly where I would buy it, exactly how much I would pay for it, including shipping and handling if it comes to that (does Radio Shack have them?). I can't claim to be doing research. I'm just trying to educate myself.

That flexibility is a good feature, but I wouldn't know which PIC chip I would want or need to use. Having to actually get the project to achieve some goal that I might need done is a huge distraction. I need something more along the lines of programmed play behavior: a bunch of planned activities, not planned by me, which will teach me some basic things I need to know and which I am guaranteed to learn if I follow the very clear instructions. If I have to figure out what I need or what I want to accomplish, it isn't going to happen.

It's good to know that whatever it is, it will plug into the parallel port.

The website says: "Burning under Linux PiKdev is a nice development environment which provides the independent program "pkp" which allows to flash PIC devices from the commandline. The default setup works well with MBHP_BURNER, no additional modifications are required - here my .pkprc file just for documentation: # settings for parallel port device : # (use /dev/parports/x if your system is devfs based) port=/dev/parport0 type=parallel # pin assignments: negative value means inverted signal # the following values are working with MBHP_BURNER vpp=-5 vdd=-4 clock=3 datao=2 datai=10 rw=25 delay=0 "

This file makes sense if one already knows how to use Pikdev and pkp. Pikdev (according to

formatting link
assumes a KDE environment, whereas I have Gnome. But at the bottom, they say: "The programming engine of PiKdev can be used from a non graphical user interface named pkp. pkp has a simple command line interface and can be used by people who do not use KDE or use an old Linux distribution."

When I click on pkp in that quote, I get sent to

formatting link

which says that it assumes one has a GCC 3.2 based distrubtion of Linux. In RH 7.1, which is what I have, the version of GCC is 2.96 (which I'm told officially doesn't exist). So, I don't know whether I can use this Linux software on my system.

I'm not sure which one is the last one on the list since there are a few lists. At the page you mention, if I click on midi-PCB-Sets, a scrolling list appears and there are several MIDIboxes, most of which are at least 26 Euros, but there is one that costs 10,00 EUR, namely the MIDIbox SID, Art.-Nr.: 5005. Maybe it comes to the figure you mention with shipping and handling.

Unfortunately, I'm not yet at the level where I can possibly know that. I don't know anything yet.

I just want to become familiar with the PIC through some successful hands on experience. I have a lot of experience teaching myself things but I know from that experience that planning my own curriculum is a LOT of work. I'm looking for a way to save myself that planning effort, since I don't have time or energy for it right now. I just want to know EXACTLY what to get, both hardware and software, EXACTLY what to read, EXACTLY what to do with it all and EXACTLY what it will all cost, which should be very little.

A bit.

--
Ignorantly,
Allan Adler 
 Click to see the full signature
Reply to
Allan Adler

Thanks for the suggestion. I'll take a look at comp.arch.embedded.

--
Ignorantly,
Allan Adler 
 Click to see the full signature
Reply to
Allan Adler

Thanks, that's an interesting idea. I'll look into it. Even if it doesn't help with this particular problem, it might help with others.

--
Ignorantly,
Allan Adler 
 Click to see the full signature
Reply to
Allan Adler

A quick look for Gnome PIC software has shown:

formatting link
formatting link
formatting link

Best advice I have seen is to avoid ASM and start with C, much easier to get into it.

Bob

Reply to
Bob_

Is there a reason why you choose PICs? Atmel AVR microcontrollers are similar or even a bit better in terms of features, pincount, memory, speed, and they are easier to program. There is a gcc port for AVR controllers (yes, it's the same gcc you'd use on your Redhat system, but this one spills out code for AVR instead of x86). There are free programming tools like avrdude for programming the controllers via their ISP interface. So AVR is a better choice for you.

Start reading here:

formatting link
formatting link
formatting link

Mit freundlichen Grüßen

Frank-Christian Krügel

Reply to
Frank-Christian Kruegel

Not really.

I considered AVR earlier and tried to find some materials on it that didn't assume a Windows environment. The stuff I downloaded contained the following files with no documentation, and also looked BSD specific, so I gave up: AT90CAN128.BSD ATMEGA169.BSD atmega323.bsd ATMEGA329.BSD ATMEGA6490.BSD ATMEGA128.BSD ATMEGA16.BSD ATMEGA3250.BSD atmega32.bsd ATMEGA649.BSD ATMEGA162.BSD ATMEGA2560.BSD ATMEGA325.BSD ATMEGA6450.BSD atmega64.bsd ATMEGA165.BSD ATMEGA2561.BSD ATMEGA3290.BSD ATMEGA645.BSD

Vielen Danke. I looked at these links and will have to read the first and last a few more times before I can get an overview. Meanwhile, I went to the sourceforge link and downloaded everything that I couldn't prove I didn't need, except when there were long sublists of downloads for very specific interfaces, etc. Here is what I wound up with:

cdk-avr-atmelprg-20060228.tgz cdk-avr-ava-0.3b_0815_E.tgz cdk-avr-avarice-2.4.tgz cdk-avr-avra-1.1.1-20060912.tgz cdk-avr-avrctrl-isp-20020506.tgz cdk-avr-avrdis-0.01.tgz cdk-avr-avrp-1.0.tgz cdk-avr-AVRprog-20060215-20060626.tgz cdk-avr-avrprog-pzn-0.2.1.tgz cdk-avr-base-0.5.tgz cdk-avr-base-libconfuse2-devel-2.5.tgz cdk-avr-base-libftdi0-devel-0.7.tgz cdk-avr-binutils-2.16.1-20060708.tgz cdk-avr-cisp-1.0.4.tgz cdk-avr-example-butterfly-0.6.6.tgz cdk-avr-example-simulavr-ddd-1.0-20060709.tgz cdk-avr-gavrasm-2.0-20061001.tgz cdk-avr-gcc-3.4.5-20060708.tgz cdk-avr-gdb-6.4.tgz cdk-avr-geany-0.9-20061001.tgz cdk-avr-jtagice-0.0.3.tgz cdk-avr-libavr-20051024.tgz cdk-avr-libavrhal-20030717.tgz cdk-avr-libc-1.4.4.tgz cdk-avr-picoweb-pppt-20030107.tgz cdk-avr-revava-0.4.tgz cdk-avr-simulavr-0.1.2.2-20060709.tgz cdk-avr-sp12-2.1.0.tgz cdk-avr-tavrasm-1.22.tgz cdk-avr-uisp-20050207.tgz

I didn't download the separate doc files. If it turns out that I need them, I can always go back.

Since I don't possess an AVR and don't know yet exactly what to get, I think I need to try to figure out which of these tgz files to open and explore. For example, cdk-abr-simulavr-0.1.2.2-20060709.tgz, by its name, sounds as though it will let me simulate the AVR without actually having one.

The third link, to tuxgraphics.org, is fairly specific about binutils-2.15, while I have binutils-2.10, and gcc-core-3.42, while I have gcc-2.96. So, I'm not sure yet what ought to work on my RH 7.1 Linux PC. They also sell some hardware at various prices in Euros, any one of which might represent approximately the total of what I'm prepared to spend on hardware for this learning experience, and I don't know how many items I might actually need. I do know that I can't buy anything until I have very detailed knowledge of exactly what I will need in the way of hardware, software, documentation and other educational materials.

--
Ignorantly,
Allan Adler 
 Click to see the full signature
Reply to
Allan Adler

I've downloaded what looked appropriate, except for GTK+ and the stuff that goes with it (pango,...) and stuff that required me to make sense of the New Site window that popped up. Here is what I have now:

gpsim-0.21.11.tar.gz gtk+extra-2.1.1.tar.gz sdcc-src-2.6.0.tar.gz gputils-0.10.0.tar.gz libscigraphica-2.1.1.tar.gz

Actually, I'm still downloading the sdcc. It's taken almost 4 hours to download this stuff and the stuff at the AVR websites on a 56K dialup. I have about 15 minutes before my ISP's 4 hour online limit kicks in, so sdcc is in a race against time. It's 43 percent downloaded... 48...

59... 70... 80... 90... 100 with 7 minutes to spare...

Now I just have to make sense of all these packages.

I do know how to program in C. I've always been very bad at it but recently I seem to have gotten a lot better. So maybe I can do it that way.

--
Ignorantly,
Allan Adler 
 Click to see the full signature
Reply to
Allan Adler

These files are BSDL files for chip testing (boundary scan description list) and have no relation to BSD Unix.

Exactly.

You've got gcc-2.96 for x86. For AVR programming you'll need tools for AVR. So just do what they write, download these files and compile them.

I guess you are not very familiar with the Linux/Unix development environment. This would help you in getting started with AVR, since the tools are basically the same.

Mit freundlichen Grüßen

Frank-Christian Krügel

Reply to
Frank-Christian Kruegel

Frank-Christian Kruegel writes:

On 10 Nov 2006 00:00:59 -0500, Allan Adler wrote:

That's encouraging. I have now untarred it and learned that, even if it can run without an AVR, it apparently can't run without the rest of the software. Now that I have a lot of the packages, I'm going back and trying to download some of the documentation. Some of it is in German and I've made an attempt to read it. Ich spreche jetzt sehr schlecht Deutsch, aber ich kann es sehr langsam lesen. Dass is sehr gut weil es is besser die Dokumentation langsam zu lesen. I don't normally have the patience to do so in English.

OK, the first thing they say to do is:

mkdir /usr/local/avr mkdir /usr/local/avr/bin export PATH=/usr/local/avr/bin:${PATH}

I'm very picky about what I install on my machine and where I install it. When I'm installing something like this, I prefer to keep it in my user directories, instead of on the system as a whole. That makes it a lot easier for me to back up my system and also a lot easier for me to remove it in case I decide I don't like having it. (The other link having directions

formatting link
seems to agree with the tuxgraphics site on this point.)

So, I'm going to pretend they didn't tell me to do that, but I'll keep in mind that I may eventually need to create some directories and put one of them in my path.

Now let's look at the GNUbinutils instructions:

tar jxvf binutils-2.15.tar.bz2 cd binutils-2.15/ mkdir obj-avr cd obj-avr ../configure --target=avr --prefix=/usr/local/avr --disable-nls make

# as root: make install

Since I'm going to put this in my private directories, I won't need to be root to do the installation. Also, I downloaded the tgz version of binutils, not the tar.bz2 version. So I have to do this differently from what they say to do. Actually, I don't know where the directory binutils-2.15 is supposed to live. I guess I can put it wherever I like. I'll just stick it in my directory ~/AVR/LINUX as /AVR/LINUX/binutils-2.15. Now, where is the varmint? Actually, it was cdk-avr-binutils-2.16.1-20060708.tgz and when I untarred it in ~/AVR/LINUX it created various subdirectories of ~/AVR/LINUX/opt and that is consistent with that the second link:

formatting link
(which is where I downloaded all the stuff from) said would happen. So, maybe I don't need to create anything even remotely resembling a binutils-2.15 directory. But let's see: I'm still trying to follow the 3rd link:
formatting link
and it does have something to say about creating a subdirectory of the binutils-2.15 I was supposed to create and cd'ing to it in order to run configure and make. So, where should I go? Well, probably to wherever the configure program is, i.e. in .. of the mythical directory obj-avr, which was created as a subdirectory of the mythical directory binutiles-2.15, i.e. configure should be in the directory binutils-2.15. Wherever it is, since I untarred the file cdk-avr-binutils-2.16.1-20060708.tgz in the directory ~/AVR/LINUX, this file configure which I'm going to execute as ./configure ought to be in *some* subdirectory of ~/AVR/LINUX. But when I execute ls -R | grep configure in ~/AVR/LINUX there is no mention of any such file named configure. So, it appears that I can't take the next step and I would not have been able to take this next step even if I had untarred the file inside some subdirectory of /usr/local/avr or some other subdirectory of /usr. And then I would have had a mess to clean up, so now I'm really glad I didn't follow the directions blindly.

Actually, a lot of the files that have turned up in subdirectories of ~/AVR/LINUX/opt have turned out to be executables. So, maybe there is no make process involved. Maybe what I have downloaded is binaries and I just have to use them. For example, from the simulavr package, I wound up with three files in the subdirectory ~/AVR/LINUX/opt/cdk4avr/bin, namely simulavr simulavr-disp simulavr-vcd and I was able to run them, except for not having anything else that they needed to run. So, I'm going to proceed on the theory that I should ignore most of the instructions I find on the pages:

formatting link
formatting link
even though their selection of topics is probably quite useful. The problem is that the 3 pages contradict each other in fundamental ways, but I now have some sense of what to believe and what to disregard.

After I've experimented with this for a while, I'll have a better idea of what I know, what I don't know, when I knew it and what I wish I had known. As that process can be quite verbose, and not very interesting, I'll stop reporting on it until I have something more definite to say.

I'm certainly not an expert on Linux/Unix, but I'm not as feeble as I seem to have made you think. It's more accurate to say that I'm not extremely good at guessing what is going on by reading the names of the distribution tgz files instead of the documentation. In particular, I don't know yet which files refer to the target machine and which refer to my x86 but I expect to know soon.

--
Ignorantly,
Allan Adler 
 Click to see the full signature
Reply to
Allan Adler

Well, I've been trying and have had some interesting experiences. As I guessed, what I have, after unpacking all of the tgz files, is a collection of binaries and some documentation, shell scripts, etc., but nothing that needs to be made. The binaries work well enough to tell me they can't find things and then give up. I don't know yet how to tell them where to find the things they say they can't find (e.g. versions of lib.so.6 or whatever it was) and GLIB3.2, etc. I tried to download documentation from the sourceforge site but there is not always documentation available from there. My browser doesn't support whatever is at some of the sites that sourceforge does link to, i.e. the sites of whoever wrote the software, so there may very well be some documentation there that I can't find.

Here is one of the more positive experiences so far: I managed to get simulavr-ddd to work to some extent, but not really. I ran run-simulavr-ddd and got a complaint that it couldn't find simulavr. So, I made a back up copy of run-simulavr-ddd and then edited the original so that it could find simulavr. That caused a window to open but it couldn't be used for simulavr because I hadn't told it where to find simulavr-disp. It could, however, be used as a terminal window, which I closed. I modified it again to tell it where simulavr-disp is and this time the window opened and closed very quickly. Apparently, whatever port or device or socket it was trying to access was busy.

Anyway, I decided it would be helpful to look at the source code for the various packages, which has to be completely accurate about what the program is supposed to do and under what conditions, unlike the more optimistic opinions often expressed in documentation. I returned to sourceforge and downloaded the base-0.5 rpm. I don't like rpm files since they don't give me enough control over where the files wind up and because I don't like to do things as root unless I know exactly what I am doing and why. So, I used rpm2cpio to convert the rpm file to a cpio file and then tried to use cpio --extract to extract the contents of the cpio file. Unfortunately, cpio just hung and I don't know why. It would be much better if there were also a tgz file that contained the source code, instead of a dreimal verdammt rpm file. I didn't see one listed at sourceforge. If there is one available, I'd like to know about it.

It is probably not a good sign that I am now thinking of reading the source code to these dozens of programs in order to find out how to use them. As I mentioned in my original posting and in at least one follow up posting, I tend to be easily thrown by little details and wind up in very strange places, and this is a good example of how that happens. The way I read source code, since I'm not very good at it, is to try to convert the source code (if it's in C) to a literate document written in CWEB. I've done this with a Go playing program and am now revising the CWEB file. It took quite a long time but I now understand thoroughly how the program works. Unfortunately, I have several programs I am already trying to study by this extremely labor intensive method and they have much higher priority than AVR, which I was hoping would not be very distracting from my research and other projects.

If I have to work this hard at it, it probably isn't going to happen.

--
Ignorantly,
Allan Adler 
 Click to see the full signature
Reply to
Allan Adler

I would avoid buying a development kit. If you use e.g. a PIC16F84A, then I have had success plugging those into a "solderless breadboard" (white things, about two inches by six inches and quarter inch thick, that have an array of little holes in them connected together in groups of five.) Just make sure that you put a decoupling cap very close to the PIC, and keep the wiring of the crystal oscillator absolutely as short as you can to minimise capacitance.

To program it I used something based on this schematic: ftp://ftp.armory.com/pub/user/rstevew/PIC/DaveTait/pp.gif I had to add some small resistors (1kOhm) in series with the data lines from the printer port and small capacitors to ground (1nF) as a filter on these lines because I was getting glitches due to coupling between the wires of the printer cable, but if you use a very short cable then that may not be a problem for you.

I can highly recommend the PIC C compiler from HiTech, of which there is a free (but closed source) version for Linux, (though I only used the DOS one many years ago):

formatting link

In the end I became a bit frustrated with the small amount of RAM on these old PIC chips and I will one day have to get around to figuring out how to use something with more memory (but hopefully not too many pins - I don't want to have to make a PCB for very project I undertake.)

Chris

Reply to
Chris Jones

OK, thanks.

OK, I've downloaded the schematic.

I haven't figured out how to download it. I clicked on the thing for HI-TECH PICC-Lite and found information on the differences between it and the full non-free version, but I didn't find any way to actually download it.

Since my Linux systems are so old and so unprepared for the other free PIC software I've found for LINUX, I'm wondering whether I might be better off trying to use the FREEDOS partition I have on one of my machines.

--
Ignorantly,
Allan Adler 
 Click to see the full signature
Reply to
Allan Adler

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.