Post by thread:[PIC] Assembly language problem

Hi, I'm new to the list and would greatly appreciate help. My program seems to lockup in the "r1" loop: ee_read movwf EEADR bsf STATUS,RP0 bsf EECON1,RD r1 btfsc EECON1,RD ; Wait to finish read. goto r1 bcf STATUS,RP0 movf EEDATA,W andlw 07Fh return All is good when the loop is bypassed. Any ideas? Thanks Rob

Rob Blanchard wrote: {Quote hidden}> Hi, > > I'm new to the list and would greatly appreciate help. > > My program seems to lockup in the "r1" loop: > > > ee_read movwf EEADR > bsf STATUS,RP0 > bsf EECON1,RD > r1 btfsc EECON1,RD ; Wait to finish read. > goto r1 > bcf STATUS,RP0 > movf EEDATA,W > andlw 07Fh > return > > > All is good when the loop is bypassed. Any ideas? > > Thanks > > Rob > You don't need to loop-test the bit RD. It is always ready, you just have to put it into RD mode, and the data will be immediately available. err... why are you anding the data with h'7f'...? --Bob A

Thanks Bob A. So I can just remove the loop structure and all is good? It's not my code. I'm building a project that uses this code to turn on outputs based on MIDI note-on events. I traced the problem to this subroutine's loop. The original project calls for a 4MHz PIC, but I'm using a 20Mhz with a 4 MHz crystal. Could this cause this problem? The rest of the program works ok. The anding, I believe, is to keep the data <128. Rob >>> spam_OUTengineerTakeThisOuTcotse.net 10/2/2007 10:41 AM >>> Rob Blanchard wrote: {Quote hidden}> Hi, > > I'm new to the list and would greatly appreciate help. > > My program seems to lockup in the "r1" loop: > > > ee_read movwf EEADR > bsf STATUS,RP0 > bsf EECON1,RD > r1 btfsc EECON1,RD ; Wait to finish read. > goto r1 > bcf STATUS,RP0 > movf EEDATA,W > andlw 07Fh > return > > > All is good when the loop is bypassed. Any ideas? > > Thanks > > Rob > You don't need to loop-test the bit RD. It is always ready, you just have to put it into RD mode, and the data will be immediately available. err... why are you anding the data with h'7f'...? --Bob A

Rob Blanchard wrote: > Thanks Bob A. So I can just remove the loop structure and all is good? > > It's not my code. I'm building a project that uses this code to turn on > outputs based on MIDI note-on events. > I traced the problem to this subroutine's loop. The original project > calls for a 4MHz PIC, but I'm using a 20Mhz with a 4 MHz crystal. Could > this cause this problem? The rest of the program works ok. > > The anding, I believe, is to keep the data <128. > > Rob > > Yes, just try it directly.Here is code I use for PIC16F877A, which is similar to all PICs: readEE: bank2 ;a macro, sets RP1=1, RP0=0 movwf EEADR bsf status,RP0 ;bank3 bcf EECON1,EEPGD bsf EECON1,RD bcf status,RP0 ;bank2 movf EEDATA,W return That's all you need. --Bob A {Quote hidden}>> ee_read movwf EEADR >> bsf STATUS,RP0 >> bsf EECON1,RD >> r1 btfsc EECON1,RD ; Wait to finish read. >> goto r1 >> bcf STATUS,RP0 >> movf EEDATA,W >> andlw 07Fh >> return >> >> >> All is good when the loop is bypassed. Any ideas? >> >> Thanks >> >> Rob >>

Rob, On Tue, 02 Oct 2007 10:59:43 -0300, Rob Blanchard wrote: >... > The original project > calls for a 4MHz PIC, but I'm using a 20Mhz with a 4 MHz crystal. Could > this cause this problem? No, using an external timing source a PIC will work at any frequency from its maximum down to DC (at which point it won't get much done! :-) The only aspects to bear in mind when changing frequency are timing-dependant things such as serial communications, and of course if you're doing musical note generation, but as you're using the originally-designed frequency even these are OK in this case. Cheers, Howard Winter St.Albans, England

