Learning PIC

[navkan]

Hi folks, I'm a new member who has re-entered model flying after many years out of the hobby. My interest is electrics and I was gratified to see how electric technology has advanced since the 80s. In addition, I told my wife who has encouraged me in this hobby, that she has created a monster, since her electrical engineer husband has also discovered that the world of DIY has greatly expanded, especially with the availability of microcontrollers. That is exciting to me. I live in Ottawa where the flying season is short and the winters long. There is plently of time for DIY projects.

Enough rambling. I want to learn to use PICs. There is lots of stuff on the net but I would like some advice from any of you PIC-knowledgable modelers.

I"m not a programmer so I would like to avoid assemby language or a complex hol like C. PICBASIC (not the pro version) looks like a good answer. I am leaning towards a high capability processor like the 18F452 to learn on. I need to identify debugging tools and a programmer. Most of all, I would like to identify a good, comprehensive textbook to assist my learning.

I would appreciate any and all adivice and suggestions!

cheers, Fred

[hbsloper]

I am also a EE who works with ASICs. I found the PICs to be pretty easy to learn and the assembly is probably as easy as it gets since only 35 instructions in the set and works across the whole line of parts. Get a copy of MPLAB 6.0 from the microchip site and start simulating the example programs you get from APP notes or from here. Most of the good stuff is in assembly which is efficient and usually simpler than a higher level language. It took me awhile to learn enough to write my own programs but now I actually like the Assembly level its gets you closer to the hardware.

Steve

[Ironsides]

Fred:

I documented my learning curve:

http://www.rc-float-flying.rchomepage.com/RCWeb/PIC/PIC.htm

David

[Comatose]

I'd argue that C isn't, or at least doesn't have to be any more complex than basic.

I'd offer than for most needs (especially needs here) the pic18f1320/2320/4320 series is a better fit than the 452.

You can't go wrong with a warp-13a for a programmer. www.newfoundelectronics.com

[Cats Eyes]

From Ottawa, eh? Me too! What club are you in (if any)? Ever hear of OREO (http://www3.sympatico.ca/rwoolley/list.htm)?

I started in PICs about a year ago. I'm glad I did, it's amazing the functionality you can pack into these small, cheap devices. They seem very well suited to aeromodelling as we generally use 5 volts to power onboard electronics, and the PWM signals used by the RX, servos and ESCs are easy to decode/encode with a PIC.

In fact, in the long, cold Ottawa winter I completed not one, but two PIC-based projects, one a camera shutter switch and the other a "tilt" controller for a camera tilt platform. Just tried them out this Saturday, see this thread: Photos: Central Experimental Farm, Ottawa, ON, Canada (http://www.rcgroups.com/forums/showthread.php?threadid=217210). I think PICs are a very worthwhile thing to look into for anyone with the time to devote to it.

There's certainly some argument about whether it's better to start with assembler or a high-level language. I'm a programmer by profession, so it was fairly easy for me to pick up the assembler. I basically started from the ground up, learned about the hardware first, then the memory mapping, then the assembler instruction set. I recommended this route to Ironsides, but, being a non-programmer, he had a tough time with it. He seems to be making great strides now after abandoning the idea of starting with assembler and starting with PicBasic instead. I can see this being a wise route for a non-programmer. You can always get into the assembler later, once you have a general understanding.

I can't help you with a textbook recommendation; I learned it all from the datasheets I downloaded from Microchip (http://www.microchip.com/). But here are a few on-line resources.

Starting with PICmicro controllers (http://www.voti.nl/swp/)
MPLAB (http://www.microchip.com/1010/pline/tools/picmicro/devenv/mplabi/index.htm)
The official PICList home page (http://www.piclist.com/)
IC-Prog Prototype Programmer (http://www.ic-prog.com/)
Digi-Key (http://canada.digikey.com/) (Canadian). (Forget Active, they don't have much in the way of PICs!)

Good luck!

-- Kevin

[niklas]

If I was in your position I would ditch the Basic approach and go for assembler (or possibly c). As someone said assembler isn't very hard to learn, and I think you get much more out of your processor with assembler.

This is why I think so:
Every year I supervise a few groups of students in an electronics projects course. The students are in their third year of a degree of master of science in engineering. Their background and interests vary (they will major in one of several subjects, like electronics, mathematics, physics, socware) but (almost) everyone successfully learns to program the PIC and/or Atmel AVR in assembler. The grand total is about 300 students learning how to program the PIC or AVR in assembler per year. So what wonderful tools and book are they using?

1) Datasheets
2) MPLAB/AVRStudio
3) Application notes
4) Good(?) advice from their supervisors (among others, yours truly...:cool: )
5) A lot of practice

They get to choose from PIC16F87x and ATmega8 & 16. My experience is that the PIC is somewhat easier for the complete beginner. Well, I could go on forever on this education matter but here is the bottom line(s):

Pick a processor and the necesarry tools, get the complete datasheets some app.notes. Hook some LEDs and buttons to the processor and experiment. Remember, I see 300 students develop good assembler skills in about 6-7 weeks with no special books or tricks. And they have no general engineering experience.

Also find someone experienced to pester with questions...

Thats my $0.02

//niklas

[OmegaDot]

I found a book in a college bookstore, by Mike Predko (spelling?), that was a general intro to PIC controllers. In the book was a bare PCB for a programmer called the "ElCheao". This hangs on a printer port. I populated the board for about $10 (I did have to do some debug because my NEC computer port had strange pull up behavior. I added a couple of transistors to buffer). Book also has CD with source and hex code for example projects.

I find MPLab / MPASM to be quite easy to use and the Microchip documentation is very good. If your EE experience involved digital logic, then I think assembler will come to you easily. What's the hardware guy's phrase... "I program in solder".

If you have an initial project in mind, you might select your chip based on hardware needs. Other than that, use a flash version, so you don't need an eraser. I used 16F84 and 16F628 so far.

[Cats Eyes]

Originally posted by OmegaDot
I found a book in a college bookstore, by Mike Predko (spelling?), that was a general intro to PIC controllers. In the book was a bare PCB for a programmer called the "ElCheao".Myke Predko. See El Cheapo PICmicro Programmer (http://www.myke.com/elcheapo.htm). Works with the IC-Prog Prototype Programmer (http://www.ic-prog.com/). David (Ironsides) put one together and got it working. I think he's now using a programmer from Microchip.

And, as OmegaDot says, be sure the chip you choose is flash programmable!

-- Kevin

[navkan]

Thanks to everyone for the great information and suggestions. Much appreciated. I will definitely re-consider my decision not to use assembly language

Kevin, I sent you a private message

Fred

[BGR]

I have a PIC Start kit at work that I use to program station controllers for automated assembly machines. I use the larger chips but the programming is probably similar to the smaller chips. The documentation for the chips and the software to program them is massive. At first it seems daunting but if you take the time to read the important parts like setting up the I/O, register usage, timer usage and the commands, you can control just about anything you want.

The decision between Assembler or a High Level Language depends on how much you want to sacrifice in time and effort. It will take time to learn both, but more so with the Assembly language. However there is a trade off, the higher level language may not be able to perform everything you want the chip to do and it may create a somewhat larger and slower program than if you use Assembler. You could find yourself running out of memory before your program is finished.

[Comatose]

BGR, thats half of it. The other half is that even if you know asembler really well, someone equally trained in C will get the code finished faster. In terms of running out of ram/flash, they's 90% an issue of proper design and 10% an issue of the language used. You can even get compactish programs out of a bacis compiler if you're careful.

Try assembler. Its truely great advantage is thats its free. If its not your thing, then before you give up on PICs as too hard, try a higher level language.

[AndyKunz]

If you use the Hitech compilers, they will regularly beat a GOOD programmer on both code and RAM space used.

Andy

[BGR]

BGR, thats half of it. The other half is that even if you know asembler really well, someone equally trained in C will get the code finished faster.

Yup, for commercial purposes where time is money. But for hobby purposes time is not as important.

High level languages have a tendancy to plop flexible functions into the code. These functions are often designed to deal with a wider variety of input and therefore take up more chip space. This is probably not an issue if your programming 1 or 2 simple functions.

[Texy]

I,d agree with what everyone has said so far.
Personally, I went for the assembler route. However, if there was
a popular free (and unrestricted) picbasic, then I would have gone
that routed, probably. Basic was my first high level language, and
although, it gets a lot of knocks, can be made to do whatever you want.
I built my own comm port programmer initially, and used IC-PROG programming
software. The programmer I made from parts from mym junk box, and the
software was free. I used MPLAB of course to develop my code (also free).
My problem was that I kept blowing up my PIC's (16f84, 16f628's), and I decided to look out for a Microchip programmer. I wasn't too sure if it was handling, or my homebuilt programmer killing my chips. I ended up with a Pictstart+ from ebay. The main advantage with a programmer from microchip is that mplab drives it directly - this makes the whole development cycle much cleaner and easier. I was also lucky enough to get hold of a number of faulty microchip In Circuit Debuggers (ICD2's), and fix some of them, although
I,ve not used them for developement yet.
For any of you thinking of getting into PIC's I say "go for it".
Just use google and search for pic tutorial - there's lots of info out there!
Texy

[Cats Eyes]

If you use the Hitech compilers, they will regularly beat a GOOD programmer on both code and RAM space used.
Is this the compiler you mean?

http://www.htsoft.com/products/piclite/index.html

Good price (i.e. free). Has anyone used this and is it good?

-- Kevin

[niklas]

Programmers: I think the PicStart+ is so ¤#¤#%¤ slow I try to avoid it :mad: . For the PIC16F87 series I use a bootloader instead. If a Picstart+ is free or almost free I'll get it, otherwise, no way!

BUT: I have to admit they are robust. We have several and all of them are OK (with som upgrades) after several years of abuse (students...).

//niklas

[AndyKunz]

It's a very good compiler, however (don't you hate those?)

The free version doesn't have the optimizer that makes it work good for packing the code down. If you use software loops, they will run much slower than if you had the optimizer installed. Also, it doesn't let you link stuff together as nicely.

I use the full-blown one ($800) for my stuff, but then it's how I make a living so I had no problem buying the best tool for the job. I've been using it since before it was a released product.

Andy

[Texy]

Programmers: I think the PicStart+ is so ¤#¤#%¤ slow I try to avoid it :mad: . For the PIC16F87 series I use a bootloader instead. If a Picstart+ is free or almost free I'll get it, otherwise, no way!

BUT: I have to admit they are robust. We have several and all of them are OK (with som upgrades) after several years of abuse (students...).

//niklas

Well its not going to be slower than any other comm port programmer - and you still can't beat the mplab intergration. Also, to speed up programming, you only have to program to the end of the code, not the whole pic.
However, I agree that USB is the way to go - my pickit1 and ICD2 USB are considerably quicker at programming.
Texy

[Cats Eyes]

It's a very good compiler, however (don't you hate those?)

The free version doesn't have the optimizer that makes it work good for packing the code down. If you use software loops, they will run much slower than if you had the optimizer installed. Also, it doesn't let you link stuff together as nicely.

I use the full-blown one ($800) for my stuff, but then it's how I make a living so I had no problem buying the best tool for the job. I've been using it since before it was a released product.
Thanks for the input, Andy. No, I will not be buying an $800 compiler for hobby work! :eek: I think I'll probably be able to live without an optimizer, since I have yet to even come close to filling up the code space. And I find most of the time the PIC is waiting for something to happen, so I don't care too much how fast it runs.

However (there it is again!)

I want to make sure I can embed assembler for critical stuff, like interrupt handlers for instance. Will the free version allow embedded assembler?

Now, about the linking stuff... I assume that's just if you want to use third-party libraries or if you've developed your own code libraries. I'm assuming that I won't need that if I have all the source in one file (cut and paste anything I need from old code). Is that correct?

-- Kevin

[AndyKunz]

I'm pretty sure it will. Use

#asm
Your assembly code here
#endasm

or asm ("your assembly here");

Both should work fine for you.

Andy

[Cats Eyes]

I'm pretty sure it will. Use

#asm
Your assembly code here
#endasm

or asm ("your assembly here");

Both should work fine for you.
I just looked at the user's manual, and in-line assembly is supported, just like your sample. Looks like you can also write assembler subroutines and link them in. Looks very nice all around. :cool:

I guess you've convinced me to try it. Now I have to upgrade to MPLAB 6.41... which means I'll have to upgrade Windoze to SP4... :( It never ends!

Thanks for your input.

-- Kevin

[Comatose]

Well its not going to be slower than any other comm port programmer - and you still can't beat the mplab intergration. Also, to speed up programming, you only have to program to the end of the code, not the whole pic.
However, I agree that USB is the way to go - my pickit1 and ICD2 USB are considerably quicker at programming.
Texy


But see, that's jsut not true. The picstart is MUCH slower than the serial warp-13a. Much like up to 5 times slower. The warp-13a can operate as a (cheaper, faster) picstart clone as well, so you get full MPlab compatibility.

Lets not kid ourselves. We're talking about putting a few Kb onto the PIC, and that takes at least a minute with the picstart. That's about 300 baud. RS-232 at up to 115200 bps is not the bottleneck, so the only real advantage of going to USB is future-proofing yourself, and there are some gains to be had for ICD.

[joe@tech-mp]

I have used the HITEC PICC Lite compiler for the 16f628 and the 12f675 parts and it works great. This is the way to write fast tight code especially if you need to do signed arithmetic. The compiler handles 16 and 32 math with ease. Why bother trying to do it with assembly code? This compiler has an outstanding optimizer (Lite version) that will blow away the best assembly programmers out there. It will generate code tighter and more efficient than any human could overall. I found the PICSTART programmer to be a good value. These parts have a code space of just a few Kbytes. It only takes 30 seconds to program a part. What is the big deal.
I found the MPLAB simulator to be a great help. It models most of the peripheral devices in the chip.

Joe

[BGR]

I agree with all of what your saying Joe except for it will blow a human away. A human wrote the routines that the compiler uses. :D

[AndyKunz]

I used to say the same thing. "No computer is going to beat my assembly." That might be OK at the start of a compiler's life cycle, but a compiler gets to choose the best optimization from the input of literally hundreds of programmers and can be continually refined to make the better choice each revision.

Even the best programmers have to write code that they can fix in a year - the compiler doesn't have that constraint. It only needs to get the right answer out - the technique to accomplish that may change radically.

In the 8-10 years I've been using the Hitech PIC compiler, I've seen the optimizer get better and better. As soon as you graduate from blinking LEDs to doing real work, the compiler wins. The only time it won't is when you have to do two things at once, such as an ESC measuring incoming pulse while generating outgoing pulse at a different frequency.

Andy

[peterbennett26]

There are some webpages on Pic programming where the guy has his own Pascal like programming language. On these pages he mentions that for some devices a bootloader is normally needed, or another pre-programmed PIC. Under what situations is a bootloader needed? Is there a freeware bootloader somewhere? Is it possible to write your own bootloader?

I was under the (perhaps mistaken?) impression that you built a programmer from one of the many designs, then used the program from microchip to program the assembly language on to the chip. The original program would probably be a commented assembly program file and the microchip software would also produce a hex file from this, which the microchip software can put straight on to the chip.

Another question ;- Is the hex file like an exe in that you can not get back to the original assembly code?

Thanks,

Pete

[joe@tech-mp]

Generally, a compiler or programmer (person) generates the assemebly source code. This gets assembled by an assembler to produce an object code file (.obj) which contains the processor opcodes. The object code file(s) then get linked by a linker to produce the final hex file. The hex file is a text file that contains all the opcodes from the object file(s) as well as address information for programming. There is a one to one correspodence between the assembly code, object code, and the hex file.

Object files and hex files can be disassembled to produce uncommented assembly code.

Joe

[Texy]

A bootloader is a method of a pic programming itself, rather than using external hardware to provide
the voltage levels required. It would be useful, for instance, to re-program surface mount chips that
are already 'in the field'. You still need to connect the pic to an external pc that would supply the new code,
running suitable software.

The pascal like software is 'JAL' perhaps?

Yes, you are correct about the hex file, although of course, the hex file can be disassembled (painfull).

Texy

[Cats Eyes]

This compiler [HITEC PICC Lite] has an outstanding optimizer (Lite version) that will blow away the best assembly programmers out there.
Now I'm confused. You say the Lite version has an optimizer?!? AndyKunz said it does not. Or are you talking about something different? Please clarify. :confused:

-- Kevin

[joe@tech-mp]

Hi Kevin,

Yes, the PICC lite compiler has all of the features of the full version of the compiler including the optimizer.

Differences from the full versions are: there is no source code supplied for the library routines; the compiler comes with no printf() support for longs or floats; two ram banks of the 16F627, 16F877, 16F877A are supported for general purpose ram; Code size for the 16F877 and 16F877A is limited to 2048 words.


Joe

[AndyKunz]

Just checked the site. Well what do you know, Clyde's shipping the optimizer now!!! That's fantastic!

Sometimes it's good to be wrong!

Andy

[MAVA]

To All,

Not to take you off course.., but what do you tell someone that just..can not get the whole programming thing..

Yet very very intimate with electronics!! Can fix and design just about anything.

What real path do you recomend in learning PIC or AVR programming?

Any one can chime in.

Thank you,

Martin

[joe@tech-mp]

Hi Martin,

Asking questions is a good start. What would you like to do? Set the goal and I am sure this forum can help you know how to get there.

Joe

[BGR]

To All,

Not to take you off course.., but what do you tell someone that just..can not get the whole programming thing..

Yet very very intimate with electronics!! Can fix and design just about anything.

What real path do you recomend in learning PIC or AVR programming?

Any one can chime in.

Thank you,

Martin

Lost of people dont get it because they have some pre conceived notions that are blinding them. Some people see it as more complicated than it is. Others do not have a grasp on how a computer executes a program.

To teach these people programming one must discover where the weaknesses are and correct them before you can teach them the basics.

[Cats Eyes]

Not to take you off course...
LOL. Well I think I kind of hijacked this thread for a while, so your turn now. :)

Thanks to Andy and Joe and everyone for all your help. :D

-- Kevin

[MAVA]

Cat Eyes,

