Learning to use programmable integrated circuits

[robertgzzzt]

Hi, I'm relatively new to the world of electronics. I've recently taken up model building as a hobby, and in the past few weeks, through researching various online tutorials and youtube videos, I've learned how to build a couple of circuits for controlling LEDs to light my models. A simple LED blinker circuit using the 555 timer, and a chaser circuit using the 555 and a 4017 Johnson's decade counter. Also, Kris and *steve* here on the forums have helped me sort out some power issues.

I'd like to take it a step further. I'd like to learn how to use PICs, and hot air soldering so that I can use very small SMD components. I have no programming experience at all, however, I think I can learn if there's a tutorial somewhere like "PICs for dummies", or some literature that explains it in a way that someone with no formal training, like me, can understand. For the most part I'll probably just be using existing code that someone else has already written, modified slightly for the timing I need. For now, all I'm wanting to do is control some LEDs, nothing overly complicated. However, I know this is not something one can earn overnight and I'm willing to put forth the effort. I'm looking for some advice on where to begin and what hardware would be the most user friendly. Can any of you guys (or gals) point me in the right direction?

 

[p.erasmus]

Take a look here ,there are many example programs and books for beginners to start with PIC's ,Get youselve a small Development board use the DEMO compiler/example code and the books in no time you will do some nice things with these PICs

http://www.mikroe.com/pic/development-boards/

You can choose between C,Basic and pascal which ever language you would prefer ,I personally like C and Pascal
you can down load a demo version of the compiler from here

http://www.mikroe.com/mikroc/pic/

the demo compiler is fully functional up to 2K code size which should be enough for most of your beginner projects
Hope this helps
Regards

 

[robertgzzzt]

Hi p.erasmus, thank you for responding. In regard to the "small development board", there are many to choose from. What would you recommend (the more user friendly, the better)?? Do I need a board that can handle 40 pin PICs? Remember I'm just controlling flashing LEDs

Thanks a bunch for those links. I will check them out right now.

 

[p.erasmus]

Hi
I like the 28 pin board here
http://www.mikroe.com/ready/pic-dip28/
it also come with bootloader you do not need and ICD unless you would like to debug the code which is the prefered way however for a start this would give you a kick start and it wount stay long by blinking led then you would like to do more ,believe me microcontoller programming get adicted

 

[robertgzzzt]

Awesome, I was just admiring that board a few minutes ago. What do you think of the Arduino? I read a little about it before I posted this topic, but I think it's an entirely different format than the DIP28 isn't it, as far as the compatible PICs it can program?

They didn't have a book on "pascal" at MikroElektronika, all they have is Basic and C, but I found this at Amazon

http://www.amazon.com/gp/offer-listing/0531047482/ref=dp_olp_used?ie=UTF8&condition=used

 

[p.erasmus]

There are so many examples how to use pascal to program the pic and with a book like you showed helps you to understand the pascal syntax you are on your way.
Arduino is fine however my problem with Arduino is that it is sort of its own language and sytax ,you are always in the hands or Arduino with the C or pascal option you learn to use the low level things of the pic and you can do with the micro what you want to do ,with Arduino if it does not support something you want to do you are stuck go for learning how the micro works at regsiter and bit level apply your pascal to control the registers and bit to your needs and you are dependant on nobody

just on a side note all the mikroE stuff is available at Mousers in the US

 

[robertgzzzt]

I see what you're saying. Just a couple of other questions and I'll quit pestering you, I promise

Hypothetically, if I learn the basics of programming, I can use that DIP28 dev board to program another PIC, then solder that PIC to a prototype board to mount inside my model display base to run my LEDs, totally self contained and independent of the dev board?

Can it also program SMD PICs and does it support 8 or 16 pin PICs

Another hypothetical, can I control more than one function on a single chip? For example, say I have a large model with some LEDs that blink....one second on, one second off, and other LEDs that "strobe" (flash on for a tenth of a second, then off for one second) and maybe even a third set of LEDs, say 8 of them, than run in a chasing pattern. Could I do all of those functions with a single chip? All of the LEDs I would be using have a forward current of 20mA and anywhere from 1.2 to 3.4 forward voltage, depending on the color.

