[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
gpasm numbers
From: Craig Franklin ####@####.#### Date: 24 Aug 2004 05:52:37 +0100 Message-Id: <4129DA4D.40905@users.sourceforge.net> A few questions have come up recently about gpasm number representations. Section 3.2.3 of the gputils manual covers numbers for gpasm. This section recommends that you represent all numbers using the formats: base general syntax 21 decimal written as =============================================== binary B'[01]*' B'10101' octal O'[0-7]*' O'25' decimal D'[0-9]*' D'21' hex H'[0-F]*' H'15' hex 0x[0-F]* 0x15 There are several other legacy formats that gpasm supports for mpasm compatibility. Most of these formats have shortcomings. For example "21d" is another way to represent "21 decimal". The problem is that 'd' is a hex character so "21d" could also mean "0x21d". So gpasm uses the same hack that mpasm does, if the default radix is hex, "21d" is a hex number, otherwise it is decimal 21. This is one example, there are many more. So please don't use the other representations. Using the numbers above are also immune to an inadvertent default radix change. I don't recommend relying on the default radix for your code to assemble correctly. There are too many ways that it can cause problems. There is one real bug in gpasm's number representations. Certain numbers like "14000" are treated as processor names instead of numbers. This is a hack that really needs to be fixed. I haven't had time. Although if you use one of the recommended representations in the table above you won't have a problem. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
gpasm numbers
From: pico ####@####.#### Date: 25 Aug 2004 00:32:04 +0100 Message-Id: <412BCFDA.5060306@sourceforge.net> Additional note: The most misleading thing about numbers in gpasm is that the default radix is HEX and not DEC as in many other assembler. Microchip application notes requires, especially the math related, that the default radix is decimal.The same apply for third part code. The gpasm manual don't explain that the default radix is hex in the section related to numbers. Instead it's explained in the section regarding command line arguments. As explained in the previous mail, some of the numeric representations explained in the gpasm manual don't work. One simple example: #define KH *1000 #defime MH KH KH ; set processor speed #define CLK 4000000 ; or #define CLK 4MH ; set timer0 prescaler #define TM0PRE 16 ; set prescaler to 16 - minimum is 4 delay_ms: ; ARGS: 0-256 = W ; VARS: _tmp ; RET : W = 0 ; NOTE: destroys the W register and set Z. C is untouched. ; timer0 must be started before enter this pice of code. ; otherwise this is a non returning call. ; DESC: delays 0-256 milliseconds ; HOOK: idle_1ms #if CLK / TM0PRE / D'1000' > 0xff #error "Prescaler in timer0 out of range" #endif movwf _tmp skipnz retlw 0 movlw ( CLK / 4 -4 ) / D'1000' / TM0PRE movwf tmr0 call idle_1ms ; idle task called every ms in a time loop movf tmr0 skipz goto $-2 goto delay_ms+1 The result is a 3 or 4 time longer delay. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: gpasm numbers
From: Craig Franklin ####@####.#### Date: 25 Aug 2004 05:18:35 +0100 Message-Id: <412B23D5.4060908@users.sourceforge.net> pico wrote: > Additional note: > The most misleading thing about numbers in gpasm is that the default > radix is HEX and not DEC as in many other assembler. I don't know which default radix is most common. I know some that are hex and some that aren't. Good thing it is easy to change the radix if you want. I like to do all my stuff in octal :) > Microchip application notes requires, especially the math related, that > the default radix is decimal.The same apply for third part code. If they do that, they should use the radix directive in their code. Especially when you consider that their assembler defaults to hex. Tell which app notes and I will send them a bug report. > The gpasm manual don't explain that the default radix is hex in the > section related to numbers. Instead it's explained in the section > regarding command line arguments. At least it is in the manual. I agree that it should also be in the numbers section of the gputils manual. I will add it. It is also reported in the help message if you command "gpasm -h". > As explained in the previous mail, some of > the numeric representations explained in the gpasm manual don't work. > You need to be more specific. AFAIK, all representations work as documented in the manual. I also believe that gpasm passes all of the numeric regression tests provided by Microchip. Some of the representations are flawed by design. Like the "21d" example. This isn't gpasm's fault. These representations are supported for mpasm compatibility only and are not recommended. > > One simple example: > > #define KH *1000 > #defime MH KH KH > ; set processor speed > #define CLK 4000000 > ; or > #define CLK 4MH > ; set timer0 prescaler > #define TM0PRE 16 ; set prescaler to 16 - minimum is 4 > > > delay_ms: > ; ARGS: 0-256 = W > ; VARS: _tmp > ; RET : W = 0 > ; NOTE: destroys the W register and set Z. C is untouched. > ; timer0 must be started before enter this pice of code. > ; otherwise this is a non returning call. > ; DESC: delays 0-256 milliseconds > ; HOOK: idle_1ms > #if CLK / TM0PRE / D'1000' > 0xff > #error "Prescaler in timer0 out of range" > #endif > movwf _tmp > skipnz > retlw 0 > movlw ( CLK / 4 -4 ) / D'1000' / TM0PRE > movwf tmr0 > call idle_1ms ; idle task called every ms in a time loop > movf tmr0 > skipz > goto $-2 > goto delay_ms+1 > > The result is a 3 or 4 time longer delay. > With a quick look, I don't any numeric problems in this example. I do see some other problems. #defime is one. I am going to guess you are having problems with this line: movlw ( CLK / 4 -4 ) / D'1000' / TM0PRE That line doesn't assemble with mpasm. MPASM 03.80 Released TEST.ASM 8-24-2004 4:00:44 PAGE 1 LOC OBJECT CODE LINE SOURCE TEXT VALUE 00001 processor 16f877 00002 00003 #define KH *1000 00004 #define MH KH KH 00005 ; set processor speed 00006 ;#define CLK 4000000 00007 ; or 00008 #define CLK 4MH 00009 ; set timer0 prescaler 00010 #define TM0PRE 16 ; set prescaler to 16 - minimum is 4 00011 00012 Warning[225]: Invalid label in operand (MH) Error[112] : Missing operator 0000 3000 00013 movlw ( CLK / 4 -4 ) / D'1000' / TM0PRE 00014 00015 end If you put a space in the CLK macro and change the radix to decimal, it works in mpasm and gpasm. MPASM 03.80 Released TEST.ASM 8-24-2004 4:01:09 PAGE 1 LOC OBJECT CODE LINE SOURCE TEXT VALUE 00001 processor 16f877 00002 00003 #define KH *1000 00004 #define MH KH KH 00005 ; set processor speed 00006 ;#define CLK 4000000 00007 ; or 00008 #define CLK 4 MH 00009 ; set timer0 prescaler 00010 #define TM0PRE 16 ; set prescaler to 16 - minimum is 4 00011 00012 0000 303E 00013 movlw ( CLK / 4 -4 ) / D'1000' / TM0PRE 00014 00015 end Keep in mind that the mpasm's preprocessor isn't an ANSI C preprocessor, so some things that you are use to won't work. If you need those features use an external preprocessor. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ####@####.#### > For additional commands, e-mail: ####@####.#### > > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |