AVR Freaks

I don't know how to measure worst case.

Think I'm under 160clk.

Is there a way to find the worst case with Atmel Studio?

Also, are you interested on average for numbers above two bytes?

You can convert a two bytes with another program, like your version.

So, fastest above 65535?

My atmega328p works on 16MHz.

With three bytes you can display your real frequency, in real time.

Three bytes maximum is 16.777215 M .

I'm also displaying the temperature above the Quartz, using the same uC.

The measuring is done using an UBLOX GPS signal.

I am counting my own uC clocks using Timer/Counter1 Capture Event,

250 times per second, on an Event raised by a GPS receiver.

In the same time I have a TWI connection with a thermometer,

and a 2Mbit full duplex UART connection ... and this is just the begining.

I have indeed a "too fast" conversion for hex to ASCII,

but the relative large length of my "routine" is not a problem;

and that is because I'm not using libraries.

I'm thinking on storing  frequencies on a temperature base,

 that is on TWI also. Some kind of auto-calibration.

Thank You.

I meant only on crystal. As far as I've seen the large drift is on temperature.

I guess there's no problem to "link" your device on UBLOX only once a year,

to corect your freq. on temp. table, due to the aging of the Quartz.

adt7422 is sensitive enough for an 0.1 degree step, so I'll have 40 bytes/degree;

meaning temerature + frequency. I would prefer to store this outside uC.

My code:

clr r18        ; max. 16 byte conversion to BCD
 cpi r16,10
  brlo PC+3
  subi r16,10     ldi r18,$10

  or r16,r18

First instruction should be erased; my mistake.

Your code is faster. I was just copying and paste (from my code above); not thinking.

Thank you.

 I know my code is hard to follow, because I had to debug it. As I've already said, it is cumbersome. I'm sorry.

There are very many remainders, so I've tried to give a general ideea on what the algorithm does.

If you'll let me know what you did understood, it might be a good start.

1. I've tested my code from 0(one) to 256^3-1, and it is working.

2. As you probably suspect, I'm working on interrupts, I do know what confusing a register might do to you.

3. I've worked with perforated cards and perforated tapes;

I've seen pencil cards but they didn't let us run the program;

they (the theachers) were doing only a visual inspection of the program.

4. If you want to see a program REALY hard to understand, please see att.

Again, I'm sorry for the inconvenience.

I'm working on a two byte version, hoping that it would be easier to understand the algorithm.

I do believe that is the algorithm that causes you difficulties.

It's similar to making the division by hand, with a pencil.

int(32735/256)=127    mod(32735/256)=223  ; you don't have to do this because it's just BYTE1 and BYTE2

on the other hand we are looking for:

int(32735/250)=130    mod(32735/250)=235

Based on 256=250+6: this means that 127*6+223=985

now int(985/256)=3  mod(985,256)=217   ; we are kiping score on the quotient!

and again 3*6+217=235,   BUT THIS TIME the rest is smaller than 250.

So the result will be 127+3=130 and the rest is 235

Does this make sense?

I was trying to avoid the usage of registers above R16. I need those for other purposes.

Also my intention was to use as few registers as possible.

PUSH and POP  on interrupts costs 4 cycles, but you have to do LDS and STS also.

So 8clk. is a price hard to bear when you are dealing with more than 250 ints./second.

Also, I was trying to find something ready to fit on my purpose, and I didn't.

When I have no luck, I'm getting to work on my own.

It was my intention to share; may be others will have more luck than me. ;-)

I've promised to upload a two byte conversion, for the purpose of simplicity on understanding the algorithm; see att. .

This time I've been commenting a lot, hope not too much.

This version is also tested(0 to 65535).

I'm just guessing that divideing by 1000 is less eficient on two bytes than on three bytes.

Anyway on my testings I never saw more than 72clks used; so I'm assuming less than 80.

Dividing by 4 first, and with 250 later is advantageous, because the 250 division will be done on a smaller number.

This time there is no MACRO, and the code is less obfuscated - I hope.

On the contrary I think MUL is a very powerful tool, even I can't argue for the moment; because of the algorithm I use.

