LedTriks Stand Alone programming issues

[Penfold]

I was trying to get my tiny2313 chip to accept my standalone firmware, but all I could get AVRDUDE to do was read the chip. My command line is as follows:

avrdude -c usbtiny -p attiny2313 -u flash:w:SAtest.hex

I get the reading and it goes to 100% then it says avrdude done. There is no writing to the chip. I look at the ledtriks display and it flashes for a second then goes back to the original test pattern. I have looked at the code and I see my seven frames there. I tweaked the number of frames line to reflect the 7 that I have.

Am I missing something in the command line? This has been a weird endeavor for me. I try something then I run into a brick wall. I leave it alone for a couple of days and then come back to it and, viola, something works that didn't before. This whole thing has had me scratching my head.

[TimW]

Did you try with -U instead of -u?

avrdude -c usbtiny -p attiny2313 -U flash:w:SAtest.hex might give you a different result. AVRdude seems to be a bit case sensitive...

Tim

[Penfold]

hmmmm I haven't tried the "-U" I will give that a try tonight. Thank you for the tip. I will let you know how that works out.

Thanks Tim

[Penfold]

Success!!!

That's exactly what I needed Tim. Thanks a bunch!!

I have two more questions though. How do you make the frames scroll quicker? I remember that you gave me a link, but all I found in that link was how to specify how many frames you had available "Equiframes" or something like that.

Also, is there an easy way of entering font in NRomanelli's template?

Please let me know.

[TimW]

I have two more questions though. How do you make the frames scroll quicker? I remember that you gave me a link, but all I found in that link was how to specify how many frames you had available "Equiframes" or something like that.

In the code you will find a scroll delay constant:

;Scroll delay constants
.EQU shift_H = 0x0a
.EQU shift_L = 0x8c
.EQU NUMFRAMES = 2 ; Number of frames stored in AVR
shift_H and shift_L combine to determine the scroll rate... in the example above its (hex) 0x0a8c which I think was about 4 steps per second
smaller number=faster scroll .. if you halve it it goes twice as fast!


Also, is there an easy way of entering font in


NRomanelli's template?

not sure he took it any further?

Without a code solution the easiest way is probably to generate text in vixen, display it in the ledtriks preview plugin (which has nice dots) and manually transcribe it into the frame generator.

Tim

[Penfold]

I had the ledtriks preview selected, but I never really clicked on it or used it. DOH! That was my fault.

I will look into the scroll delay constants.

THANK YOU VERY, VERY, Much for your help TIM.

[Penfold]

In the code you will find a scroll delay constant:

;Scroll delay constants
.EQU shift_H = 0x0a
.EQU shift_L = 0x8c
.EQU NUMFRAMES = 2 ; Number of frames stored in AVRsmaller number=faster scroll .. if you halve it it goes twice as fast!

Tim

Ok when you say that the code is in hex, how would I figure out how to change the alpha numeric code to get it running faster?

I tried the following:

;Scroll delay constants
.EQU shift_H = 0x0a
.EQU shift_L = 0x4c
.EQU NUMFRAMES = 2 ; Number of frames stored in AVR

Apparently I have misunderstood this whole thing. Please let me know what I am missing here.

Mike

[budude]

I think you need to halve the entire number so that 0x0a8c would become 0x0546 or:

.EQU shift_H = 0x05
.EQU shift_L = 0x46

[Penfold]

Budude, thanks for you reply. How did you arrive at that number? Sorry, but view me as a noob when it comes to this kind of thing. How does 0X0a8C become 0x0546?

Mike

[LabRat]

Budude, thanks for you reply. How did you arrive at that number? Sorry, but view me as a noob when it comes to this kind of thing. How does 0X0a8C become 0x0546?

Mike

Option 1: Use HEX calculator

Turn to your "windows" calculator, Click VIEW, SCIENTIFIC
Click on the Hex radio button
Type "0A8C" "/" "2" ENTER
Results: 546


Option 2: Learn about Hex numbering as being base 16 vs base 10.

Ok.. this is a bit harder to explain as it's akin to doing division in your head. How do you explain *THAT* to anyone?

Here goes (and if this is too simplistic.. I apologize).

We normally count things up using a "Base-10" counting system. That means that we have 10 symbols to represent the quantities of items that we are counting [0 thu 9]. The symbol "3" represents "three items". (I know this sounds ridiculous but it is going somewhere)
One you have counted more items than you have symbols, you shift to the left int the next column (what we typically call the "ten's" column)
Evertime you count up a number that matches the number in the base, you increment the next colum over. If that column gets full, it cascades up to the left again (100's column)
Ok.. now assume you are counting with a system that has 16 symbols... not 10. [0 thru 9, and A,B,C,D,E,F]
When you have "ten" items, you don't write it as 10 (that's base 10 thinking) you write it as "A"
When you have "fifteen" items, you write "F". Adding one more, causes the cascade to occur, and you get 10.
However, since that looks like "ten" we add a "0x" to the beginning to make sure you realize that it's counting in base 16.

So, in a base 10 thinking 1024 means 4 + 2*10 + 0*100 + 1*1000, which is also (4*10^0) + (2*10^1) + (0*10^2) + (1*10^3)
And in base 16 thinking 0x0A8C = C + (8*16) + (A*256) or (C*16^0) + (8*16^1) + (A*16^2)
Now divide in your head... (told you it was messy)


