T&L Publications

I've been trying to use asm code written for a PIC12C508 on a PIC10F206 (modified of course). I can't seem to get it to load. It compiles fine but I get errors when I try to write it to the chip. I'm using MPLab IDE v7.00 and a PICSTART Plus w/ firmware version 4.30.4.<p>The purpose of the program is to generate a 38kHz pulse output to an IR led. I have a PIC10F206 and I would like to use it instead of the 555 oscillator circuit that I originally intended to use. Ultimately I would like to pulse a right and left channel LED 180 degrees out of phase with each other. For now I would be happy to pulse one led. <p>The error log looks like this:<p> <blockquote><font size="1" face="Verdana, Helvetica, sans-serif">quote:</font><hr>
PICSTART Error Log File
26-Dec-2004, 15:10:34<p>Device Type: PIC10F206
Address Range 0-1b<p>
Program Memory Errors<p>Address Good Bad<p>0000: 0205 3FFF
0001: 0CFD 3FFF
0002: 0006 3FFF
0003: 0426 3FFF
0004: 0000 3FFF
0005: 0000 3FFF
0006: 0000 3FFF
0007: 0000 3FFF
0008: 0000 3FFF
0009: 0000 3FFF
000A: 0000 3FFF
000B: 0000 3FFF
000C: 0000 3FFF
000D: 0000 3FFF
000E: 0000 3FFF
000F: 0000 3FFF
0010: 0000 3FFF
0011: 0000 3FFF
0012: 0000 3FFF
0013: 0000 3FFF
0014: 0000 3FFF
0015: 0000 3FFF
0016: 0526 3FFF
0017: 0000 3FFF
0018: 0000 3FFF
0019: 0000 3FFF
001A: 0000 3FFF
001B: 0A03 3FFF<p>
Configuration Bits Errors<p>Configuration Setting Expected Received<p>Master Clear Enable Functions as GP3 Functions as Master lear<p>
Calibration Memory Errors<p>Address Good Bad<p>01FF 0C00 3FFF
<hr></blockquote><p>I suspect the error is in the "defines" section but frankly I know almost nothing about ASM for the PIC. If the basic compiler that I use was able to program the 10F series I would know less than I do now That said, I am suddenly and painfully aware of the need to learn ASM.<p>Here's the ASM file listing:<p> <blockquote><font size="1" face="Verdana, Helvetica, sans-serif">quote:</font><hr>; 38kHz Oscillator---12/26/04
;
#include <p10F206.inc>
__CONFIG _CP_OFF & _MCLRE_OFF & _WDT_ON & _IntRC_OSC
;<p>#define port B'11111011'
;
org 0x00
movfw OSCCAL
movlw port
tris GPIO
;
BEGIN
BCF GPIO,1 ;1uS
NOP ;2uS each nop is 1uS long
NOP ;3uS
NOP ;4uS
NOP ;5uS
NOP ;6uS
NOP ;7uS
NOP ;8uS
NOP ;9uS
NOP ;10uS
NOP ;11uS
NOP ;12uS
NOP ;13uS
NOP ;14uS
NOP ;15uS
NOP ;16uS
NOP ;17uS
NOP ;18uS
NOP ;19uS low on gpio.0
BSF GPIO,1 ;1uS Begin HIGH duty cycle
NOP ;2uS
NOP ;3uS
NOP ;4uS
NOP ;5uS
GOTO BEGIN ;2uS (26uS total for 38KHz)
END<hr></blockquote><p>When I change the Master Clear Enable function in the Configuration Bits menu it always reverts back to the same thing? Where is that happening in the code?<p>Any help would be greatly appreciated. I"ve spent the better part of this day getting to this point.<p>Thanks<p>Mike
NE5U

