Project planning in assembler

How to plan an AVR project in assembler

Hardware considerations

1. Which port connections with a fixed location are needed? Fixed locations are I/O ports of internal components that are only available on certain pins, and cannot be moved to another portpin. Components and connections of this kind are:
   1. If the processor should be programmable within the circuit (ISP interface), the pins SCK, MOSI and MISO have to be assigned for this purpose. If your peripheral allows that those can be used as inputs (e.g. SCK and MOSI) or as outputs (by decoupling them via resistors or multiplexers).
   2. If a serial interface is needed, RXD and TXD have to be reserved for that purpose. If the RTS/CTS hardware handshake protocol shall be implemented as well, two additional portpins are required, but can be placed at any other free location.
   3. If an analog comparator is needed, AIN0 and AIN1 have to be reserved for that.
   4. If external signals are to be monitored for level changes, INT0 and/or INT1 have to be reserved for that.
   5. If AD converters arew to be used, the ADC inputs have to be placed and reserved for that purpose. If the converter has the external AVCC and AREF connections, those should be used and wired accordingly.
   6. If external pulses are to be counted, the timer input pins T0, T1 and T2 are fixed and exclusive for that use.
   7. If external SRAM is to be attached, the respective address and data ports together with ALE, RD and WR have to be reserved.
   8. If the processor clock should be generated from an external crystal oscillator, XTAL1 has to be reserved. If an external crystal or ceramic resonator shall control the clock frequency, XTAL1 and XTAL2 are fixed for that purpose.
2. Are there any external components that require more than one portpin (e.g. 2, 4 or 8) to be written or read? These should be defined in an appropriate way (in the same port, in the right order).
   1. If controlling of an external device requires writing or reading of more than one bit at once, e.g. a four- or eight-bit LCD interface, the necessary port bits should be in the right order. If it isn't possible to place the whole interface in a single port, the interface can be divided into two pieces. The software is easier, if the resulting portions are left- or right-adjusted in the port.
   2. If two or more ADC channels are required, the software is easier, if those are placed in an order (e.g. ADC2+ADC3+ADC4).
3. At the end, all external components are placed that do not require fixed pins.
   1. If only a single pin causes you to select a larger device, you can consider using the RESET pin for that purpose. This can be used as an input pin if a certain fuse is set. Setting of that fuse disables further ISP programming, the chip can only be programmed in high-voltage programming modes. For final productions with a large number of identical devices, this is acceptable, but not for prototyping. In case of prototyping a high-voltage programmer interface on the ISP pin can be used, if the component on the RESET pin is protected against the 12 V on this pin during ISP programming, e.g. with a resistor and a zener diode.

• How many timers are needed and which resolution should these provide?
• Which values/informations should be preserved when the operating voltage is shut down? (EEPROM capacity)
• How much storage space is required? (SRAM capacity)
• Space requirements on your PCB, how much space for the processor fits best, which package types are available?
• Operating voltages and power requirements. If the operating voltage comes from a battery or an accumulator, the power characteristics play an important role.
• Price for the device? Only relevant for production in larger series. Not at all depending from the processor's internals, and a matter of unpredictable market conditions.
• Availability? If one starts a project with the AT90S1200, probably from a rummage table, can make it cheap. Such a decision is not very sustainable. Porting such a project to a tiny- or mega-device mostly ends up in a complete redesign of the software, that also looks and feels much better, works better and requires only a fraction of code lines.

Considerations on interrupt operation

Basic requirements of interrupt-driven operation

• Enabling interrupts:
  • Interrupts require the stack hardware. So set SPL (and in larger devices SPH) at the beginning to RAMEND, and reserve the upper part of the SRAM for that purpose (e.g. the last 8 to x bytes).
  • Each internal component and each condition that should be able to trigger an interrupt has to be enabled to do that, by setting the respective interrupt enable flag bit. Switching those bits on and off is a risky thing, so better design your software without switching.
  • The I flag in the status register SREG has to be set at the begin and remains set during operation. If it is necessary to clear the I flag during an operation outside an interrupt service routine, add the set-I-flag instruction within a few instruction words.
• Interrupt vector table:
  • Each internal component and each enabled interrupt condition corresponds to a specific interrupt vector, placed in a certain address in the flash program storage. The instruction at this address is a single-word RJMP instruction, in large ATmega processors a two-word JMP instruction, to the respective interrupt service routine.
  • The vector addresses are type-specific. When porting the software to a different type, those require adjustment.
  • Each vector address in the table, that is currently not used, is given a RETI instruction (in large ATmega types a RETI, followed by an NOP). That prevents erroneous ghost interrupts to be running into false code. The use of the .ORG directive for adjusting vector addresses does not provide safety against those events.
  • If an interrupt condition occurs, the respective flag in the control register of the internal component is set. This is automatically cleared, if the interrupt is executed. In some rare cases (e.g. in case of a TX buffer empty interrupt condition of an UART, if no further character is to be sent), the interrupt enable flag of the component has to be cleared first and the interrupt condition flag at last.
  • If the interrupt condition gets true for more than one component at a time, the interrupt with a lower address wins the race.
