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 AVR

smaller 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?