I will end this post, and look on the link afterwords; hope you don't mind.

Thank you.

So what's the minimum for converting $63 to two decimal digits, on atmega328p?

This code is 12.5clk AVG, min. 9clk and max. 15clk. Not bad at all, on first writing. :-)

number

between     Cycles

0 and 9        9

10 and 19   13

20 and 29   14

30 and 39   10

40 and 49   14

50 and 59   15

60 and 69   10

70 and 79   14

80 and 89   15

90 and 99   11

Mul takes two Cycles:

"MUL Rd, Rr Multiply unsigned R1:R0  Rd  Rr Z,C  2"

from 7810D–AVR–01/15  ATmega328P [DATASHEET] pag. 281

so total is 9+2=11

if i'll do the initialization will be 13; and I will lose the benefit of not using two more registers.

I am very, very sorry; in this case I'll chose AVG 12.5 is better.

Don't know if you looked at the conversion of the two Bytes to BCD, att. at #23.

I've measured AVG=72.3 , from 256 to 65535; that is except the One Byte conversion.

"Just saw I was wrong, and you are right. Please excuse.

Your code is indeed 11 cycles and I have to reconsider my code.

Thank you."  - my original comment.

Now, that I've tested the code in Question,

I can say that It Is Wrong Code.

It just seems to be good.

So this code:

; nummer in r16 only 0..99 are legal
; 10 i r21
; 1  i r20

ldi r17,26
mov r20,r16
sbrc r18,6
dec r20
mul r20,r17
mov r21,r1
ldi r17,10
mul r21,r17
sub r20,r0

Gives this conversion:

I am using 0.5s or 1 second update, and I'm not using the "oscilloscope" type display; so I don't know.

I've done some programs with displaying on Hitachi HD44780; this uses 4 lines of data, and 2 lines for control.

Know I'm using only UART or TWI. I haven't got issues  with these, but I'm using short Interrupt Routines (~60Cycles).

I have two adapters TWI to Hitachi HD44780, not used.

I'm using "USART Rx Complete" Interrupt, but on the transmit side I use:

.MACRO SChar2UART
    lds        @1,UCSR0A
    sbrs    @1,UDRE0    ; Wait for empty transmit buffer
     rjmp    PC-3
    sts        UDR0,@0        ; Send CHAR
.ENDMACRO

.MACRO SendUART2ASC
    mov r16,@0
    swap r16
    ASC r16
    SChar2UART r16,r17
    mov r16,@0
    ASC r16
    SChar2UART r16,r17
.ENDMACRO

I. GPS

II. I'm using Counter1 To count the pulses on the signal received from UBLOX.

can't count more than 65535 on a two bytes counter (or it's difficult)

so I've chose 250x64000; that is on 64000 pulses from U-BLOX I have INT

and based on the GPS precission, I have a very good aprox of what I'said:

250 INTs/second. I'm using only 60 Cycles on every INT, generated by the UBLOX,

but I also have the USART Rx Complete INT, and the TWI transmission.

III. I've said "too fast":

I am counting my own uC clocks using Timer/Counter1 Capture Event,

250 times per second, on an Event raised by a GPS receiver.

In the same time I have a TWI connection with a thermometer,

and a 2Mbit full duplex UART connection ... and this is just the begining.

I have indeed a "too fast" conversion for hex to ASCII,

but the relative large length of my "routine" is not a problem;

and that is because I'm not using libraries.

Added on 03/03/2021:

Someone found something rather useful here, so att. are present-day my file sources.

Yes, this is a freak piece of code. It works.

This:

; nummer in r16  [0..99]
; 10 in r21
; 1  in r20

; if used more then once load 10 and 26 to two registers

ldi r17,26      ; load value for mul with 1/10 (26/256)
mov r20,r16  ;make a copy to the remainder place
sbrc r16,6      ;if more than 64
dec r16          ; use one less
mul r16,r17    ; do the 1/10 mul
mov r21,r1     ; high result in high byte of mul
ldi r17,10       ; load value for mul with 10
mul r1,r17    
sub r20,r0      ;low digit is the remainder

gives these results: