Gooligum? Advice for a PIC novice

[jamie297]

Hi All,
I'm looking to get started with PICs and have been checking out the Gooligum tutorials and dev board.
I've got MPLab and my Pickit3 clone, but starting from Google alone seems pretty daunting for such a big topic.

I'm looking to learn enough to be able to add PICs to hobby projects with C, if it gets far enough to be job useful in a year or two that'd be fantastic too.
I've dabbled with programming and, reading the tutorial samples, I don't think I'll have trouble following them.

Short version:
- How do you rate Gooligum dev board and tutorials?
- Are there any alternatives I should consider for a similar budget?
- Should I hold off and learn basic C programming before getting the Gooligum stuff?

Thanks for your wisdom 

[Zero999]

I can't say anything about the development board, I don't have one, but the Gooligum tutorials are excellent.

[jamie297]

Thanks - Do you think I'll need much C ability before starting them?

[Zero999]

Thanks - Do you think I'll need much C ability before starting them?

I don't know. Everyone is different. Why not download some of the free samples of the tutorials and read through them?
http://www.gooligum.com.au/PIC-tutorials

If you want to learn C beforehand, there are plenty of free tutorials and free software available.
http://computer.howstuffworks.com/c-programming.htm
http://www.cprogramming.com/tutorial/c-tutorial.html
https://www.tutorialspoint.com/cprogramming/cprogramming_tutorial.pdf

[rstofer]

I would think that you would start with the mid-range PICS and assembly language.  There's a lot to learn about the chips in that range and we just had a thread on it last week.  Went on for a long time... 

https://www.eevblog.com/forum/beginners/pic-microcontoller-programming-in-assembly/

When I started with PICs about a dozen years ago, there wasn't much in the way of free C compilers (cc5x was about it!) so it was assembly language or nothing.  That's not really a problem because we don't usually try to program a solution to world hunger for a mid-range PIC.  Programs are often only a couple of hundred lines of code so assembly language isn't such a drag.

I wish I could recommend starting with assembly language but due to the ugly architecture of the PICs, there are a couple of complications that make it difficult.  Truth be known, I wouldn't even recommend starting with PICs but that is another story.  In general, the C compiler takes care of the banking and paging problems.

Another story:  There is a version of the Arduino that uses a chip in a DIP configuration.  That means you can prototype and develop your project on the Arduino and then move the chip to your final project.  All you need to do is replace the chip and your prototype board is back in business.

https://www.arduino.cc/en/Main/ArduinoBoardUno

There is almost no chance you will need to use assembly language for the Arduino.  Everything that can be done with the chip has and it's all out there on the web.

If assembly language is the goal, you might as well start with the PIC.  Even though the architecture is ugly, the instruction set is small so there is less confusion about which instruction to use.  It isn't hard to choose when there are only about 30 of them.

[rstofer]

In the other thread, I made a comment about Read-Modify-Write.  This is the bane of programmers when changing bits in ports.  It is not clear to me that the C compilers handle it properly either.  I simply don't know...

As to C:  You should head in that direction as early as possible.  It's worth doing some assembly language just to get a feel for it but, ultimately, your code will be written in C.  Mid-range PICs are a horrible architecture for C compilers for the simple reason that there is no hardware controlled stack.   What stack there is is only 8 levels so passing parameters on the stack not only doesn't work, it wouldn't be enough even if it did.

Sooner or later, you will be looking at the assembly language output of the C compiler.  It is nice to be comfortable with the lower level code.

In the end, I think learning assembly language programming on the PIC is worthwhile.  Just to get a feel for low level programming.  As soon as possible, I would migrate to almost anything else and use C to code it.  I really believe that the Arduino is the platform of choice for beginners and for those of us that want results in a big hurry.

Arguably, the Arduino is coded in C++ but, for the most part, you don't deal with that other than when you declare objects.  The code itself is C.  C has been around for 45 years and it still rules for embedded programming.  And just about everything else!  Linux is written in C.  I'm just guessing but I suspect Windows is as well.  C is probably the most used language on the planet - right after Fortran (kidding, sort of...).

