ATTiny10 Assembly IDE and Device Programmer

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've developed a simple, Java-based IDE for writing assembly code for the ATTiny10 family. I've also developed a simple HV programming circuit that works with the IDE to create a complete solution for writing code and then programming an ATTiny10 device. Since my design implements a high voltage programmer, this means you can write code that sets the RSTDISBL fuse in order to use the RESET line (pin 6 on the ATTiny10) as an additional I/O pin (PB3, ADC3, PCINT3) and still reprogram the device later. The code and hardware design is still alpha but, if you're interested in trying my IDE, check out the project page, here:

https://sites.google.com/site/wayneholder/attiny-4-5-9-10-assembly-ide-and-programmer

Note: while written in Java, the IDE is currently packaged as an OSX app, so it's only available to Mac users at the moment. I'd like to release Win and Linux versions, but I need to figure out some details on how to link with the RXTX serial library on these platforms before I can do this.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Neat, I guess. I think I would have re-implemented the broken LDS/STS as macros (maybe LDSS/STSS for "short"?), so I wouldn't lose other features of the assembler.

Do you publish the EAGLE files for your shields?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How would one implement such a macro for usage with the gnu assembler? Something like

.macro ldss Rd, k
.word 0xA0000000 | ((k & 0x70) << 8) | (Rd << 4) | (k & 0x0F)
.endm

perhaps?

The opcode for the 16-bit lds is

1010 0kkk dddd kkkk

I tend to post off-topic replies when I've noticed some interesting detail.
Feel free to stop me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
Neat, I guess. I think I would have re-implemented the broken LDS/STS as macros (maybe LDSS/STSS for "short"?), so I wouldn't lose other features of the assembler.

Do you publish the EAGLE files for your shields?

Thanks for your interest in my project. Actually, I didn't develop the PCB in Eagle. I used a Mac program called Osmond PCB:

http://www.osmondpcb.com

However, I also made the board is available via BatchPCB, here:

http://batchpcb.com/index.php/Products/50927

I thought about the macro approach, but the IDE was pretty easy to write and had the advantage that I could integrate it easily with the programmer for a solution that makes it quick and easy to pop out changes.

Wayne

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
How would one implement such a macro for usage with the gnu assembler? Something like

.macro ldss Rd, k
.word 0xA0000000 | ((k & 0x70) << 8) | (Rd << 4) | (k & 0x0F)
.endm 


Yep; something like that; probably more like:
.word 0xA000 | ((k & 0x70) << 4) | (Rd << 4) | (k & 0x0F)
I'm not intimate enough with gasm macros to tell whether that's exactly right or not. I once wrote a whole 8085 assembler as macros for Macro-10 (on DEC mainframes.) It was great; you got all the other assembler features for free. It might have even worked (when you type in a forth interpreter from a magazine, assemble it with your own assembler, and run it under your own simulator, there are a lot of different places where things can go wrong...)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I didn't develop the PCB in Eagle. I used a Mac program called Osmond PCB:

Ah; I was fooled by the look of the schematic. I was interested in trying to make a more single-sided version. I definately need to try out that voltage multiplier!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any macro solution for gas would ideally have some sort of bounds checking to ensure you only attempted to use addresses between 0x40 and 0xBF re-mapped down to op-code operands 000xxxx0000 up to 111xxxx1111. (The I/O registers in addresses 0x00 to 0x3F are inaccessible by lds/sts.) And it would have to account for the fact that the three most significant bits of the address encoded in the op-code are out of order:

+-----+-----+-----+
|bit 5|bit 4|bit 6|
+-----+-----+-----+
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My main concern was "assembling" the different pieces (instruction and operands) into the right data word. Of course, checking the boundaries is important.

I had another look at the instruction set manual, and the bit order is indeed as lfmorrison writes it, but what does the inverted bit _INST[8]_ do there?

Quote:
A 7-bit address must be supplied. The address given in the instruction is coded to a data space address as follows:
ADDR[7:0] = (_INST[8]_, INST[8], INST[10], INST[9], INST[3], INST[2], INST[1], INST[0])

I tend to post off-topic replies when I've noticed some interesting detail.
Feel free to stop me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is their way of dealing with the encoding offset.

The instruction encodes addresses running from 0x00 up to 0x7F. These addresses are then re-mapped to run from real-world locations 0x40 up to 0xBF.

Doing things by hand, a straightforward arithmetic operation would appear to be a simple addition or subtraction by 0x40.

However, if you think of things in terms of logic gates, the inverted _INST[8]_ has an almost-equivalent effect, but probably saves transistors somewhere.

Instructions with bit 8 set, from 00Xxxx0000 to 11Xxxx1111 would decode to addresses from 01000000 to 01111111, or 0x40 to 0x7F.
Instructions with bit 8 clear, from 00Xxxx0000 to 11Xxxx1111, would decode to addresses from 10000000 to 10111111, or 0x80 to 0xBF.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now I understand how the instruction

LDS r21,0x50 

is turned into 0xA350, thank you! So without checking bounds, the opcode is built up like this:

0xA0 | (((k-0x40) & 0x30) << 5) // bits 10 and 9 of the opcode
     | (((k-0x40) & 0x40) << 2) // bit 8
     | (Rd & 0xF0) // bits 7..4
     | ((k-0x40) & 0x0F) // bits 3..0

(0x40 <= k <= 0xBF)

I tend to post off-topic replies when I've noticed some interesting detail.
Feel free to stop me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
Quote:
I didn't develop the PCB in Eagle. I used a Mac program called Osmond PCB:

Ah; I was fooled by the look of the schematic. I was interested in trying to make a more single-sided version. I definately need to try out that voltage multiplier!

I did use Eagle for the schematic, but I never really got the hang of using it for PCB layout.

I'm actually quite pleased with how well the multiplier works and how it keeps the cost down compared with using something like a MAX662A (http://www.maxim-ic.com/datasheet/index.mvp/id/1141). The cost of all the part is less than half the cost of just the MAX662A chip. It was also fun figuring out how to use the Arduino as both the driver for the voltage multiplier and also as the programmer.

Wayne

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By popular demand, I've now improved the assembler used in my IDE so that it handles simple expressions. The revised code is available here:

https://sites.google.com/site/wayneholder/attiny-4-5-9-10-assembly-ide-and-programmer

Wayne