Option 3: Convert to binary.. shift right by 1 (equates to divide by two), and convert back to HEX.

0x0A8C = 0000 1010 1000 1100 (note each letter of the HEX is 4 bits of binary)
Shift right by 1 and you get 0000 0101 0100 0110
Convert each nibble (4 bits) back to HEX = 0x0546


Clear as mud?

[budude]

I'm assuming that the entire number is some type of wait loop counter of some sort (have to look at code) and as Tim suggested, halving it would make it scroll twice as fast (it only counts up/down to half as much).

So - if you take out your handy calculator 0x0a8c / 2 = 0x0546
or in decimal, 0xa8c = 2700, 2700/2 = 1350, 1350 = 0x0546 (back to hex).

edit - LabRat beat me to it... but that's how it's done anyway...

[klanger]

Option 1: Use HEX calculator

Turn to your "windows" calculator, Click VIEW, SCIENTIFIC
Click on the Hex radio button
Type "0A8C" "/" "2" ENTER
Results: 546


Option 2: Learn about Hex numbering as being base 16 vs base 10.

Ok.. this is a bit harder to explain as it's akin to doing division in your head. How do you explain *THAT* to anyone?

Here goes (and if this is too simplistic.. I apologize).

We normally count things up using a "Base-10" counting system. That means that we have 10 symbols to represent the quantities of items that we are counting [0 thu 9]. The symbol "3" represents "three items". (I know this sounds ridiculous but it is going somewhere)
One you have counted more items than you have symbols, you shift to the left int the next column (what we typically call the "ten's" column)
Evertime you count up a number that matches the number in the base, you increment the next colum over. If that column gets full, it cascades up to the left again (100's column)
Ok.. now assume you are counting with a system that has 16 symbols... not 10. [0 thru 9, and A,B,C,D,E,F]
When you have "ten" items, you don't write it as 10 (that's base 10 thinking) you write it as "A"
When you have "fifteen" items, you write "F". Adding one more, causes the cascade to occur, and you get 10.
However, since that looks like "ten" we add a "0x" to the beginning to make sure you realize that it's counting in base 16.

So, in a base 10 thinking 1024 means 4 + 2*10 + 0*100 + 1*1000, which is also (4*10^0) + (2*10^1) + (0*10^2) + (1*10^3)
And in base 16 thinking 0x0A8C = C + (8*16) + (A*256) or (C*16^0) + (8*16^1) + (A*16^2)
Now divide in your head... (told you it was messy)


Option 3: Convert to binary.. shift right by 1 (equates to divide by two), and convert back to HEX.

0x0A8C = 0000 1010 1000 1100 (note each letter of the HEX is 4 bits of binary)
Shift right by 1 and you get 0000 0101 0100 0110
Convert each nibble (4 bits) back to HEX = 0x0546


Clear as mud?

Ummm OUCH, that hurts. I gave up right when you said,

Here goes (and if this is too simplistic.. I apologize).

[LabRat]

Ummm OUCH, that hurts. I gave up right when you said,

Here goes (and if this is too simplistic.. I apologize).

It goes much better with a whiteboard. ;)

[Penfold]

I sort of get where you are coming from Budude, but I am still trying to soak it all in. Thanks for the explanations though!

[LabRat]

I was looking at the TRICKS-C source last night.
In this version it listed several options for the refresh timer. So the whole "divide by two" wouldn't necessarily be warranted.

;Scroll delay constants
.EQU shift_H = 0x0a ;0x010e=40hz 0x021c=20hz 0x2a30=01hz 0x1518=0.5hz 0x0a8c= 0.25hz
.EQU shift_L = 0x8c

Something doesn't look right on the 20 & 40 Hz however, as they aren't
20x the 1hz value. Some more reading on my part seems warranted. ;)

[TimW]

Um, would you believe that was a test to see if anyone ever read the source? ( Labrat... you win btw :) )

Ignore that comment line for a couple of reasons.
1) Its numerically wrong...
2) its not really hz... (!) its more like scroll delay (actually the inverse of Hz)

I thought if I just omitted this from my initial explanation the fact that its a bit wrong might just go away.... just shows you can run but you can't hide!

Penfold: If it makes it easier to understand these values you can just use normal decimal numbers. To do this you need to understand that the delay is determined by 2 values which are worth different amounts...

shift_L (the lower value) can have any decimal number from 0 to 255
shift_H (the higher value) can have any decimal number from 0 to 255

the actual delay is a combination of (256 * shift_H) + shift_L

so if Shift_H =0 and shift_L=5 the actual counter = 0*256 +5 = 5
if shift_H=1 and shift_L=5 then the actual counter = 1*256 +5 = 261

To define the values in normal, decimal... just omit the 0x (0x says its a hexadecimal number)

so...

.EQU shift_H=10
.EQU shift_L=140

is where we started from (=10*256 + 140=2700... =0x0a8c in hex)

This explains why if you just change shift_L you don't see much of a change... try changing shift_H and see what happens!

It doesnt matter what combination of values you put in there (up to a point...) as long as they allow a reasonable display rate... so they don't need to be a multiple of the initial values or anything. Halving/doubling the numbers was just for convenience...

Tim

[Penfold]

I did some tweaking to the code and have come up with:

.EQU shift_H=2
.EQU shift_L=23

It looks descent and I think I am going to stay with this. Thanks for all your help Tim, Labrat, budude. I really appreciate it! :-)