Some folks are starting with PICs simply because they are taking a course that uses them (see the other thread).  In this case, you have to go with the flow.  It does no good for your GPA to tell the professor the Arduino is better than the PIC.

[jamie297]

Thanks, loads of good info.

I realise it's a huge field to get into and just feel that I need to start somewhere - structured tutorials seem like a sensible option.
As you suggest I like the idea of having an introduction to assembly and C, knowing that C is the way forward long-term.

[rstofer]

You have to start somewhere, we all did.  Over time, skills and need increase.  There is always another processor to learn.

[KL27x]

In the other thread, I made a comment about Read-Modify-Write.  This is the bane of programmers when changing bits in ports.  It is not clear to me that the C compilers handle it properly either.  I simply don't know...

It may have been awhile since you programmed any PIC in assembly. On modern devices, you don't have to write to any port, anymore, unless you are doing something very strange. All of the PICs made in the last decade have a separate latch register which you would write to. You can do any bitmask or manipulation you want, directly to the latch register, with no concern over read-modify-write error. You would normally only ever read the port to see what the physical state is. (But you can also read the LAT register, and you can technically still write directly to the port or even do bit manipulations there, if you wanted to do it the old way and see what a read-modify-write error looks like).

I'm sure C compilers handled the old port registers just fine. It was not difficult for a compiler to do that. (And a compiler that didn't handle it correctly would have been totally useless. ) I bet some of them still do it the old way, even with the lat register available on the newer devices. Depends on how much they have optimized for newer devices.

[rstofer]

In the other thread, I made a comment about Read-Modify-Write.  This is the bane of programmers when changing bits in ports.  It is not clear to me that the C compilers handle it properly either.  I simply don't know...

It may have been awhile since you programmed any PIC in assembly. On modern devices, you don't have to write to any port, anymore, unless you are doing something very strange

This is true!  I haven't messed with PICs since I played with the 16F877A about 12 years ago.  Reading the port reads the pins, writing the port writes the latch.  There is no facility (AFAIK) to read the latch.  This also applies to my favorite variant, the 16F628A

Reading the PORTA register reads the status of the
pins, whereas writing to it will write to the port latch. All
write operations are read-modify-write operations.
Therefore, a write to a port implies that the port pins are
read, the value is modified and then written to the port
data latch

I agree, it depends on which PIC you are using and newer versions may get around the Read-Modify-Write issue.  It is still included as a topic in the Mid-Range Family manual so it must still apply to some chips.  The fact that newer chips allow read access to the latch kind of indicates just how ugly this was in the older chips.

I don't know that the early compilers were smart enough to create a shadow register.  Maybe...  I think programmers were smart enough to work around it.

The PIC 16F family is old news.  Therefore, many of the tutorials and development boards are going to be based on older chips where Read-Modify-Write is still an issue.  How many 16F84A projects are still out there?

[Buriedcode]

I'm unsure why others are talking about assembly.  The instruction set for low to mid-range PICS is probably the easiest to learn of all micros, plus it makes a fair bit of sense.  But I think learning assembly would probably be a waste of your time - go straight to C.

