That was Senor Martinez comment, not mine.
Max.

Fair enough. I wondered..
Agree on the colons, too.

 

Because, the LATA register (or "file", in this stupid thing) does NOT have an RA0 bit, but rather a LATA0 bit ... the compiler should've reported that as an error ...

The definition for RA0 and LAT0, which are both bit indexes, are the same (ie; 0) and that's why it works. Not sure if you'd want the assember to report it as an error because you'll often use an alias in your programs... for example;

#define spkr 0    ; bit index for piezo spkr on RA0


        bsf     LATA,spkr       ;
        DelayCy(10*msecs)       ;
        bcf     LATA,spkr       ;

 

The definition for RA0 and LAT0, which are both bit indexes, are the same (ie; 0) and that's why it works. Not sure if you'd want the assember to report it as an error because you'll often use an alias in your programs... for example;

#define spkr 0    ; bit index for piezo spkr on RA0


        bsf     LATA,spkr       ;
        DelayCy(10*msecs)       ;
        bcf     LATA,spkr       ;

I understand now ... thanks for pointing that out

 

I am guilty of not looking at the .inc file for this chip. The reason the bit indexes are interchangeable as Mike said is they are defined to be the same there.

;----- PORTA Bits -----------------------------------------------------
RA0              EQU  H'0000'
RA1              EQU  H'0001'
RA2              EQU  H'0002'
RA3              EQU  H'0003'
;----- TRISA Bits -----------------------------------------------------
TRISA0           EQU  H'0000'
TRISA1           EQU  H'0001'
TRISA2           EQU  H'0002'
;----- LATA Bits -----------------------------------------------------
LATA0            EQU  H'0000'
LATA1            EQU  H'0001'
LATA2            EQU  H'0002'
;----- ANSELA Bits -----------------------------------------------------
ANSA0            EQU  H'0000'
ANSA1            EQU  H'0001'
ANSA2            EQU  H'0002'
;----- WPUA Bits -----------------------------------------------------
WPUA0            EQU  H'0000'
WPUA1            EQU  H'0001'
WPUA2            EQU  H'0002'
WPUA3            EQU  H'0003'

Not only will RA0 work, but so will WPUA0! Makes me wonder why Microchip went to the bother of creating all those different labels. GladI am in the habit of just using the numbers or RA0

 

It’s so your code can read better. They’re just defining the individual bits in context.
bsf LATA, WPUA1 would generate valid code but wouldn’t make much sense when consulting the datasheet.

 

Because, the LATA register (or "file", in this stupid thing) does NOT have an RA0 bit, but rather a LATA0 bit ... the compiler should've reported that as an error ...

It would in C, but as RA0 and LATA0 both are defined as 0, it matters not in asm...

 

I dont know why you need to use assembler

I have learned the PIC RISC and it is akward
.

You may as well get used to the fact that there are some of us out there that prefer Assembly.
All you are doing is digging up the old issue and pitting one against the other.
Which usually ends up with acrimony and no one ever changing their minds.
Incidentally I have programmed in assembly since 1980's.
Max.

 

MOD Note:
hi guys,
The TS's Topic is:
Learning to program the PIC10LF322
Please keep your posts on topic.

Eric

 

+1
Off topic post removed.

 

@cmartinez
I got in the habit of adding the colon on labels, it helps in the process when doing a search for example and the label is used in a few places in the code.
Max.

Main:
               bsf        ADCON0,GO_DONE    ; start an A-to-D conversion
               call    InitLCD            ; Initialize LCD Special Function Registers
               clrf     Counter
               clrf    TMR1L
              clrf    TMR1H

Loop:
              btfss    INTCON,T0IF        ; TMR0 is preloaded so than this loop is exited every 23.4ms
              goto    Loop

I'm back ... and I'm glad this thread didn't degenerate into a meaning-of-life discussion, and also glad to see that off-topic comments have been removed ...

Anyway ... yes, I too always use colons on labels, except that I started this code by using someone else's code that I found online as a template. And the guy didn't use colons, so I assumed that was the proper syntax for this brand of assembly... so that makes it his fault, not mine ...

My next step will be to experiment a bit with timer and external interrupts. So stay tuned, I'll be back with more protocode and then take it from there... I need all the help that I can get.

 

Did you ever get the Gooligum directory/Index?
Max.

 

Did you ever get the Gooligum directory/Index?
Max.

Errrrr... nope ... but I did browse through the Assembler manual a bit, and corroborated what you said about the colons in labels, among other things. In fact, I have tons of questions regarding syntax. But that's gonna have to wait until I've given enough steps.

 

...And just to muddy the water, there is also Pseudo instructions!
http://picprojects.org.uk/projects/pseudoins.htm
Max.

 

I tested MPLAB X IDE's compiler with colons in its labels, and it worked just fine... then I tested it with colons on its labels, and the labels starting at a different column other than one, and the code was compiled correctly, but several warning were shown. Is there a way to tell the compiler not to report that sort of warning?

 

Another question, what is the "radix dec", or "radix hex" instruction/directive all about? Does it tell the compiler what the default numbering system is throughout the code?

 

Re: Colons
If you look in the MPASM User's Guide (DS33014L), you will see various acceptable ways to denote labels. I just use a separate line without a colon and depend on the label being in the first column. Older code seems to have colons, but most recent examples from Microchip, as in datasheets, don't use colons. So far as I know, it is just a preference.

And to add even more mud, some of those pseudo codes are now included as instructions and some of our old friends (like swapf and xorwf) seem to be on the way out:


From the 16F1788/9 datasheet. EDIT: ACTUALLY, IT THINK THAT IS AN ERROR IN THE DS. THERE ARE OTHERS. WHAT IS PROBABLY INTENDED IS "SUBWFB" WHICH IS AVAILABLE FOR ALL ENHANCED MID-RANGE CHIPS.

Radix dec means that when you write "10" is means ten. You don't need to write .10 or any of the other acceptable formats. The default radix is hexadecimal, I believe. So, if you define the radix as decimal, then when you mean hexadecimal, you need to write 0x0A for "ten". The guide is very useful for those things. Unfortunately, I did not save the link with my copy.

 

I tested MPLAB X IDE's compiler with colons in its labels, and it worked just fine... then I tested it with colons on its labels, and the labels starting at a different column other than one, and the code was compiled correctly, but several warning were shown. Is there a way to tell the compiler not to report that sort of warning?

Yes, you can use the ERRORLEVEL directive to suppress the warning. I would recommend that you NOT do that. Put the labels in column 1 like they belong; there is no valid reason to start them anywhere else, even though MPASM is OK with it.

The larger reason to not suppress the error has to do when you start to use macros. A macro invocation starts at >column 1 by design. If you misspell the macro, you will get the 'not column 1' warning as you should. If you suppress the warning, any misspelled macros will not expand and you don't get a warning. That non-expansion means that you have a big hole in your code where you expect the macro code to be. Without a warning (I think it should be an ERROR myself), you can spend a lot of time troubleshooting or, back in the OTP days, a lot of $$ blasting chips that won't run. Ask me how I know this.

Some good viewpoints re: colons here. Over time, I've adopted the label with a colon, on its own line and always starting in col. 1. I find it makes the code read better and differentiates labels from macro names. Plus in X, labels with a colon are a different color. Even easier. As you become more proficient in PIC assembler, you'll doubtless develop a style that fits your preferences but for now, I'd stay on the reservation.

EDIT:
I also would recommend using hex as the default radix then using the modifiers for other formats to explicitly identify the radix so that someone reading the code knows exactly what the number is. Older versions of MPASM actually allowed you to specify the default radix on the command line. Sheer lunacy! Take over a project without that tidbit of information can be .. problematic. Personally, I always explicitly specify the radix with the number regardless of the default so there is no chance of confusion.

 

Ok, this chip has two timers: Timer0 and Timer2 (what happened to Timer1? ). Timer0 seems like an extremely simple feature, looping endlessly through an 8 bit counter, and its only remarkable detail is that it can be prescaled by 8 different factors, from 1:2 to 1:256.

Timer2, on the other hand, also uses an 8 bit counter, but its reset value can be adjusted through a register named PR2. Also, it has a prescaler as well as a postscaler. Max prescaler is 1:64, while the maximum postscaler is 1:16.

Now for some numbers. At the maximum combination of register values, the longest value at which Timer2 will trigger an interrupt will be:
256*64*16/(Fosc/4) .... or is it 255*64*16/(Fosc/4) ?

Considering the first equation, and with the MCU running at 31 KHz, then the maximum programmable interrupt period is 33.83 seconds. Is that correct?

 

Considering the first equation, and with the MCU running at 31 KHz, then the maximum programmable interrupt period is 33.83 seconds. Is that correct?

Pretty much except I get 33.69sec. That's because PR2=255 on my sheet. Not sure if it works when set to 256 (00h).

 

Pretty much except I get 33.69sec. That's because PR2=255 on my sheet. Not sure if it works when set to 256 (00h).

it might not work at all ... but I'm sure as hell gonna test it ...