Pic microcontroller

[Jon Wilder]

If you already have a decent understanding of the PIC, either in assembler, or just the hardware itself, then there's no problem using C at all - if you like C

But the problem comes with people starting on the PIC (or other processors) just in C, they don't have a clue about the hardware and what's required, and as most application notes are in assembler it means they struggle finding how to do things.

Historically programmers at University weren't allowed to use HLL's until they had a sound grounding in assembler, and I think that is really as important now as it was then.

Exactly! Most of the example routines in the PIC data sheets (such as the required routine for writing to EEPROM) are written in assembly, and without knowing assembly first this would confuse the n00b first learning PIC programming.

Back in 2005 when I first started using a MIDI rig for guitar, I had a MIDI foot controller that featured 2 expression pedals. I used one to control a Digitech Whammy II and thought it would be super cool to modify my wah pedal to respond to MIDI so that I could make use of the 2nd expression pedal. So I went in search of and learned that I'd have to learn how to program microcontrollers. Not being a programmer I quickly said "Forget that" and nixed the idea.

Fast forward to September of last year I was working for Voodoo Lab. When I learned that the owner wrote most of the MIDI code for their devices it inspired me to give the PIC another shot (although they were using the 8031 since most of their stuff was designed 16 years ago when the 8031 was the hottest thing on the market at the time). I checked out the Cybot page at **broken link removed**, which had a PIC tutorial. After a few times of reading through the tutorial (which teaches assembly), I started to somewhat grasp the material. Shortly after that I found an old DIY kit from Ramsey Electronics for the PICPro programmer (their kit for the NoPPP programmer) at my local electronics surplus store and decided to give it a go and build it. Built it, and it didn't work at first (I learned shortly after that it hadn't been tested on PCs with over a 500MHz CPU, which really dated the kit lol), but as it turned out I had Enhanced Parallel Port enabled in the bios on my PC and had to change it to Standard Parallel Port to make it work. Loaded in the example program and it worked. That gave me a platform to experiment with coding on.

After a month or two of experimentation, reading every PIC book I could get my hands on and debugging my own code, I began to understand how to code in assembly and take advantage of the full instruction set of the 16F series of PIC's.

Assembly language itself is not hard to learn. It has a very simple syntax (3 columns - label, instruction and operand) and it always follows that syntax. I think the most difficult thing about it is that you have to learn the hardware itself and you as the programmer are in charge of most of the housekeeping. I think it was probably simple for me because I've always been a hardware guy having dabbled in analog electronics for most of my electronics days so I'm one who needs to know what's happening electrically on every wire in the circuit rather than being able to look at the wires as an 8 bit group and focusing on the "data" being transmitted on all 8 wires at once.

 

[3v0]

Random bits:

It is important to learn good programming practices early on which makes asm a poor choice as a first language. It lacks structure.

If the small asm segments in the datasheets are a reason to use asm then the huge amount of c code in the TCIP, USB, and radio communication stacks easily trump it.

My personal suggestion is that people learn c first on a PC then learn how to use it on a uC .I agree that learning about bits, bytes and peripheral hardware is essential. But asm only teaches you the instruction set which you do NOT have to learn. The problem is not with c but that we need to teach it with hardware in mind.

Unlike a human coding in asm a compiler does not have to produce readable code. It is free to do most anything that will result in smaller code. And because optimization is done at computer speeds it can search for opportunities that a human might not find. Much of the code bloat is from the inclusion of libs. I expect compilers are improving with time and they have had decades to work on optimization. But not all compilers are created equal.

If you are using a compiler that does not optimize well, memory and speed are cheap.

 

[TheKnight]

Like suggested by 3v0. I will first get back and completely learn C/C++ on PC or software development. In meantime, I'll be reading pic and electronics eBooks. Thanks for all the help.

 

[Dakta]

I don't think you have to 'know' assembly as such. But as said before it's important I think to get your hands dirty with it, because in my experience - 'you will not escape assembly'.

I started with assembly, wasn't great at it but I could write simple programs off my own initiative with it, and my biggest surprise when moving to C which seemed to have an easy-to-use library for just about everything I could imagine a hobbyist would use was that you still have to 'set the chip up', just calling a routine in C that does this or that might not work until you've set the registers at the start of the code. So even though I'm using a much easier language now that I used to, the old routine I had with assembly where i'd set up the peripherals and get the chip 'booted' as I used to phrase it, is very much still with me today.

It's not so much about being able to code in assembly, it's just the lessons you learn about pic's when using assembly will make life easier across the board.

 

[cubnflyer]

I would recommend the assembly route, as said before it will give you a better understanding of the way the various registers work togther within the PIC. Why not check out Nigel tutorials, I can recommend these as a starting point.