I coded in assembly for a few years (over a decade ago) whilst most had moved on to C, and yes, in some ways assembly produces small, and faster code, but there isn't much of a difference and it only matters when you are doing extremely fast things (in which case there are faster and cheaper micro's to use) or running out of program space (in which case there are cheaper micro's.. with more flash!).

I mean, assembly is still "programming" and probably a bit more intimate with the hardware but I don't think it will 'help' you in any way.  Although those tutorials look as good as any other, I found the best way to learn a micro is to think of several projects, ones I don't know how to do, and get started. Especially something useful and cool - something you can actually use!  Something with inputs and outputs etc..

[Ian.M]

The Read-Modify-Write effect is still a problem for any PIC that doesn't have accessible LATx registers (Baseline 12 bit core, and original Midrange 14 bit core).  XC8 and most other C compilers don't do anything to mitigate the effect - coding shadow registers is almost invariably left to the user. See RMW and solutions for it

If you cant code in assembler, you have no way of determining the cause of unexpected failure of your C code.   You can test the algorithm on another platform, and when it works there but not on a PIC, you will be at a dead loss.  If you understand assembler, you can inspect the listing file or the disassembly to determine what code is being generated for a particular line of C and why it is misbehaving.   Either you will discover the unjustified assumption you have made or you may find you have run into a limitation of the compiler or hardware.  Very rarely you may discover a hardware fault or compiler bug and once in a blue moon, it will be a new reproducible silicon or compiler bug that you should report.

You don't have to be fluent in assembler, but you should know the instruction set welll enough to be able to sight-read a listing without having to look up individual instruction behaviour, and familiar enough with common techniques that you don't have to puzzlew them out with pencil and paper to understand them.  The easiest way of developing the required competence is to work your way through the Gooligum assembler tutorials and code some small projects of your own.  Then for %DEITY%'s sake switch to C - its a much more profitable use of your time . . . .

[jpanhalt]

Short version:
- How do you rate Gooligum dev board and tutorials?

They are good.  The only reservation I have is he switches to Relocatable code rather early on.  Many Assembly programs use Absolute for most everything.  (Let's not add that discussion to well worn C vs. Assembly discussion.)

- Are there any alternatives I should consider for a similar budget?

These are the two I used when I started:
http://www.amqrp.org/elmer160/lessons/
http://winpicprog.co.uk/pic_tutorial.htm

I particularly liked  Elmer160.   My only criticism of Nigel's tutorial is that he introduced a character (namely "$") without defining it first.  A nit pick for sure.  But, it does take time to find out what it means, if you are a complete novice.

Some advice: Don't try to follow multiple tutorials at the start hoping to get the best of each.   Pick one and go with it, until you get blinking LED's and start writing your own project.

- Should I hold off and learn basic C programming before getting the Gooligum stuff?

No comment.   That argument is like solving the Gordian knot.

John

[picandmix]

- How do you rate Gooligum dev board and tutorials?
- Are there any alternatives I should consider for a similar budget?
- Should I hold off and learn basic C programming before getting the Gooligum stuff?

Thanks for your wisdom 

Think I would suggest you start with Assembly code , it may seem complicated to look at now, but it is not difficult once you get started and the understanding  of the micro system it gives you will always be useful for C or any other micro system/language.

Gooligum tutorials used to be free, but seems many are now chargeable, so as said, perhaps worthwhile looking for other free ones.

The dev board seems expensive, but if thats your thing, then also look at the MikroE boards.

You do not mention how you are with hardware ?  can you solder, build circuits etc etc ?  if so building your own basic dev  board, either wired or pcb is possible.

Also no indication if you have any particular interest  towards specific areas for applying a micro, like robotics, RF , comms, control etc.

Everyones different, but I usually find its easier to learn a new system if you have a project in mind.

Its surprising how much you can do on a breadboard  with just a pic chip and a few components and wired to a 16x2 lcd.

[Paul Price]

Learning assembly is a waster of time to learn C-language..it isn't C-language and much harder to decipher any code  you write past the most simple of intention. Assembly is also specific to the device family and mfg. of the mcu your are working with and is thus learning so much is learning nothing if it is not-portable to another device.

You shouldn't waste a dime paying for a C-course, there are many free C courses available online  that are excellent, you can also learn a lot just from Youtube vids.

If you wanted to learn how to ride  a bicycle, I wouldn't ask you to first take a course in designing  bicycle chains.

Get a solderless breadboard and a DIP PICC chip, something like a PIC16876A or PIC16F886 in a DIP socket you can plug into a breadbroad. This chip doesn't require you to learn complicated code to turn on and off a pin, no LAT required, when you turn a port pin on  it only requires one instruction.
These two chips are very popular and their is much code published in C on the web and much more even  to be found on Microchips forum, and if you need help, it is easy to get help and  learn from others on many forums regarding these two popular chips.

The best way teacher is experience, and when you write some code in C to do something, like even detect a switch, debounce it and toggle the light of a LED, you can study the C-language, write the code, then compile and burn it to your chip and then is it so easy  to check to see if your code is correct on a solderless breadboard in seconds.

Direct feedback between theory and practice is the most enjoyable way to learn.

[Paul Price]

Learn C from the Mass. Inst. of Tech Free:

http://www.embedded.com/electrical-engineer-community/general/4402974/Free-MIT-online-C-programming-course

or else
http://www.learn-c.org/

EDX gives a very nice free course in embedded MCU C
 https://www.edx.org/course/embedded-systems-shape-world-utaustinx-ut-6-10x

[gooligumelec]

They are good.  The only reservation I have is he switches to Relocatable code rather early on.  Many Assembly programs use Absolute for most everything.

Yes, and starting off with relocatable code was one of the main goals for the tutorials.  I found it painful to see all these tutorials out there showing the old way of doing things, for no good reason.  Relocatable isn't any harder if it's what you start with - why not let the tools handle the details?  And then when your code grows, and you start reusing modules, it's so much easier.  So might as well just start with good habits - it doesn't cost anything.

Mind you, for anything non-trivial I'd use C these days, so the relocatable/absolute argument becomes less persuasive.  I still stand by starting with relocatable code though.

[gooligumelec]

- How do you rate Gooligum dev board and tutorials?

Very highly!    

- Are there any alternatives I should consider for a similar budget?

People starting out with the tutorials will soon need to find another dev board, because I only have three left in stock and I don't intend to have any more manufactured.

Other dev boards don't tend to have the 3 x 7-seg displays (they are used to teach about lookup tables and using interrupts to drive multiplexed displays), or a variable frequency oscillator (a venerable 555, used to teach about interval timing and such), but these things aren't hard to breadboard if you have the parts.

- Should I hold off and learn basic C programming before getting the Gooligum stuff?

The Gooligum C tutorials assume a working knowledge of C, so best to be familiar with it first.  That said, it's easy enough to pick up as you go.

[austfox]

People starting out with the tutorials will soon need to find another dev board, because I only have three left in stock and I don't intend to have any more manufactured.

I’m the owner of one of your development boards. Because it ties in well with your tutorials, have you considered extending their life by putting the gerbers in public domain?

[ebclr]

I don't recommend wasting your time learning legacy CPU's got to arm or RISC-V your investment will have a better ROE than with legacy Pic's

[gooligumelec]

I don't recommend wasting your time learning legacy CPU's got to arm or RISC-V your investment will have a better ROE than with legacy Pic's

Yeah, it depends what you're trying to achieve.  Certainly it doesn't make much sense to use an 8-bit PIC as the main MCU in most new projects.  Your typical STM32 (or insert other ARM) clearly blows them away in price/performance.  They can still make sense as an I/O processor though, e.g. suppose you're building a device with a bigger ARM and it's going to run Linux.  Although your main CPU is going to have a lot of smart peripherals and DMA that limits the need for low latency realtime response, there are still situations where a tiny PIC hanging off the side to handle something that's timing critical can be an appropriate solution.

But as for learning - that's another matter.  Sure, it can seem a waste to learn about simple 8-bit PICs, but the key work here is "simple".  Data sheet for the 10F200 (which the Gooligum course starts with) is less than 100 pages, compared with > 1000 for your typical ARM part.  The architecture and programming model are simple, as are the peripherals such as timers.  You can get your head around the whole part.

When you then move on to something bigger and more modern, that you'd actually use in a practical design, it's easier to take in because you've seen some of it before, in a simpler form.

That's the theory, but it worked for me.

[Jan Audio]

Dont you have something else to program ?
Try DOS first ( console application ).