EDIT I want to be able to program those tiny little chips like you see on mini RC helicopter control boards.

 

[p.erasmus]

You are welcome to ask as many question as you need to ask

Yes you can use the the 28pin board to program 28 pin devices however then you need an external programmer such as mikroProg which connects to the 10 pin header marked mikroProg on the board ,you can then remove the pic and place it on anyother board and it will run the code you programmed,
Note that the board comes with an PIC18F25K22 which has a bootloader proggrammed into it this allows you to programm this pic without any external programmer you have then to put this pic on your other board which is not a good idea.
if you place a new or other pic in the board you need to programm the bootloader into this pic to be able to program it again if you want to develop code only then use the pic with the bootloader option ,if you want to program more than 1 pic then get a board and a mikroProg ,
Thisboard will not help you with smd parts for smd part I would recommend that you place them on the baord you want it to be on and place a header on this board that connects to the smd parts or tracks and program then in circuit or in the target board.
This pic runs at 64Mhz you can run several things at the same time example blink leds read Analog signal switch thing on and off,communicate with your pc over UART ect .
The pic pins can source or drain around 10-15mA no problem to drive leds directly you only need a resistance in series with the leds,take a look at the EasyPIC7 Board manual and you will see how to connect leds and other things to the PIC port pins
the advantage of an external programmer or ICD (Incircuit debugger) is that you can single step threw your code and debug it and you can program your PIC's this is a necessary tool for people that really wants to programm effectivly and develop code

To program the small PIC(PIC10 and PIC12 series) I would then suggest a EasyPIC7 board then you have a mikroProg ICD on the board ,plus you can programm all PIC12 ,16 and 18 F chips ans many times as you whish remove them from the board and put them in your projects you can use the board to develop your code and Program and debug chips and remove them and put thm in other boards
you the just buy the EasyPIC 7 board nothing else you have a whole development system

http://www.mikroe.com/easypic/



Hope this help you

 

[robertgzzzt]

You are welcome to ask as many question as you need to ask

You're awesome. Thank you for being so patient

To program the small PIC(PIC10 and PIC12 series) I would then suggest a EasyPIC7 board then you have a mikroProg ICD on the board ,plus you can programm all PIC12 ,16 and 18 F chips ans many times as you whish remove them from the board and put them in your projects you can use the board to develop your code and Program and debug chips and remove them and put thm in other boards
you the just buy the EasyPIC 7 board nothing else you have a whole development system

That sounds like the ticket right there. If I can learn the programming language, then I can program pretty much any EasyPIC7 compatible chip I need to drive LEDs, or maybe an audio device for sound effects, then remove the chip and solder it into my circuit. You see, once I program a chip to control the LEDs or whatever, the chip will then have to be placed in the model permanently. I won't be programming a chip to do one task, then reprogram that same chip later for another project. Once it's programmed, it gets installed inside the model for it's entire life-span.

The pic pins can source or drain around 10-15mA no problem to drive leds directly you only need a resistance in series with the leds

Yes I'm familiar with OHM's Law and using current limiting resistors, but I might be running up to 10 blinking LEDs @ 20mA each, wired in parallel, so I assume I would have to use an N-Channel MOSFET in the circuit to drive them, and switch the MOSFET with the output pin on the chip? (steve and kris here on the forums taught me that little trick with my 555 timer circuit)

 

[(*steve*)]

however my problem with Arduino is that it is sort of its own language and sytax

Considering you're using a standard C compiler, you're actually quite wrong.