As someone said it takes time to evolve the programming thing, but you must have the time to give it..

I do not have time to devote to it right now, my week day is consumed from 7:00am to 9:30pm(non-stop). This is ending soon-this is my first handicap.

What do I want to design? Well I am being thrown into the sharks very soon(next several months).
I will be "asked" to design a multiple analog input device to interface to a low data rate satellite tranceiver. The Satallite tranciever is made by a company in ottawa(I have been there, but I will be there next month).

I know I need to start small by making like a RC switch, RX decoder and etc.

It is funny, but when I was in(18 years ago) school I got good with 8088 ,BASIC and Fortran. Must have realy lost those Brain cells.
It just does not "click" at all...now

This is not my first attemp at the PIC stuff.

Now for me the "Rubber will Meet the Road" this go around and I know there will be all kinds of "Mud Pies" in the process.

Enough said

Thank you,

Martin

[MAVA]

Joe@temp-mp,BGR & CatEyes,

Thank you,

I will use this form for help, but first I need give up some time in my day.
The time will come in June.

Martin

[peterbennett26]

Thanks Joe,

Your description of the programming procedure is the same as that I have used in the past for fortran programs. If I remember correctly the linking step ties in to the new program all the called library routines.

Thanks again

Pete

[GeneSS]

I need some basic help with PIC's. I am a EE with 35 years experience. I am the IT guy at our company. I also fly RC and have just recently gotten interested in Pics. I bought the PICkit 1 from Microchip which come with the 12F675. All the demo tutorials work fine, but none of my code works. I suspect that my header and configuration may be incorrect. The PICkit has the Leds wired from pin to pin and not pin to gnd or Vcc to pin. I would like some very basic code that just simply turns one of the LEDs on the board, D0 - D7, on and stays on. Seems very simple, but I am obviously missing something. All of the tutorial asm's are way too big and complicated to start out with. My code assembles and compiles to a hex file, but when I burn it, it doesn't do anything at all.

If any of you kind souls could furnish me with some "good" code for the 12F675 with the proper header and configuration lines, I would be eternally greatful.

[Comatose]

GeneSS, if you're connected pin to pin, you have to configure both as outputs, then drive one high and one low. That will turn on the LED.

[joe@tech-mp]

Hi GeneSS,

The 12F675 is a great part. I have used it for several projects. The PICC Lite C compiler supports this part. I would recommend that you download and install it http://www.htsoft.com. I could then send you an initialization include file and a simple LED blinker program written in C.

Joe

[Texy]

I need some basic help with PIC's. I am a EE with 35 years experience. I am the IT guy at our company. I also fly RC and have just recently gotten interested in Pics. I bought the PICkit 1 from Microchip which come with the 12F675. All the demo tutorials work fine, but none of my code works. I suspect that my header and configuration may be incorrect. The PICkit has the Leds wired from pin to pin and not pin to gnd or Vcc to pin. I would like some very basic code that just simply turns one of the LEDs on the board, D0 - D7, on and stays on. Seems very simple, but I am obviously missing something. All of the tutorial asm's are way too big and complicated to start out with. My code assembles and compiles to a hex file, but when I burn it, it doesn't do anything at all.

If any of you kind souls could furnish me with some "good" code for the 12F675 with the proper header and configuration lines, I would be eternally greatful.

I,ve got a pickit1 as well. The way that the LED's is wired does make things complicated for pic beginers, but the reason is a simple one. Due to the limited i/o pin's of the 12f675 they decided to drive 8 LED's from 4 I/O lines.
Then its just a question of applying the correct logic level to 2 of the appropriate pins to light the LED. If you reverse the levels on those 2 pins a different LED will light. Take a look at the schematic to see which 2 I/O lines
connect to each LED pair.
Texy

[Cats Eyes]

If any of you kind souls could furnish me with some "good" code for the 12F675 with the proper header and configuration lines, I would be eternally greatful.
OK, let's give this a whirl... :)

I'm assuming here you're using MPLAB.

For the configuration section, I usually include this:

; ===== CONFIGURATION =====
list P=12f675 ; Define processor
#include <P12F675.inc> ; Processor specific definitions
errorlevel -302 ; Suppress message 302
radix dec ; Everything in decimal
; unless otherwise indicated


This ensures the processor is set up properly and includes all the names of file registers
and bits etc.

Make sure the configuration word is set up properly, for example:

; ===================
; Configuration word has the following values set:
; (See section 9.1, page 52)
; * Data protect off
; * Code protect off
; * Brown-out reset enabled
; * No MCLR pin function
; * Power-up Timer enabled
; * Watchdog Timer disabled
; * Oscillator is INTOSC with no CLKOUT
__config _CPD_OFF & _CP_OFF & _BODEN_ON & _MCLRE_OFF & _PWRTE_ON & _WDT_OFF & _INTRC_OSC_NOCLKOUT


A bizarre (to my mind) "feature" of the 12F629/675 is that by default the comparitor module is enabled. This means GP0 and GP1 are unavailable for digital I/O (e.g. to light an LED). To disable the comparitor module, use:

; Disable comparitor module
movlw B'00000111' ; Set GP<2:0> to digital I/O
movwf CMCON


As Comatose mentioned, you'll have to configure the pins you are using as outputs. Since all you're trying to do is light an LED, you can make them all outputs by:

bsf STATUS, RP0 ; Bank 1
clrf TRISIO
bcf STATUS, RP0 ; Bank 0

Note that TRISIO is in bank 1, not bank 0, so to set it you have to set the bank bit. And don't forget to set it back afterwards!

I can't help you as to which lines (i.e. which GPIO bits) have to be set to what, since I don't have the pickit1. Hopefully you got that one figured out. It might help is to use MPLAB's simulator to debug your code. From the menu, select Debugger -> Select Tool -> MPLAB SIM. Make sure you are displaying the special function registers. From the menu, select View -> Special function registers. Then step through your code and when you execute the instruction to light the LED, the corresponding bit in the GPIO register should switch to a "1" or a "0" as required. If it does not, something's wrong and there's no point burning it to the PIC 'cause she ain't gonna work. (Note that GP3 is always an input, so you can't set it to a "1" in GPIO.)