Hi Mike<p> I am no expert in .asm but I do a little programming from time to time so some of my comments might not help.... I have downloaded MPLAB 7.00 recently and I ran into some problems with the debugger when I tried to use the "Stimulus" function. I contacted their Tech Support and they have been of no help at all, it used to be much better though, so I went back to MPLAB 6.40. Microchip has a forum on their products and I seems that there is quite a few people that have problems with MPLAB 7.00. Here is my first dumb question, have you selected the right device in "Configure>>Select Device". Second question, is OSCCAL a register, if not it might need to be defined. There might be an error in the way you typed the __CONFIG line of instruction. There is an easy way to configure the "Configuration Bit", it is by going to "Configure>>Configuration Bits", by doing it this way, you avoid typo and syntax errors. When you want to generate a delay, there are two convenient functions called DECFSZ or INCFSZ which loop on themselves until a condition is met. Let me know if it helped (I doubt) or if there is an improvement.<p> Good luck
Marc

Thanks Marc,<p>Well... Believe it or not I "Crashed" my way thru it and the program is loaded. I think. It had something to do with the programmer setup. There is a Settings selection at the bottom of the drop down for Programmer. Inside that is a Memory selection. Auto / Manual and some checkboxes. Basicly I selected No Memory settings other than ??? I forget... Config bits?? or something like that. I had to change my settings in the command line to match what the software was doing (I think)... Anyway... it's loaded and on the breadboard. This one little thing took all freakin day I'll probably "step away from the Microchip" and finish the breadboarding tomorrow...<p>Thanks for the response.

I program my microcontroller with an modified project I got form an article in Poptronics, so imagine the fun I have....Recently, I started a new project and my MPLAB 6.40, that I just reloaded in another computer, didn't work, it took me about 4 hours to find the problem only to find out that I couldn't fix it, that's why I downloaded MPLAB 7.00 and spent a couple of hours trying to get it to work and exchanging Emails with Microchip Tech Support. When I couldn't get it to work, I went back to MPLAB 6.40 and work around the my original problem. Altogether I must have wasted about 8 hours, so to me, you did pretty good...<p> Take care

Learning new software can eat up a lot of time. Even if it's just a new version of the same ole same.<p>I'm still trying to figure out why but the oscillator program output is very unstable in frequency. I'm starting to wonder if it's the 'scope. It should be a good instrument (50mHz Fluke 97) but there were stability issues with the 555 timer circuit that I built too. I don't have any way to check the scope though. I'm powering the circuit with a 9V battery (thru a voltage regulator) so it's not a power supply issue. I don't know. Maybe I need some magic smoke to put into the circuit

I have done a circuit involving a PWM for a friend and the frequency was very stable. I noticed that you put the label BEGIN at the top of the list of code, I don't know if it is like that in the program but it is recommended that the label is at the very left of a column and the codes should be a few spaces to the right, like 8 spaces, for example. I don't know how familiar you are with programming in general or assembly in particular, but I know that a program can work but not do what it is supposed to, although it is usually the other way around...

<blockquote><font size="1" face="Verdana, Helvetica, sans-serif">quote:</font><hr>Originally posted by connect21:
I have done a circuit involving a PWM for a friend and the frequency was very stable. I noticed that you put the label BEGIN at the top of the list of code, I don't know if it is like that in the program but it is recommended that the label is at the very left of a column and the codes should be a few spaces to the right, like 8 spaces, for example. I don't know how familiar you are with programming in general or assembly in particular, but I know that a program can work but not do what it is supposed to, although it is usually the other way around...<hr></blockquote><p>
It's just the way that the cut and paste worked. MPLab tells you if there is a directive in the wrong place when you compile the code. <p>I've done some VB programming. I used to hack around with assembly but I've never written anything. It's one thing to trace and quite another to write.<p>Tech Support replied to my question... Let's just say that they were no help. In fact, here, look at this-<p> <blockquote><font size="1" face="Verdana, Helvetica, sans-serif">quote:</font><hr>Problem Resolution:
I don't think you have a code problem. You could run the simulator to check that. Your error log is telling you the chip isn't programming, not that there is a bad program - the software can't tell if you write bad code, it can only tell you if the code you did write went in the part or not. You need one of these to program a 10F in the PS+:<p>PIC10F2XX Universal Programmer Adapter
Part #: AC163020<p>http://www.microchip.com/stellent/idcpl ... m=en021325
<hr></blockquote><p>They want me to buy a programmer adapter yet the program appears to have loaded fine. I'll cut them a little slack though. It's hard to read someone elses code and immediatly follow what their intentions were. On the other hand, how could I get a verification from the software if the code didn't load?