> Thanks Bob A. So I can just remove the loop structure and all is good? If it helps, this is working code with bank switching more apparent. Note that eepgd = 1 is to select Flash memory eeread bank0 movf eea,w ;address in eea variable, then W bank2 movwf eeadr bank3 bcf eecon1,eepgd bsf eecon1,rd bank2 movf eedata,w bank0 return

Howard Winter wrote: > > No, using an external timing source a PIC will work at any frequency from > its maximum down to DC (at which point it won't get much done! :-) > I have never completely understood the "DC" portion of the specification "dc to 20Mhz". Where could I get an explanation of this? ? If it is in a PIC data sheet then I have overlooked it. CR

DC means Direct Current, as opposed to AC, Alternating Current. This means no frequency, or zero Hertz. But it also means that the circuit works really slowly. Wed 2007/10/3, Charles Rogers <.....charles_rogersKILLspam@spam@att.net>: {Quote hidden}> > Howard Winter wrote: > > > > No, using an external timing source a PIC will work at any frequency > from > > its maximum down to DC (at which point it won't get much done! :-) > > > > I have never completely understood the "DC" portion of the > specification "dc to 20Mhz". Where could I get an explanation > of this? ? If it is in a PIC data sheet then I have overlooked it. > > CR > > -

On Oct 3, 2007, at 8:32 AM, Charles Rogers wrote: >> No, using an external timing source a PIC will work at any >> frequency from >> its maximum down to DC (at which point it won't get much done! :-) > > I have never completely understood the "DC" portion of the > specification "dc to 20Mhz". Some of the original microprocessors had internal circuitry vaguely similar to todays DRAM; some things were dependent on charges stored in internal capacitance that were subject to decay over time. As a result, these micros had a MINIMUM clock frequency for reliable operation as well as a maximum speed. Most of this went away when CMOS replaced NMOS and PMOS logic, so most of today's processors can be clocked arbitrarily slowly. This is useful for saving power, and in complex systems I suppose it can be useful for debugging external circuitry, and it might be particularly educational (imagine studying the external happenings on something like an 8051, with it's 12 clock cycles per instruction, one cycle at a time...) BillW

CR, DC just means that there is no lower limit on the frequency specification. The PIC is a static part. The ram and registers are static. They don't need To be refreshed. Some processors are dynamic meaning they need to be refreshed Periodically to retain the data. To get this periodic refresh, it has to occur at a certain interval. If you have a lot of cells to refresh, that all takes time. And to have enough time to do what is needed, you have to specify a mininum frequency For the clock so that this can happen. However, since the PIC is a static part, this doesn't need to occur. Therefore, you can specify down to DC, or No Frequency at all. For instance, you could, if you wanted to, run the PIC clock input at say 60Hz. If you did this, then your instruction cycle time would be ~64ms. Or you could Run it at say .005 Hz. This would make the instruction cycle ~800 Seconds. Now if you were to actually connect DC to the click input, you would never get Anything done, and your instruction cycle time would be infinite. You could use this to your advantage in some cases by halting the clock. Whatever condition the processor is in when you halt the clock will remain as long as there is power. When you resume the clock signal again, the processor would take off right where it left off when you turned the clock off. Hope this helps. Regards, Jim {Original Message removed}

On Wed, 2007-10-03 at 10:32 -0500, Charles Rogers wrote: > Howard Winter wrote: > > > > No, using an external timing source a PIC will work at any frequency from > > its maximum down to DC (at which point it won't get much done! :-) > > > > I have never completely understood the "DC" portion of the > specification "dc to 20Mhz". Where could I get an explanation > of this? ? If it is in a PIC data sheet then I have overlooked it. It means the PIC will work at any freq down to DC. At DC, it will stop, the point being it won't hurt the PIC, and is an acceptable (although kinda useless...) mode of operation. FWIW I have used this "feature" before, single stepping an I2C transaction clock by clock, using a multimeter after each clock pulse (before I had a scope). TTYL

On Wed, 2007-10-03 at 09:31 -0700, William "Chops" Westfield wrote: > so most of today's processors can > be clocked arbitrarily slowly. This is useful for saving power, and > in complex systems I suppose it can be useful for debugging external > circuitry, and it might be particularly educational (imagine studying > the external happenings on something like an 8051, with it's 12 clock > cycles per instruction, one cycle at a time...) Another area limiting the "down to DC" operation are analog type blocks like DLLs and PLLs. These blocks only have a limited frequency range at which they operate, and as a result the chip hosting them is usually speced to only run within that range. Even in a PIC, the sample/hold circuitry has a maximum amount of time after which the sample is no longer in spec, so although you can run the PIC at any speed you like, be aware that the ADC may no longer work accurately at the slower speed. TTYL

>> I have never completely understood the "DC" portion of the >> specification "dc to 20Mhz". Where could I get an explanation >> of this? ? If it is in a PIC data sheet then I have overlooked >> it. > DC means Direct Current, as opposed to AC, Alternating Current. This > means > no frequency, or zero > Hertz. But it also means that the circuit works really slowly. :-) For values of 'really' approximately equal to infinity. The point of them saying "DC to xxx" is that they are telling you that all the clocking is "static". ie there are no dynamic timing requirements which will stop working if you do them often enough or long enough at a fixed clock level. This means that you can, notionally at least, in the middle of a say 4 MHz clock stream, when the clock goes low, leave it that way for 100 uS, or 1 million or for a week AD that when you next raise it again and continue at 4 MHz the processor will just continue as if nothing has happened. Not all processors allow this sort of clock stopping and they will have a specified lower clock frequency below which you may (will when low enough) get dynamic timing problems. "Just stopping" a clock in mid oscillation can be harder that it may seem due to issues like ringing, loading etc. To do this you'd almost certainly need an external clock source. Just disconnecting and reconnecting the crystal is "unlikely" to produce a clean result. Russell

> I have never completely understood the "DC" portion of the > specification "dc to 20Mhz". Where could I get an explanation > of this? ? If it is in a PIC data sheet then I have overlooked it Fosc = 0. Obviously anything reliant on Fosc isn't going to happen. A PIC will run with a very slow, eg RC, clock, although the mA/ MHz does have a bottom limit. I guess you could arrange such a slow clock for some single-stepping diagnostic purpose. For example having the PIC select a large R with a 4066 at a particular point

Jinx, On Thu, 04 Oct 2007 16:10:38 +1200, Jinx wrote: > > I have never completely understood the "DC" portion of the > > specification "dc to 20Mhz". Where could I get an explanation > > of this? ? If it is in a PIC data sheet then I have overlooked it > > Fosc = 0. Obviously anything reliant on Fosc isn't going to happen. > A PIC will run with a very slow, eg RC, clock, although the mA/ > MHz does have a bottom limit. I guess you could arrange such a > slow clock for some single-stepping diagnostic purpose. For example > having the PIC select a large R with a 4066 at a particular point Indeed, or have a potentiometer for R so you can vary the speed as you like - there was a development board published by Everyday Practical Electronics (or one of its predecessors) which did this - I think it was one of John Becker's early designs. Or you could have an external oscillator with a logic gate feeding the clock to the PIC, so that you could just stop it with a logic signal if you wanted, and then step it slowly for debugging, using just a meter or LEDs. You could probably even arrange for the PIC to stop itself like this at a particular point, or have some external logic to detect a condition and stop it when it happens. Much cheaper than a logic analyser... Basically, it's not something you need very often, but having it available when you do is very handy! Cheers, Howard Winter St.Albans, England