Another thing to watch is if you are setting the OSCCAL value. This is stored in location 3FF and is a retlw instruction. To load this value you would execute a call to 3FF and save the returned value to the OSCCAL register. However, if there is no retlw at location 3FF (it's not in your code and your programmer does not carry it over properly), you're screwed (the technical term). I would suggest to start with, if you have the call instruction to 3FF in you're code, just remove it. Unless you're doing something very timing-critical, you don't need it.

Hope some of this helps. If not, why don't you post your code here and we can pore over it and let you know what you did wrong?

-- Kevin

[GeneSS]

Guys, especially Cats Eyes, thanks for all the help. I finally started making some progress. I am not new to programming, but new to Assembly. I have used Fortran, Basic, Java and Html for year years. The big problem I have had was the documentation for the MPLAP, PicKit, and the 675's. Cats was correct. It was the Comparitor that was throwing me off. I had no idea that it defaulted to the "comparitor" mode. Also, the documentation for the "config" word is not good. It took me a while to realize that I needed to insert that in the code. The last thing that I have not figured out is "org". It seems that the "org" command references a memory location but why is it needed? Some of my code works without this command.
The output of the evaluation socket is wierd. It is simple enough that they use only 4 GPIO lines to address 8 Leds. If you make all of the GPIO (except gpio 3) outputs, you can force some lines hi and others low. Oddly, some of the Leds glow dimly when reversed biased. I only noticed this the other night when it was dark.

[GeneSS]

Whoops, I wasn't finished. Just another thanks for all your suggestions. My code is running and I will be building on it from day to day.

Peace

Gene

[Texy]

ORG tells the assembler where the next block of code is going to go in memory.
So for a PIC the first bytes read from the program counter upon switch on or reset will be 0. Usually the first code is a jump to the start of the 'main' code, as the first bytes of memory are (usually) reserved for special needs - the interrupt service routine, for example, will always be called to address 0004. You may have seen an 'org 4' just before the ISR in other code examples. If you are not using an ISR then you may not need it - as perhaps in your trial examples.
Hope this helps,
Texy

[PDK]

Hi,

I am just starting out on the microcontroller thing and have downloaded icprog and built several programmers but can't seem to get one to program!

I downloaded a couple of pic projects and built the speed400 controller by Bruce abbott using a 12c509. Also I breadboarded another speed control for a 16f84
First I built a JDM programmer connected to the serial port. I setup icprog from the hardware check (and inverted where needed) area so that when the apropriate section (data, clc etc) were activated (with the box ticked) the pins on the programmer went high. When I loaded the hex and pushed the program button it would go through the motions and then say that it was varified!! All good but, the chip did not work in the project. If I put the chip back in the programer and do a 'blank check' it says that the device is blank.
I then built an el-cheapo programmer and it did the same thing.

What should I look for and try. :confused:

I am using windows XP, the JDM was serial port and the el-cheapo parrallel port.

Many thanks
Phil

[joe@tech-mp]

I use a Picstart programmer. The firmware is upgradeable for new devices when they become available, Microchip supports it, it is low cost, and the thing works. Add up your time spent so far and consider the savings. Many of the homebrew Pic programmer projects have limitations that may not be well understood by those that build them.

Joe

[BGR]

I use a Picstart programmer. The firmware is upgradeable for new devices when they become available, Microchip supports it, it is low cost, and the thing works. Add up your time spent so far and consider the savings. Many of the homebrew Pic programmer projects have limitations that may not be well understood by those that build them.

Joe

Yea I agree, only issue that I have ever had with a picstart is when Windows NT slowed the serial port to the point that it failed to properly burn the chip. Running under DOS in a separate partition fixed that problem.

[Texy]

I use a Picstart programmer. The firmware is upgradeable for new devices when they become available, Microchip supports it, it is low cost, and the thing works. Add up your time spent so far and consider the savings. Many of the homebrew Pic programmer projects have limitations that may not be well understood by those that build them.

Joe

I,ve also got a picstart+. From now on though, the firmware is only upgradeable if your PS+ is fitted with the new Programmable Upgrade Module.
The good news is that this module is flash upgradable from mplab - you'll never need to purchase another upgrade (so it says here!).
Texy

[Texy]

Hi,

I am just starting out on the microcontroller thing and have downloaded icprog and built several programmers but can't seem to get one to program!

I downloaded a couple of pic projects and built the speed400 controller by Bruce abbott using a 12c509. Also I breadboarded another speed control for a 16f84
First I built a JDM programmer connected to the serial port. I setup icprog from the hardware check (and inverted where needed) area so that when the apropriate section (data, clc etc) were activated (with the box ticked) the pins on the programmer went high. When I loaded the hex and pushed the program button it would go through the motions and then say that it was varified!! All good but, the chip did not work in the project. If I put the chip back in the programer and do a 'blank check' it says that the device is blank.
I then built an el-cheapo programmer and it did the same thing.

What should I look for and try. :confused:

I am using windows XP, the JDM was serial port and the el-cheapo parrallel port.

Many thanks
Phil

I used to use ic-prog, and its highly recommended - for the price you can't go wrong! It does seem strange that your device programs and verifies but also passes the blank check! The only way logic tells me all of that is true is if you are trying to program a 'blank' hex file. Which device are you trying to program - the 12c508 or the 16f84? I found that my homebuilt comm port programmer couldn't program the 12c508 devices. I read that the OTP devices needed more current to program them, and my programmer just wasn't man enough for the job. I also found that I couldn't program any devices reliably once I,d upgraded from windows ME to XP - you know you need to install some extra drivers for XP to get icprog to work, right?
After all those programs, I got a picstart+ from ebay, and I,ve not looked back, especially as I can directly drive it from mplab - makes thing a whole lot easier and quicker to develop code.
Texy

[OmegaDot]

It does seem strange that your device programs and verifies but also passes the blank check! The only way logic tells me all of that is true is if you are trying to program a 'blank' hex file.Texy

I had similar symptoms once with my ElCheapo, burning someone elses hex file (that I didn't assemble and knew little about). The problem turned out be be that the hex file was Intel32 format and the ElCheapo software was looking for Intel8 format. The sw read and "burned" the first line of the Intel32 file and mistook it for "done" (or else just choked). The sw "verified" but also "blank checked", just as you saw. I forget the details, but the 32 header looked like a line with no data bytes in the 8 format. The check sum from the verify matched what you would have calculated from the first line of hex. I suppose I should have been suspicious because it took no time at all to "burn" the file.

You can specify Intel8 format either as a directive in the assy file or as a line in the project file. However, I never could find where in the project window you could specify the format. Details of the files are on my other PC, but let me know if you need snippets.

[PDK]

I had similar symptoms once with my ElCheapo, burning someone elses hex file (that I didn't assemble and knew little about). The problem turned out be be that the hex file was Intel32 format and the ElCheapo software was looking for Intel8 format. The sw read and "burned" the first line of the Intel32 file and mistook it for "done" (or else just choked). The sw "verified" but also "blank checked", just as you saw. I forget the details, but the 32 header looked like a line with no data bytes in the 8 format. The check sum from the verify matched what you would have calculated from the first line of hex. I suppose I should have been suspicious because it took no time at all to "burn" the file.

You can specify Intel8 format either as a directive in the assy file or as a line in the project file. However, I never could find where in the project window you could specify the format. Details of the files are on my other PC, but let me know if you need snippets.

Yes I think you have something there.
My chip also ''burns'' very quickly. I don't really know how long it should take but it is finnished in less that 10 seconds! I have seen somewhere about the two formats (ic-prog or MPlab ?) so I will have to have a closer look. So I should be looking for the Intel8? Does this apply even if I am using the IC-prog and not the el-cheapo software?
Yes I know that it would be much easier to buy the picstart+ but I just don't have the spare cash now that I am studying. I am not using the high-tech new devices and just wanted to learn the very basics as a step up for my subjects next year.
Many thanks for your comments
regards
Phil

[PDK]

Hi,
OmegaDot. I have had a bit of a look at changing the format but no sucess yet. Can you please give me some of the "snippets" that you think may be of use. Even a hex file in this format that I can test my programmer on.

best regards
Phil

[joe@tech-mp]

FYI, Most linkers generate only a few types of target files. They rely on utility programs for converting to the many of the possible output file formats. The utility will use the binary file to generate the desired output file in the specified format. This is a utility called bin2hex (http://www.keil.com/download/docs/bin2hex.zip.asp)

Another utility called objtohex is bundeled with the PICC lite C compiler that is free. Go Here (http://www.htsoft.com/)

Joe

[OmegaDot]

Here is a section from an MPLab project file (*.pjt) that shows one way of specifying the output format. See the 1st item in the OptionString. This file can be manually edited if necessary.

[Target Data]
FileList=ECU628.ASM;
BuildTool=MPASM
OptionString=/aINHX8M;/e+;/l+;/x-;/c+;/rhex;
AdditionalOptionString=
BuildRequired=0

Another way to make the switch is in the Assembly file (*.asm) with the addition of a directive. The following snip is from a 16F84 application. Note the second "list" statement.

list p=16F84 ; list directive to define processor
list f=INHX8M ; make intel 8 format
#include <p16F84.inc> ; processor specific variable definitions

__CONFIG _CP_OFF & _WDT_OFF & _PWRTE_ON & _XT_OSC

[OmegaDot]

Here is the assembly file from the snip in the previous reply. This simple app takes the state of Port A, bit 4 and copies it to Port B, bit 2. Operation can easily be observed with an LED on PortB.2

BTW, this was setup for a Xtal oscillator.

;************************************************* *********************
; *
; Filename: fmsck1.asm *
; Date: *
; File Version: *
; *
; Author: *
; Company: NA *
; *
; *
;************************************************* *********************
; *
; Files required: *
; *
; *
; *
;************************************************* *********************
; *
; Notes: Hardware test for FMS transmitter interface board *
; *
; *
; *
; *
;************************************************* *********************

list p=16F84 ; list directive to define processor
list f=INHX8M ; make intel 8 format
#include <p16F84.inc> ; processor specific variable definitions

__CONFIG _CP_OFF & _WDT_OFF & _PWRTE_ON & _XT_OSC

; '__CONFIG' directive is used to embed configuration data within .asm file.
; The lables following the directive are located in the respective .inc file.
; See respective data sheet for additional information on configuration word.




;***** VARIABLE DEFINITIONS
w_temp EQU 0x0C ; variable used for context saving
status_temp EQU 0x0D ; variable used for context saving








;************************************************* *********************
ORG 0x000 ; processor reset vector

main

;init port directions
;PORTA is input by default
nop

bsf PORTB, 2 ; Make the LED on PORTB.2 "off"

bsf STATUS, RP0 ; Goto Bank 1 to set Port Direction
bcf TRISB ^ 0x080, 2 ; Set RB0 to Output
bcf STATUS, RP0 ; Go back to Bank 0


;Loop
; movf PORTA, w ; Simply Transfer PORTA.0 to PORTB.0
; movwf PORTB

; goto Loop




MainLoop
btfss PORTA,4 ;test the buffered Tx pulse
goto $+3
bsf PORTB,2 ; copy high state to output
goto MainLoop
bcf PORTB,2 ; copy low state to output
goto MainLoop ; repeat indefinitely

END ; directive 'end of program'



The corresponding INHX8M hex file is here:

:1000000000000615831606118312051E0928061521
:0600100005280611052879
:02400E00F13F80
:00000001FF

[PDK]

Thanks OmegaDot,

I will give that a go

Phil

[OmegaDot]

PDK,
any luck yet?

[PDK]

Hi OmegaDot,

No I have been flat out with some assignments. I will try again when I can see the end of this tunnel :)

Regards
Phil

[dgoderich]

For stuff that does not require extreme speed, the Basic Stamp is by far
the easiest to program. I can not beleive no one has mentioned it. You guys
are making things harder for yourself. Most of you must be programmers to want to go with assembly

I am an EE and have writtten many programs using the stamp in Pbasic it is
a lot easier for a beginner/nonprogrammer to get started with. But I don't see any mention of it in this thread?

The compilier and more info for you beginners can be found at
www.parallaxinc.com

[Cats Eyes]

For stuff that does not require extreme speed, the Basic Stamp is by far the easiest to program. I can not beleive no one has mentioned it. You guys are making things harder for yourself. Most of you must be programmers to want to go with assembly ...
Yes, you are probably quite right that Basic Stamps are easier to learn to program than PICs. But to be fair, the name of this thread is Learning PIC and in navkan's orignial post he said "I want to learn to use PICs."

So that is an interesting question. If you want to learn to program PICs, is it easier to launch right in and try to program PICs, or is it easier to learn to program Basic Stamps and then transfer that knowledge to PICs?

Lets see what people have to say...

-- Kevin

[niklas]

I think the BasicStamp is a dead end if you intend to learn using the PIC-processors. Plus it is expensive so the money for one BasicStamp would buy you many different PICs... Well thats just my opinion and I don't like the BasicStamp...

//Niklas

[steve lewin]

I think Stamps have their uses but for most of the things I want to do they are too big, too slow and too expensive. Directly programming PICs in a high level language like Basic is a reasonable compromise. It gives you access to a much better range of devices and features without the need to get involved in assembly language, which I do agree is a bit daunting to the newcomer.

If you are really interested in learning to use microcontrollers then the Stamp is a real disadvantage because it imposes far too many limits and hides from you what is really going on.

Steve

[navkan]

I did look at Basic Stamp when I was first investigating the whole subject of learning PICs. I wondered if it was a simple way to do it but when I discovered that PIC programming with an hol (perhaps in conjunction with some assembly language) was an option I dropped consideration of Basic Stamp. I have an open (if somewhat empty) mind, however, so like Kevin, I would be interested in others opinion.

PS: I certainly did not expect to launch such a spirited discussion. This is a great group!

Fred

[e-geezer]

If you need real-time programming, you'll need to know precisely how fast your code is running. For example one of my current PIC projects is an ultrasonic parking helper. I generate the 40kHz signal required using code. To do it I need to know the exact number of program cycles (1uS each for a 4MHz Xtal) between the leading edge of the [1] I output to a port and the end of the following [0]. Most instructions in the PICs take 1uS. Some take 2uS. When I receive the reflected pulses as input to another port, I again need to process the pulses as they come in.

'Real time' sometimes means 'process the data immediately - as it arises', as in the above application. Another example is processing radar data, as I used to do at West Drayton air traffic control centre using PDP11s. In these applications knowing the speed of your code is essential, and you know it with assembler because each instruction is converted to one machine instruction, and the number of cycles for each instruction is given in the processor's documentation.

Sometimes 'real time' just means 'process the data as soon as possible', as in, say, a messaging application. C and other high-level languages would be OK for that. The military also use Jovial, ADA and FORTRAN for that sort of application (according to my aircraft magazines).

[clipclop]

As this thread seems to have been lost and there are regular questions on Pic's , can this thread be made a "sticky" ?
It will remain in plain sight then and the info in it not lost , but added to .
Stewart

[clipclop]

Found a good online BOOK on learning PIC heres the link :- http://www.mikroelektronika.co.yu/english/product/books/PICbook/0_Uvod.htm
hope its usefull
Stewart

[Malc C]

I'm also new to this PIC programming stuff and have the Microchip PICKit1 (USB), and found Assembly hard to get to grips with. For simple stuff (flashing LEDs, generating PWM etc) I found JAL easy, and I was able to get results quickly. Here's some links

http://www.voti.nl/jal/ - Excellent web site with the open code
http://www.esquire.co.ae/sunish/html/jaledit.htm - Excellent IDE (windows base editor)

To flash an LED using JAL the programming is simple

include f675_4i
include jlib

var bit LED1 is pin_a0

pin_a0_direction = output

Forever loop
LED1 = high
delay_20ms( 5 )
LED1 = low
delay_20ms( 5 )
end loop

[Hovertime]

Well, it definitely sounds too complicated for my taste, I just like building projects that are already made (hex and schematics download) by someone smarter than me;)

Thanks to all who shares their projects!

[Malc C]

Yeah its great that a lot of the guys here share their code and even help others out with writing variations to suit a particular project. But it helps to try and write your own programs even if it is fimply to flash a few LEDs or actuate servos, etc as you get a great sence of achievment when it works. Mind you I don't think I'd ever get to the levels of some of the guys here who design complex data loggers, mixer boards and the like, and then write thousands of lines of code to program the PICs !!

[kfong]

Here is a really cheap way to start,

http://www.embeddedtronics.com/picmee.html

It is a stand alone programmer and controller. You can separate the two by cutting it or we can cut it for you.

The programmer supports the PIC family that is listed by ICPROG. The necessary pins are on a header for in circuit programming.

The controller supports Microchip PIC16Fxxx or similar pin compatible processor.
Dallas DS1302 real time clock.
Two channel Linear Technology LTC1298 12 bit A/D.
TWS433 RF transmitter.
Compact size 2.45" X 1.7" can be cut for an even smaller footprint.
Built in "TAIT" compatible parallel port PIC programmer.
No expensive hardware programmer needed. Program files can be downloaded using a standard parallel port.
All I/O pins of micro are brought out to a .1 space header for easy external connections.
Professional quality board with silkscreen.

You don't need to bother to put in the realtime clock, A/D, extra memory or transmitter. They are there if you need them. All pins are available on the header.

If you keep the board as one unit, you just plug it into the parallel port and program. Unplug and plug it onto a protoboard to experiment.

Bare PC Board: $10.00

Kin
http://www.embeddedtronics.com/

[Hovertime]

Another good site with PIC and general electronics articles, http://www.poptronics.com/interactive/intro.html

I also got my PIC programmer kit from them :http://www.poptronics.com/interactive/FreeProjects/MultiChipPgmr/MultiChipPgmr-P1.html

[Malc C]

Thats a nice little programmer there.. but it still suffers from the same issue with the PICKit1, in that you are limited to PICs with 18 pins or below (or 14 pins in the case of the PICKit). Mind you this is only an issue if you intend using PICs above these pins, but it does limit the functionality of these programmers IMO. I'm sure it would be possible to adapt that programmer (which looks very much like its based on the JDM design) to handle larger PICs

[Texy]

In Circuit Serial Programming (ICSP) really is the way to go. Design a header on your target board with all the lines neccessary to program the PIC. Make a cable that has (in this case) the relevant pins on the 18-pin socket at one end, then at the other a connector to go into your target board header. This way you don't need to remove the PIC from the target board to program it. You will of course need to follow some basic rules on the use of the ICSP designated pins in your hardware design.

Texy

[Acetronics]

Hi Navkan

An efficient thing is PicBasicPro from Melabs ...
add all the Pic Course from Parallax inc.( soft is compatible !!! ) and you can do a very big lot of stuff for your models ...
And overall, you have PicBasic Free Forum !!!
difficult to find an easier Way ... a cheaper, may be !!!

Alain

[Hovertime]

PS-the programmer that I received from Poptronics is a newer version, and does have In circuit programming. Its cheap - cost me about 15$ with shipping, and it works with my laptop, but it needs serial port, and these may be gone from PC's soon.

[joe@tech-mp]

Serial ports will be imortalized with the low cost USB to serial converters. Check it out (http://www.tigerdirect.com/applications/SearchTools/item-details.asp?EdpNo=166218&CatId=464)

Joe

[Hovertime]

I don't think USB-serial adapters work for PIC programmers though..

[Chippie]

Serial ports will be imortalized with the low cost USB to serial converters. Check it out (http://www.tigerdirect.com/applications/SearchTools/item-details.asp?EdpNo=166218&CatId=464)

Joe

I'm afraid that these 'so called' usb/serial convertors do not fully emulate a true RS232 serial port.

I have one such convertor and it wont allow me to use my laptop with my Velleman programmer :(

[navkan]

Hi
I originated this thread and expected to be well on my way to being an expert PIC circuit designer by now. As usual life got in the way and progress has been slow (spending lots of time learning to fly the Multiplex Magister amongst other things.) Anyway I just got my Olimex MCP-USB programmer from Spark Fun. I chose this product as it was reasonably priced and was advertised to work with a laptop.

I'm hung up at the moment because when I install the FTDI usb serial driver I get a "device will not start (code 10)" error message. The board seems to be ok as I can successfully connect to my Desktop PC. For some reason it just doesn't like my Dell laptop. If anyone has any brilliant ideas I'd appreciate you sharing them with me.

Fred

[Malc C]

I take it you are pluging in directly to a USB port and not using any serial to USB adaptor ?

If so and it works fine on the desktop, but not the laptop then the problem would appear to be the standard employed by DELL when they built the laptop. I think its down to the amount of power that can be pulled from the 5v rail on the USB port. Some limit this to save battery life etc. Might be worth a call to DELL tech support to see what they have to say.

Uhmm.. just took a look at that programmer and it is as you say USB, if so why would you need to install a driver to use it on your dell (unless using an USB- RS232 adaptor ??) If this is the case then the problem is that a lot of comm ports on laptops are not able to supply the correct voltages (this is why some PIC serial interfaces do not work with FMS and laptops).

[navkan]

Malc C

The MCP-USB uses a USB UART chip designated the FT232BM made by FTDI. In order to interface this device with a computer USB port a FTDI driver (available from their web site) has to be installed. It is this installation that won't work on my laptop but will on my desktop (both Dell products).

Your idea that Dell limits the power out of their usb ports is interesting. I will give Dell a call.

Thanks, Fred

[Malc C]

Fred,

Thanks for the info. I would of thought that the device would of come up as a standard HID device using the built-in windows drivers.

I have a similar issue with my PC that I've never been able to get to the bottom of. Two USB ports don't seem to power an interface. These are the on-board sockets that form part of the stack at the back of the MOBO, yet the sockets fitted to headers on the MOBO work fine ?? - Yet if I plug a mosue in to these duff ports it works fine ???

On Laptops there are so many power saving options that it might just be somthing in the BIOS that needs changing or in the windows control panel. Be interesting to hear what Dell have to say

[AndyKunz]

I have used the FTDI chip in one product. I don't plan on doing that again. Henceforth it would be with a Microchip 18F4550.

Power is supposed to be limited by 500mA per bus, 100mA per device. Most but not all USB hubs & PC's ignore that and allow as much as they can provide.

Andy

[Cats Eyes]

Hey, here's an interesting question for all you USB gurus. There have been several threads over in the Aerial Photography forum about whether a camera can be triggered through the USB port (e.g. see: electric trigger for usb-equipped camera? and Nikon 3700 remote operation).

Apparantly some cameras support a USB protocol called PTP ("Picture Transfer Protocol") that can be used to control the camera in certain ways (the one we're interested in is triggering the shutter). The general opinion seems to be that trying to make a PIC talk to the camera using PTP would be very difficult.

However, it seems that making a PIC talk to a host computer over USB is actually fairly easy. Why the difference? I'm assuming that it's because in one case the PIC is acting as a peripheral, talking to a host PC, and in the other case the PIC is acting as the host PC talking to the peripheral (the camera). Also, there's the PTP protocol on top of the underlying USB protocol that you'd have to worry about.

Does that sound correct? Any ideas?

-- Kevin

[AndyKunz]

How about USB/OTG?

Andy

[Cats Eyes]

How about USB/OTG?
Had not heard of it before -- had to Google it. (e.g. http://www.usb.org/developers/onthego/).

I got the feeling that it was a supplemental protocol that had to be programmed into the device, over and above the basic USB protocol. Any idea if cameras currently on the market are OTG-enabled?

-- Kevin

[AndyKunz]

They have an OTG logo on them if they are. Many are - those that work with those Photo Printers directly often are. The capabilities are less than a standard PC, but the important features are there. Basically, you have so much horsepower in the peripherals nowadays it doesn't make sense for them to not be able to act as a limited (or more) USB host.

I believe PTP use OTG technology, perhaps as a particular instance. I'd have to do some research but frankly I'm a little busy for that right now.

Andy

[Mr.RC-CAM]

Generally speaking, I think you will find that a camera's OTG features will be basically centered around mass storage, picture swapping, and photo printing. Using it to snap a photo might be a stretch for what the camera makers will develop.

RC-CAM