Well... Lessons learned. It turns out that you can't program the new 10F20X PIC with the PICStart Plus programmer UNLESS you buy their little $36.00 adapter for the 10F20X chip. At least it does SOT and PDIP. Now here's the really strange part. The MPLab 7.0 software gives me a verify when I download the program to the chip. It thinks that the download was successful. Considering the way that the chip is operating I can't say what is in it but I know that it's not doing what it's supposed to. If it wasn't so funny I would be irritated that I wasted over a day jacking around with this stuff. On the other hand, I learned something so I guess it wasn't a waste after all.<p>On another note- I have been test driving the Hi-Tech C compiler (because of an article in N&V). Maybe I'm a spoiled computer user and maybe it's a jam-up compiler but when software runs in a DOS window and it's almost the year 2005 I can't help but wonder how they can charge so much for the full version. It's 3 times the cost of other Windows based C compilers (Full ANSI C) and because it's a DOS app running in a Window, it's clunky. It's like running Space Invaders on an XBox. You can do it but why would you want to?<p>Merry New Year Ya'll

ROFL... this is getting to be pretty funny. Guess what? You CAN program a 10F20X PDIP if you align pin 1 with pin 9 of the PICStart. It makes a pretty good 38.5 kHz oscillator...

Sorry I didn't read this sooner. The picstart problem with the 10Fs is known about, wish i could have saved you some time.<p>The code doesn't actually set the config bits, the programmer reads them and sets them. Your programmer *should* be able to override the config bits.<p>The microchip forums were mentioned. I have to say, I've found them only of moderate help. Lots of people who basically don't know the answer seem to want to see themselves post. sigh. The one problem I posted a question on got mostly responses on my style of coding and minor issues that had nothing to do with the problem. Several suggested wildly different approaches. sigh... I wound up figuring it out on my own (as it should be!).<p>By the way, you are TRISing all but GPIO.2 for input. Is that what you wanted? From your code, I think you want to set them all for output - especially GPIO.1 which is what your program twiddles. Generally, its not a good idea to set PIC pins for input unless you have them hooked up to something (or grounded via a resistor) - lots of issues around unused pic pins.<p>Also, I assume you know this but your frequency is actually 38.4Khz. Most IR receivers can handle that but it is > 10% off. You could perhaps fuss osccal to get it closer with a little experimentation if it matters to you.<p>Finlly, with the WDT on, the pic will reset itself every so often (could be as little as 100s of mS or as much as a couple of seconds) since you dont clear wdt. That will impart some odd little disturbences in the IR output and perhaps make your scope look unstable.

When I used to contact Tech Support, I was always dealing with the same guy and he was very very good, but it seems to have changed and I am not getting any good answer from them yet, I suppose that they will ajust....

I agree on your take on the Microchip board. I stumbled on to the answer in the programmer section. In fact someone referenced the original poster to my post telling him that I had succeeded. I hadn't but I thought that I had. Finally towards the end of the post someone referenced the Readme document (I never read those )<p>The code changed from what I originally posted. It had too The oscillator, on average, is running at about 38.4 kHz... Now where have I seen that number before? <p>I don't think that it's driving the LED. I don't remember the numbers but the voltage out of the dropping resistor was something like 0.2V and I only got sporadic output from the receiver.<p>Here's the semi-final code. It has at least one line of trash in it that isn't hurting anything.<p><blockquote><font size="1" face="Verdana, Helvetica, sans-serif">code:</font><hr><pre>; 38kHz Oscillator---12/26/04
;
PROCESSOR 10f206
;
#include <p10F206.inc> ; processor specific variable definitions

errorlevel -302 ; suppress message 302 from list file<p> __CONFIG _CP_OFF & _MCLRE_OFF & _WDT_OFF
;
#define port B'11111100'
#define LCLED GPIO,0 ; Define Left Channel LED as port 0
#define RCLED GPIO,1 ; Define Right Channel LED as port 1
;
org 0x00 ;
movwf OSCCAL ; Load factory oscillator calibration value
movlw port ;
tris GPIO ;
clrf 7 ;
;
BEGIN
BCF RCLED ;1uS
NOP ;2uS
NOP ;3uS each nop is 1uS long
NOP ;4uS
NOP ;5uS
NOP ;6uS
NOP ;7uS
NOP ;8uS
NOP ;9uS
NOP ;10uS
NOP ;11uS
NOP ;12uS
NOP ;13uS
NOP ;14uS
NOP ;15uS
NOP ;16uS
NOP ;17uS
NOP ;18uS
NOP ;19uS high on gpio,1
BSF RCLED ;1uS Begin HIGH duty cycle
NOP ;2uS
NOP ;3uS
NOP ;4uS
NOP ;5uS
GOTO BEGIN ;2uS (26uS total for 38KHz)
END ; End of Program
</pre><hr></blockquote>

I haven't used the 10 or 12F parts, but are you sure that you've saved the OSCAL value?<p>I know mChip have changed the the OSCAL from being in EEPROM to actually living at a special address now.<p>Colin

555 or small PIC running a loop program, I don't see how you'll syncronize the detectors to "look" for reflected IR when the associated LED is on.<p>If I understand what you're doing, I'd use a bigger PIC. Set timer() to interupt every 13uS.
; psuedo code
(on interupt from timer jump to next)
IF flag = 0
turn on left LED
NOP ;time for LED to come on
NOP ;and detector state to settle
get left detector
turn off left LED
ELSE
turn on right LED
NOP
NOP
get right detector
turn off right LED
END IF
TOGGLE FLAG
GOTO WAIT FOR INTERUPT LOOP
;end<p>the wait loop can execute other code, as long as its done before next timer interupt.<p>0.2V across LED dropping resistor, measured by DMM, may be okay considering 23% duty cycle of your current code and frequencies involved. Hard to get by without a 'scope for this kind of work isn't it?<p>C U L -<p>[ December 28, 2004: Message edited by: Dale Y ]</p>

Colin- Yes, OSCAL is defintely zero'd by this line"
<blockquote><font size="1" face="Verdana, Helvetica, sans-serif">code:</font><hr><pre>movwf OSCCAL ; Load factory oscillator calibration value</pre><hr></blockquote>. I had to put the ORG0x00 statement in front of the movwf before it would zero though. From what I understand about the ORG (origin) statement, that doesn't really make sense but it worked. I can watch the program run and the registers in MPLab. That's how I know that the OSCAL is set to zero. That and the oscillator is working fine.<p>Dale Y- The design comes from a book called Insectronics. The author used a 555 to simultaneously fire two IR LED's oriented to 45 degrees and 315 degrees respectively. There are two detectors oriented in the same direction. Each output leg of the detector is fed back to a PIC 16F84 that is controlling movement servo's for the "bug". I went with the PIC10F206 because I had it and I didn't like the way that the 555 oscillator circuit worked. The PIC is cleaner than a 555 circuit. Because of posts like those from Philba and yourself I'm beginning to realize that the author chose a crude method of IR detection to implement. Probably becaue it is simple to understand. The next step in the book is an ultrasonic xmitter / receiver to replace the IR system.<p>I have an oscilloscope (Fluke 97 borrowed from work). There is a square wave on the input to the led (but I can't remember what the readings were at the moment other than f=38.4kHz.) As a test I replaced the IR Led with a red LED and it's not lighting. That's why I checked the voltage.<p>73<p>Mike<p>[ December 28, 2004: Message edited by: NE5U ]</p>