Sure, the environment makes some things a lot easier (you don't have to worry too much about some of the C project setup stuff and library management is "easier"*) but you're still programming in real C++ using a real compiler.

Arduino programming is closer to the metal than you might imagine. (I think they hide this from people so as not to scare them away)


* Until something goes wrong

 

[KrisBlueNZ]

One point that hasn't been made clear: when you design your circuit board, you should always include an ICP (in-circuit programming) connector, so you can update the code in the micro easily without removing it. (You will need a programmer that supports ICP, as well as - or instead of - programming a device directly in a socket.) This is especially important if you use a surface-mounted device. This applies whether you're using a PIC, an AVR (Arduino), or something else.

Also FWIW I would not use Pascal; it is not widely used nowadays. The usual languages for microcontroller programming are C and assembly language.

 

[p.erasmus]

Yes I'm familiar with OHM's Law and using current limiting resistors, but I might be running up to 10 blinking LEDs @ 20mA each, wired in parallel, so I assume I would have to use an N-Channel MOSFET in the circuit to drive them, and switch the MOSFET with the output pin on the chip? (steve and kris here on the forums taught me that little trick with my 555 timer circuit)

This is a question of the circuit design you will use ,from microcontroller view it does not matter how you connect the leds as long as you stay with in the controller pin specs.

Arduino programming is closer to the metal than you might imagine. (I think they hide this from people so as not to scare them away)
* Until something goes wrong

Steve agreed I am in no sense and Arduino expert and also did not try to say Ardruino is no option however for me the danger is always when there is to much abstraction ,I like to know which bits ,bytes and regeister effects what in the micro and I like to have the ability not to use libraries and Roll my own libraries this way when things do not wotk I can debug my libraries.

Also FWIW I would not use Pascal; it is not widely used nowadays. The usual languages for microcontroller programming are C and assembly language.

Kris agreed ,However in Europa and the east Pascal and Basic are still very much alive
I think for a hobbiest it does not matter if he program in C basic or pascal ,to me it is important that the person likes the programming language and find it enjoyable to program with,for Industrial application which needs certification and safty certifications I can imagine it would be hard to get with out C and MISRA compliant C compilers ,but as said to an hobbiest ,I think this is not relevant and why should a guy suffer with C if he like Pascal or Basic or even stuff like flow Code
to me its a matter of choice and I mentioned all 3 options to Robert not insisting to use pascal

have great time guys

 

[ligo.george]

Here are some pic microcontroller tutorials .
PIC Microcontroller MikroC Tutorials
PIC Microcontroller Hi-Tech C Tutorials
MikroC is very easy to learn as it have a lot of built in libraries... ... but it is less efficient compared to Hi-Tech C. Use Hi-Tech C if you want to know the internal working of PIC Microcontroller and more efficient code...
Here are tutorials for other microcontrollers...
8051 Keil C Tutorials
ATmega32 Atmel AVR Microcontroller Tutorials

First choose the microcontroller and buy a programmer....
You can buy programmers here..
Robokits
eXtreme Electronics

If you are going to use PIC Microcontroller, PICKit2 is the best.. PICKit2 is an open source PIC Programmer/Debugger manufactured by Microchip... As it is open source any one can built it... Here is a modified version of PICKit2 which uses commonly available components...... including ZIF Socket..
USB PIC Programmer - PICKit2

 

[robertgzzzt]

from microcontroller view it does not matter how you connect the leds as long as you stay with in the controller pin specs.

But isn't it still true that, when connecting LEDs in parallel, you must add up the current, and when connecting in series, you must add up the voltage? 10 LEDs @ 20mA each comes to 200mA. Can these PICs handle that much current?

One point that hasn't been made clear: when you design your circuit board, you should always include an ICP (in-circuit programming) connector, so you can update the code in the micro easily without removing it. (You will need a programmer that supports ICP, as well as - or instead of - programming a device directly in a socket.) This is especially important if you use a surface-mounted device. This applies whether you're using a PIC, an AVR (Arduino), or something else.

Thanks for the heads up on that.

@ ligo.george, thanks for all the links. Some valuable information there.

@ everyone, I am a firm believer in not making things more complicated than they need to be. Whenever possible, keep it simple. Therefore, I want to use a chip that can handle blinking, strobing or sequentially blinking LEDs, maybe a little sound fx. I don't need it to do much more than that. I guess the thing to do now is go do a bunch of reading and hopeful gain enough insight to make an informed decision about what chip will best suit my needs.

 

[KrisBlueNZ]

But isn't it still true that, when connecting LEDs in parallel, you must add up the current, and when connecting in series, you must add up the voltage? 10 LEDs @ 20mA each comes to 200mA. Can these PICs handle that much current?

You're absolutely right. Small digital devices such as microcontrollers cannot supply 200 mA; you will need a buffer of some kind. MOSFETs are the logical choice (pun intended).

I am a firm believer in not making things more complicated than they need to be. Whenever possible, keep it simple. Therefore, I want to use a chip that can handle blinking, strobing or sequentially blinking LEDs, maybe a little sound fx. I don't need it to do much more than that. I guess the thing to do now is go do a bunch of reading and hopeful gain enough insight to make an informed decision about what chip will best suit my needs.

Yes. Even a small PIC will be able to handle all your LED blinking requirements, though you will need to think carefully about how to structure the firmware. A tidy approach is to use a regular timing source - for example, configure a timer peripheral (within the MCU) to generate an interrupt or set a bitflag at regular intervals such as 1 ms - and define the changes on all of the LED control pins in terms of a certain number of these time intervals.

For example, an LED that flashes ten times per second would be ON for 50 of these periods, then OFF for 50 periods; you just need a counter variable, and possibly a current state variable, to control that pin.

Sound generation is a little more difficult because exact timing is more critical. Many MCUs have output compare functions that can be programmed in advance to toggle I/O points when a particular counter value is reached; this is what I would use for simple sound effects. If you want something better than square-wave signals (i.e. "80s sound effects" , you can use digitised (sampled) sound, through a DAC (digital-to-analogue converter) (which can be as simple as a network of resistors). If your MCU is very fast, or includes the appropriate hardware, you can use PWM (pulse-width modulation) instead of a DAC.

As you can see, it would be best to start with the LED stuff, and leave the sound effects until you have more experience.

We have many people here with MCU experience. Please feel free to post any questions and tell us about what you are learning, and ideas you have.

 

[robertgzzzt]

Come to think of it, I doubt if I'll need to control sound fx through the MCU. It would just be a matter of looping a pre-recorded .wav or mp3 file, through a small 8ohm speaker when a button is pushed, I'm all about simplicity, so the simplest way to do that would be the way I want to go. Any application for a sound effect would not require it to be super small, as in microchip small.

We have many people here with MCU experience. Please feel free to post any questions and tell us about what you are learning, and ideas you have.

Thank you, Kris. I will do that. I'm sure I'll be needing help along the way.

you will need to think carefully about how to structure the firmware. A tidy approach is to use a regular timing source - for example, configure a timer peripheral (within the MCU) to generate an interrupt or set a bitflag at regular intervals such as 1 ms - and define the changes on all of the LED control pins in terms of a certain number of these time intervals.

Is this why I'm seeing an LED blinking program written like this .....

PORTB=0XFF;
_delay_ms(1000);
PORTB=0X00;
_delay_ms(1000);

To give myself uber control over the timing? I would probably never need intervals so precise, but it's better to have it and not need it than to need it and not have it, especially if it's just as easy to set it up that way as it would be to set less frequent intervals, like say, hundredths of a second.

 

[KrisBlueNZ]

The method you've shown, using _delay_ms(), is not suitable for your application. If you want to control several LEDs, with different timings for each, you would need several of those execution paths, running in parallel.

An MCU with a single core (and all small MCUs are single-core) can only execute one instruction at a time. If you need it to execute multiple threads simultaneously, you have to be more clever than that.

A general solution is a multi-tasking arrangement, where the MCU executes part of one thread, then switches to another thread and executes part of that, and so on. But in your case, you don't need to go that far. You just need to structure the code so that a single thread generates the control signals for all LEDs.

Say you have three LED-controlling outputs and you want them to flash like this:

LED1: ON for 20 ms, OFF for 80 ms
LED2: ON for 67 ms, OFF for 67 ms
LED3: ON for 50 ms, OFF for 950 ms.

int led1timer, led2timer, led3timer;
char led1state, led2state, led3state;
while (1) {
    wait_for_next_1ms_period();
// LED1: ON for 20 ms, OFF for 80 ms
    ++led1timer;
    if (led1state == 1 && led1timer >= 20) { // 20 ms elapsed with LED1 ON
        portb &= 0xFE; // set the LED1 control pin low
        led1state = 0; // remember that LED1 is now OFF
        led1timer = 0; // reset the timer ready to time the OFF period
        }
    if (led1state == 0 && led1timer >= 80) { // 80 ms elapsed with LED1 OFF
        portb |= 0x01; // set the LED1 control pin high
        led1state = 1; // remember that LED1 is ON
        led1timer = 0; // reset timer ready to time ON period
        }
// LED2: ON for 67 ms, OFF for 67 ms
    ++led2timer;
    if (led2state == 1 && led2timer >= 67) { // 67 ms elapsed with LED2 ON
        portb &= 0xFD; // set the LED2 control pin low
        led2state = 0; // remember that LED2 is now OFF
        led2timer = 0; // reset the timer ready to time the OFF period
        }
    if (led2state == 0 && led2timer >= 67) { // 78 ms elapsed with LED2 OFF
        portb |= 0x02; // set the LED2 control pin high
        led2state = 1; // remember that LED2 is ON
        led2timer = 0; // reset timer ready to time ON period
        }
// LED3: ON for 50 ms, OFF for 950 ms.
    ++led3timer;
    if (led3state == 1 && led3timer >= 50) { // 50 ms elapsed with LED3 ON
        portb &= 0xFB; // set the LED3 control pin low
        led3state = 0; // remember that LED3 is now OFF
        led3timer = 0; // reset the timer ready to time the OFF period
        }
    if (led3state == 0 && led3timer >= 950) { // 950 ms elapsed with LED3 OFF
        portb |= 0x04; // set the LED3 control pin high
        led3state = 1; // remember that LED3 is ON
        led3timer = 0; // reset timer ready to time ON period
        }
    }//while(1)

This code is written to make its operation clear; it is not optimised for efficiency or maintainability. In practice I would use #defines for all the constants in there, and I would probably use a signed counter that combines the count and the state into a single variable. Also, those &= and |= statements that modify PORTB are messy; I would use #defines for the bit numbers and calculate the AND and OR values at the point where they're used. Those (and other) changes would greatly improve the quality of the code, but that code is only designed to be easy to understand.

Edit: (If I don't mention this, someone will probably point it out...) A proper implementation of that code would also be generalised using a loop, once round the loop for each LED output. The ledstate and ledtimer variables would be arrays, and there would be a lookup table, also indexed by LED number, containing a bitmask for the port register.

Another improvement would be to update the I/O register at the start of the loop, using an AND-mask and an OR-mask variable that were set up by the previous 1 ms execution, so that all LEDs would change state at exactly the same instant. In practice this wouldn't be important; no one can notice that one LED came on 20 us after another LED, but it's a tidy way to design the code in general.

 

[robertgzzzt]

Clearly I have a lot to learn, but I do understand the concept. I'll understand it better (hopefully) when I have the device and the necessary software in front of me, so I can study it. Thanks again, Kris

 

[robertgzzzt]

p.erasmus mentioned learning to write in "C" in his first post. I've found a web-site that offers a free training online tutorial for writing in "C++". Is that the same thing, and do I need to learn it (i.e. will I be using it)??
http://www.learncpp.com/

I also found this PIC programmer on Amazon. It looks suitable for what I'm wanting to do, and it has a 6pin ICSP header, but I'll have to buy a cable elsewhere, can't find one on Amazon.
http://www.amazon.com/USB-PIC-Progr...TF8&colid=1TB0WY44C96PY&coliid=I36FNAPPWYNI8E

 

[KrisBlueNZ]

C++ is C with "object-oriented" features. This adds a lot of baggage that I don't think is appropriate for resource-constrained microcontrollers. I have heard of people using C++ on MCUs but I would not consider it myself. C++ is fairly widely used in the computer world though.

That PIC programmer looks good. It's USD 50 and a chunk of that is for the ZIF socket, which you may not ever use, but a quick search doesn't show anything cheaper out there. Perhaps Chris (CDRIVE) knows of a cheaper ICP solution?