• Interrupt service routines:
  • Each service routine starts with saving the status register SREG in a register exclusively reserved for that purpose, and ends with restoring that status register. Because interrupts can occur every time, also in times while the processor is performing instructions in the main program loop, any disturbance of that status register can cause unpredictable malfunctions.
  • Before jumping to the service routine, the processor pushes the current instruction counter to the stack. The interrupt and the jump to the respective service routine disables further interrupts by temporarily clearing the I flag in the status register SREG. Each service routine ends with the instruction RETI, that pops the instruction pointer from the stack and sets the I flag on again.
  • Because the execution of an interrupt service routine blocks any further interrupt requests from being served, even those of a higher priority, each service routine has to be as short as possible and performs only the time critical portions of the task. Lengthy response operations have to be performed outside the interrupt service routine.
  • Because interrupting an interrupt service routine does not happen, all interrupt service routines can use the same temporary register.
• Interfacing interrupt service routine and main program loop:
  • The communication between the interrupt serve routine and the main program loop is performed via single flags, that are set within the service routine and cleared in the main program loop. The clearing of flags is either performed in single word instructions or interrupts are temporarily disabled during that step to block erroneous overwriting of other flags that were possibly changed in between the three steps read-modify-write.
  • Values that the interrupt service routines provides are handed over in dedicated registers or in specific SRAM locations. Each change of those values, that are used later on outside the service routine, have to be checked for possible corruption, if another interrupt can occur in between. Single byte handling is easy, but handing over two or more bytes requires a hand-over protocol (interrupt disable during hand-over, flag setting to prevent overwrite, etc.). As an example, the handover of a 16-bit timer value requires disabling of interrupts first. Otherwise the first byte read does not necessarily correspond to the second byte read, if another interrupt happened in between.
• Main program loop:
  • Within the main program loop the processor is sent to sleep, with the sleep mode "idle" selected. Each interrupt wakes up the processor, jumps to the respective interrupt service routine and, after its return from interrupt, continues its operation in the main program loop. It makes sense to check for any flags that were set within the service routine. If that is the case, the treatment of the flag can be performed. After all things were finalized, another check for the flag settings can be made (in case of long routines) and the processor can be sent back to sleep.

Example for an interrupt-driven assembler program

;
; Register definitions
;
.EQU rsreg = R15 ; saving the status during interrupts
.EQU rmp = R16 ; Temporary register outside interrupts
.EQU rimp = R17 ; Temporary register inside interrupts
.EQU rflg = R18 ; Flag register for communication
.EQU bint0 = 0 ; Flag bit for signaling INT0-Service
.EQU btc0 = 1 ; Flag bit for signaling TC0-Overflow
; ...
; ISR-Table
;
.CSEG
.ORG $0000
	rjmp main ; Reset vector, executed at start-up
	rjmp isr_int0 ; INT0-vector, executed on level changes on the INT0 input line 
	reti ; unused interrupt
	reti ; unused interrupt
	rjmp isr_tc0_Overflow ; TC0-Overflow-vector, executed in case of a TC0 overflow
	reti ; unused interrupt
	reti ; unused interrupt
	; ... other int vectors
;
; Interrupt service routines
;
isr_int0: ; INT0-Service Routine
	in rsreg,SREG ; safe status
	in rimp,PINB ; read port B to temp register
	out PORTC,rimp ; write temp register to port C 
	; ... do other things
	sbr rflg,1<





To the top of this page



Considerations on timing
If an AVR project goes beyond polling an I/O port and, depending from that result, doing
something, considerations on timing are necessary. Timing

  
starts with the selection of the processor type,
  
continues with the question, what has be executed periodically and with which
    precision,
  
and which timing control opportunities exist,
  
how those things can be combined.
  

Selection of the clock frequency of the processor
The main question is on the necessary precision of the processor clock.


Is it unnecessary in the application to perform times less than a few percent inaccurate,
the internal RC oscillator of most of the AVR types is sufficient. In the tiny and mega
types, a oscillator calibration is built in, so that differences between the nominal
and the effective frequency are reduced. Note that the default internal calibration byte
was selected at a certain operating voltage. If your operating voltage is fixed at a
different level, rewriting the calibration byte brings more accuracy. If the operating
voltage is fluctuating, the error can be too large.


If the internal RC clock is too slow or too large, some device types have a clock
prescaler on board. This feature allows to optimize the clock frequency, and different
clock frequencies can be selected. This is either done once with changing a hardware fuse
(the DIV8 fuse) or within the software (e.g. to reduce the supply power during pauses).
But be aware that some devices with a limited clock specification (V types) should not
be set to beyond their limit, otherwise they won't work correct any more.


If the internal RC oscillator is too inaccurate, fuses can be set for external RC
combination, an external oscillator, a crystal (Xtal) or a ceramic device. Because
false fuse setting can cause a catastophe, a rescue board with an external oscillator
might be the last chance to get the device working and the fuse resetted again.


The absolute clock frequency should be appropriate for the application. As an indicator,
the repeat frequency of the most often performed work package can be used. If a key
has to be polled any 2 ms, and, after 20 times, should be debounced long enough,
there is plenty of time, if a 1 MHz clock is used (2,000 clock cycles between any
two polls, 20,000 clocks for repeated execution of the key command).


It's only getting narrower, if a pulse width modulated signal with high resolution and
a high PWM frequency has to be reached. With a PWM frequency of 10 kHz and 8 bits
resolution 2.56 MHz are too slow for a software-driven solution. If a timer with
some software-overhead can take over that burden, that's better.





To the top of this page









©2011 by http://www.avr-asm-tutorial.net