Arduino to the rescue

I think it was worth the effort to learn assembly, and to use PICs for experimental prototyping and the like. My biggest problem, though, is to get the PIC to 'talk' to the computer. It might not be too hard (everything is easy if you know how to do it, right?) but after reading several tutorials, a book (I did not read through the whole book, though, since I was hoping to find an easier way to gain the knowledge. Apparently, there are no short cuts to take, and I will just have to take the time it takes to read the book, and hopefully learn something new and interesting. But, since I do not have the time, or do not want to take the time, to read that book now, I opted to go with Arduino instead, which is about a 100 times easier when it comes to solve my problem. Again, what I could not figure out, was how to do the serial communication (or any other communication for that matter), which, in my opinion, is a crucial component when it comes to interactivity and usability in general. So, trying to do the same thing with Arduino, was more or less a piece of cake. I spent 3-4 hours debugging my code, though, since it behaved really strangely for a while, and it took me that long to figure out that it was not anything wrong with the code, but with my breadboard(!). Anyway, it did eventually work, and with that I could set up a simple interface with four potentiometers, making it really useful, at least in my opinion, for a lot of different applications.

Limits, indeed ...

Assembly is fun and interesting to learn. But, to make more complex programs with assembly requires far more experience and knowledge than I can possibly acquire in a few months. I have spent the last few days trying to figure out how to get an LCD-panel to work with a regular PIC (particularly the 16F690 which is the one I have been using lately), and it does not seem to be a problem to control an LCD-panel with this PIC, it is just that I can not find any examples of anyone using exactly this PIC for it, and I have not been able to successfully convert the few examples I have found from other PICs either. It shall be said, I have only tried to make this work in a software simulator (http://www.oshonsoft.com/pic.html), and it could be that I do not use this software as intended, thus not getting it to work. It seems to be a pretty nice piece of software, but as with all software, it has a learning curve to it. Anyway, what I decided to do, was to go back to my Arduino board, follow the tutorial found here: http://www.ladyada.net/learn/arduino/lcd.html, and see if I can get that to work. Of course, to make that happen, I once again needed to order some hardware (Futurlec.com is my friend), this time headers, both female and male. The result of that is of course that I will have to wait for a few days (between 5 and 10 they say) before I can actually start with the soldering etc. I any case, seeing how easy it is to control the LCD-panel with Arduino, especially after having the hardware done (which will have to be done in any case, either I decide to go with a PIC and assembly, Arduino or other platforms), I will definitively give that a try. When I got that working, I might try other options as well. I mean, it still sounds better to me to pay $5 for some hardware that will do exactly the same as some other hardware costing $35 (to $50 depending on if you want to use a 'shield' or not). And, as a third option (among several others), it is possible of course to use PICs with Basic or C, which also will make a lot of things much easier to do, than trying to do the same in assembly. I might actually look a bit more into what options I have for Basic, or even C, in the next few days, as I will be waiting for my hardware in any case ...

Memory? What memory?

Well, I know the memory is there, but how to get to it is the trouble. It is confusing for several reasons to me. First of all; there is more than one way to do it, but how and why they differ is not very well explained anywhere. First some general info from Microchip's PIC16F690 Data Sheet:

Data Memory is held in file registers. Instructions referring to file registers use 7 bits, so only 128 file registers can be addressed. Multiple file registers are arranged into “pages”. Two extra bits RP0 and RP1 (in the Status register) allow accessing multiple pages. These two bits effectively become the top two bits of the file register address. The additional pages may or may not be implemented, depending on the device.

So, this is the reason as to why we need to think about it at all, and then there is the means of how to do it. Again, from Microchip's, this time the "Low Pin Count Demo Board USer's Guide":

EXAMPLE 2-1: DEFINING DATA MEMORY

#define Length 0x20 ;c-like syntax

Length  equ    0x20 ;equate 0x20 with the symbol

   cblock      0x20 ;start a block of variables
Length              ;this will be at address 0x20
Width               ;this will be at address 0x21
Area:2              ;this is 2 bytes long, starting at address 0x22
Girth               ;this will be at address 0x24
   endc

So, here we can see three different ways of assigning variables to memory. But, there are other ways too. Here is an example from a template made by Microchip:

TEMP_VAR    UDATA
temp        RES   1    ;example variable definition

... and:

TEMP_VARS   UDATA_SHR
temp1       RES   1
temp2       RES   1

... where the difference is that UDATA_SHR stands for shared, which is all good, but nowhere can I find what that means in terms of being different from just straight UDATA, or any of the other options. Maybe this is unimportant altogether, but I feel like this is maybe the least well explained topic when it comes to basic PIC programming. Hopefully I will get the picture later.