Generating DMX-512 with Atmel Mega644P CPUs Andy Miyakawa / Director of Software Development Eclectic Electric / Dandy Solutions June 2008

Transcription

1 Generating DMX-512 with Atmel Mega644P CPUs Andy Miyakawa / Director of Software Development Eclectic Electric / Dandy Solutions June 2008 What is DMX-512? DMX-512 is a data transmission scheme used originally by theater lighting companies to connect lighting control consoles ("Light Boards") to the power control boxes ("Dimmer Packs"). The scheme uses a async serial protocol to transmit 512 lighting levels using a single shielded pair cable. What does DMX-512 look like? To handle the long cable lengths that are often used in actual theaters, the RS-422 connection system was selected. This uses a balance shielded cable that can (with proper termination) be extended to 4000 feet. CAT5e cable (not even thought of when DMX was created) can be used since it has a uniform impedance and great shielding. The data is transmitted in a continuous stream starting with channel 1 and ending with channel 512. When lights are changing rapidly as often happens in the theater, the design DMX had to include an updated value at least 30 times per second. 30 is chosen because the human eye cannot see flickers as fast as 30 / second and is the basis of television and movie films. With 512 values to send and 30 updates per second, there are 15,360 bytes of data that need to be sent every second so a rate faster than that was needed. For reasons that remain historically undocumented, the rate of 250,000 baud was chosen. The data is formatted in 11 bits (more on that later) so 250,000/11 = 22,727 bytes per second which is faster than the required 15,360. All 256 possible values (0-255) of data are used for lighting levels where 0 is OFF and 255 is full ON. Since there are no values reserved for special service, there has to be some way to indicate where the value for channel 1 begins. It would be good to re_sync each frame of data (512 bytes) so the scheme should be repeatable and not use much of the available bandwidth. The scheme chosen was a BREAK. A BREAK is a condition on the transmitted data signal which does not conform to normal serial protocol. Async serial sends a start bit followed by a number (8 in this case) of data bits and then a stop bit (in this case 2 stop bits). The BREAK violates the normal DMX-512 Frame Format transmission by not having stop bits where stop bits are supposed to be. The actual protocol starts each frame with a BREAK lasting at least to character times followed by the end of BREAK for at least 2 bit times followed by an ID byte (always 0) followed by 512 bytes of data (channel 1 through 512). This becomes the frame and is repeated at least 30 times per second. Figure 1 shows this transmission signal. Using the AVR USART to Generate DMX us BREAK ID Char (0) 8 us Space Figure 1 Channel 1 Value Channel Values Channel 512 Value The Mega USARTs meet all of the requirements of DMX save one, BREAK generation. The data rate (250,000 baud) is within the maximum data rate of the USART and system clock rates of 8 mhz, 16 mhz and 20 mhz DMX.CDR 21-Jun-08-1-

2 can all be divided to give this rate. The 8 data bits and 2 stop bits are all configurable but there is no USART feature which allows for the generation of the BREAK. In most USARTs that have a BREAK feature, BREAK overrides the output to force the BREAK state but the USART continues to clock and generate timing signals just like normal data transmission. Thus the USART can be used to determine the BREAK timing. On the AVR Mega, this cannot be done without extra added hardware to override the USART output so I chose a different direction. On the AVR Mega, when the USART transmitter is disabled, the pin that is used for output is instead under control of the normal port registers. By enabling and disabling the TX (transmitter) and manipulating the port values, DMX can be generated without additional hardware. The only limitation is that the BREAK will have to be timed using CPU instruction timing or using one of the timers. Since the BREAK only 88 us long, using CPU instruction timing is quite acceptable. The TX Procedure Configure the port bit shared by the TxD line (Port D, bit 1) for output and set the value to 1. 1 is chosen because RS-422 drivers and indeed the USART itself operate with inverted data. Make certain the USART is configured correctly (baud rate, async, stop bits, etc.) and the TX is NOT enabled. 1) Set the output bit to a 0 (start BREAK). 2) Delay 88 us 3) Set the output bit to a 1 (end BREAK) 4) Delay 8 us 5) Enable the USART TX and start the data frame of 513 bytes (1 ID byte and 512 data bytes 6) When the TXC flag is set after the last (512th) byte, disable the TX Repeat this continuously and at 250,000 baud a new byte is sent every 44 us. Obviously, this keeps the program busy though the CPU is capable of much more. What Else Is Desirable? One thing that is desirable is DMX in. You might wonder why but one of the common things in DMX systems is that a device may accept a DMX data stream from another device, modify it and then send it out. The RX portion of the USART can be used for this. Since the in and out may be at different points in the channel list, a full buffer (512 bytes) is needed but this is easy since the Mega644 has 4,096 bytes. In fact, two buffers are best with one holding the values received and the other holding the locally generated values. With two values for each channel, the data must be combined together before sending. In the theater world, the most common combining is called Pile though the name is somewhat misleading. Pile simply takes the larger of the two values as the value to output. For a lighting system this means that the larger value or brighter light will prevail. A typical use for this is the house lights which are often on dimmers. Rather than keeping the light board running all the time, its output is sent to a much smaller box with very simplified controls which piles on to those channels with the house lights while passing through the rest of the values. One of the specifications for DMX is that if data input is lost, all channels will assume a 0 value. This allows for the main dimmer board simply to be turned off and the house light override box to controls the house lights while leaving the house lights dimmer board controllable during shows.. What this adds is another 15,000+ pieces of data to handle each second. The word interrupts immediately comes to mind. DMX and Interrupt Service To handle DMX transmission using interrupt service, you need to come up with a scheme that uses the TXC -2-

3 (transmit complete) interrupt and the UDRE (USART data register empty) interrupt to completely handle the header (BREAK) and the data. The one complicating factor is that I planned to use the RXC (receiver complete) interrupt for incoming data and these interrupts come every 44 us also so any approach that has the interrupts disabled for more than a few us could lead to data losses. The 88 us BREAK plus the 8uS gap could not be done using CPU timing with the interrupts disabled as this would guarantee missing an RX byte. The solution is in the specifications: both the 88uS and 8uS times are minimums. Longer (up to 1S) are allowed as long as the update rate remains more than 30 updates per second. I used the TXC interrupt to handle the BREAK, gap and ID byte. TXC interrupt service first disables the TX then re-enables the interrupts. Since the TX is disabled, it does not interrupt again (it would if not disabled) and since the interrupts are on RXC service can continue. The TXC interrupt code then sets BREAK state via the port bits by writing a 0 to the bit. It then delays by counting instruction cycles for 88uS. RXC interrupts will extend this time but since there is no maximum of any issue, there is no problem. Then the TXC interrupt service clears the BREAK by writing a 1 to the bit and delays another 8 us. The tricky part begins here. First the global interrupts must be disabled so the TX can be enabled without causing a nested interrupt (remember that this already in TXC interrupt service). Once the TX is enabled, a byte of 0 (the ID byte) is loaded into the TX. Then, the TXC interrupt is masked off and the UDRE interrupt is unmasked and the output data pointer set to point to the beginning of the TX data buffer. TX interrupt service can then exit which re-enables the global interrupts. Immediately, the UDRE interrupt will occur and that interrupt service routine should fetch the next data from the buffer and load it into the TX. That interrupt can then exit and it will continue to be called every 44uS to load the next data into the TX. When the last data is sent (512th value), the UDRE interrupt should be masked off and the TXC interrupt unmasked. Then the UDRE interrupt service should exit without loading any data into the TX. Since the TX is still busy, the TXC interrupt will not occur until all of the data including the 512th byte is sent. When the TX is empty (all data sent), the whole cycle can begin again with the TXC interrupt service first disabling the TX, sending the BREAK, sending the gap and then the ID byte. You might wonder about how to start this process at first. Simply enable the TX and unmask the TXC interrupt! Tests on a Mega644 running at 16 mhz showed that about 10% of the CPU is used up in this process. This leaves 90% for the RXC interrupt and any mainline execution. As mentioned earlier, it is often the case that you will want to combine a received data stream with locally generated values. That code is placed in the UDRE interrupt service routine so that the data that is sent out (loaded into the TX) obeys whatever rules you wish but usually taking the larger value (pile fading). For this reason, I configured two 512 byte buffers in SRAM. One is loaded by the RXC service and the other by the mainline process. By making the buffers contiguous, one data pointer is enough since adding 512 will advance it to the second buffer. For my sanity sake, I put those buffers on a 256 byte boundary but this isn t strictly necessary. It does make detecting the end of buffer easier since you only need to test the high byte of the address. The RXC interrupt service is much more straight forward. Most of the time you simply read the data and store it in the buffer. There needs to be a buffer pointer which is incremented after each read. When the BREAK is received, the same interrupt occurs but the FE (framing error) bit is set. You must test for this bit prior to reading the data (which will be a byte of 0) since the bit is cleared by reading the data. Also, there needs to be a flag to indicate that the first byte (the ID byte) is to be discarded prior to storing the data. To complete the RX code, you need to have a timer which times out after 1S and clears the buffer to all 0 s. That timer should be continuously reset at each RXC interrupt so that it never times out when data is being received. There is also an issue of startup. The RXC interrupt service routine must not save data until after the first received BREAK. This guarantees that the received data is placed in its proper place in the buffer. I use a flag byte with two flag bits, one to indicate that a BREAK was received and the other to cause the first byte after the -3-

4 TX Interrupt Services TXC Transmitter Complete Interrupt Service UDRE Data Register Empty Interrupt Service Save CPU State Save CPU State Turn OFF TXEN Mask OFF TXCIE Re-enable INTS Fetch Data Pointer Fetch Pointer Load Data in TXD Increment Pointer Clear TX Port Bit (Start Break) Delay 88uS Data Pointer Past End of Buffer? Yes Set TX Port Bit (End Break, Gap) Delay 8uS No Mask UDRE Interrupt Unmask TXC Interrupt Disable Ints Turn ON the TX Load ID Byte in TXD Restore CPU State RETI Enable UDRE Interrupts Set Address pointer to data buffer Restore CPU State RETI -4-

5 RX Interrupt Service RXC Receiver Complete Interrupt Service Save CPU State DOR Data Overrun Bit Set? No Fatal Error Data Loss FE Framing Error Bit Set? Yes No Set Break_Found Set Data Pointer to Buffer Break_Found true? No Yes RX_Store true? No Yes Set RX_Store Store Data at Pointer Increment Pointer Restore CPU State RETI -5-

6 BREAK (the ID byte) to be discarded. At startup, the BREAK received (RX_STORE) bit should be cleared prior to enabling the RX. The flow charts depict these three interrupt services. The flow charts were used to coding a DMX-512 device driver which is available as part of the EEBasic language. The code for this device driver is included below but there are a few notes you need to know about this code. I use a number of macros in my coding to make my code more readable. The code for these macros is included below. ; simulate the INTEL JNZ instruction.macro jnz ; ; simulate the INTEL JZ instruction.macro jz ; simulate the INTEL JC instruction.macro jc ; simulate the INTEL JNC instruction.macro jnc ; simulate the INTEL JP instruction.macro jp ; simulate the INTEL JM instruction.macro jm ; simulate the INTEL SHL instruction.macro shl ; simulate the INTEL SHR instruction.macro shr ; absolute value.macro abs brpl PC+2 ; simulate add immediates using the sub immediates.macro addi low(-(@1)).macro.macro.macro adci sbci cpw cp cpc subw sub @1l ; LDIW Load a register pair with a value.macro ldiw ldi high(@1) ; STSW Store a register pair in SRAM.macro @1L ; LDSW Load a register pair from SRAM.macro @1+1 ; PUSHW push a register pair.macro pushw ; POPW a register ; XCHG Exchange two registers without using temporary reg.macro As you might conclude, I often code on Intel processors so the conditional jumps match those of Intel. The word load and store commands assume that their 16 bit variables are stored low byte / high byte in memory. The register designations are X,Y, and Z and the H and L are added by the macros. The PushW and PopW macros are matched so the PushW pushes low/high and the PopW s high/low. The following code is only the device interface module which is available with EEBasic. EEBasic is a single chip programmable controller which accepts code written in a Basic like language. The DVIM is callable by name from EEBasic. This module assumes the Registers tmp, tmp1, tmp2 and tmp3 are R16, 17, 18 and 19 respectively. D4700 is the address of a block of 8 bytes in SRAM. There are byte buffers: Xbuf1, Xbuf2 and Xbuf3. Xbuf1 is a buffer of flags, one for each channel. Xbuf2 is the DMX In buffer and Xbuf3 (called Parallel) receives values generated by the mainline code. The Flag byte provides a way to control if Xbuf2 or -6-

7 Xbuf3 are included in the DMX Out. If both are included, the two values are Piled (larger takes precedence). There are two code entry points, one which init s all of the variables (dmxinit) and one which allows enabling and disabling the RX and TX (dmxen). The TX and RX can be separately controlled. The SetIntVect routine is called to link the CPUs interrupt vector to the specified routine. EEBasic allows runtime linkage of interrupt vectors since this module can be loaded into an already programmed EEBasic chip but you would probably just include the appropriate JMPs in the interrupt vector area. EEBasic uses the Mega644P CPU s ability to modify it s own code (very carefully!) to make these linkages. The entry point table at the beginning of the module provides symbolic access to these routines. The tables are grouped with the internal symbol table of EEBasic so the symbolic names are declared and would not be needed if the code was used in another system. There is code in dmxinit which calculates the number of instructions to execute to make the 88 us and 8 us delays. This is based upon the number of CPU cycles that execute during one 16X clock time and is determined by the system clock frequency. There are notes in the comments about this. ; Company : Dandy Solutions / Eclectric Electric ; Comment : DMX Transmit & Receive ; Date : 23-Mar-08 ; By : A.S.Miyakawa.cseg.org 0x4600 ; code address.set DMXData = D4600 ; data storage for routine at 0x4600 ; Also takes 0x4700 and D4700.set DMXDivisor = DMXData + 0 ; Clock ticks per DMX bit ; Divisor = this value - 1.set DMXBrkDly = DMXData + 2 ; CPU Cycles for break.set DMXGapDly = DMXData + 4 ; CPU Cycles for gap.set DMXInPtr = DMXData + 6 ; DMX in pointer.set DMXOutPtr = DMXData + 8 ; DMX out pointer.set DMXFlags = DMXData + 10 ; DMX Control flags.set Flag_RX_STORE = 0 ; Allow store after first break.set Flag_RX_HDR = 1 ; Set to discard header byte after break ; RX_STORE is set by BREAK so that is the RX is enabled in mid_frame, data will not be ; stored until a BREAK occurs to guarentee that partial frame data will not be loaded. ; RX_HDR is also set by BREAK and cleared after first byte (header) so the header is ; not stored as channel 1's value..set MAPbuf = XBuf1 ; MAP bits.set PILE_DMX = 0 ; PILE on DMX In Data.set PILE_PARA = 1 ; PILE on PARA In Data.set DMXInbuf = XBuf2 ; DMX in data.set PARAInbuf = XBuf3 ; Parallel Port in data ; Flags for DMXEN.set DMXEN_ENRX = 0 ; 0x = Enable RX.set DMXEN_DIRX = 1 ; 0x = Disable RX If both, this prevales -7-

8 .set DMXEN_ENTX = 2 ; 0x = Enable TX.set DMXEN_DITX = 3 ; 0x = Disable TX ; ***********************************************************************.db 0x55, 0xAA, 0x55, 0 ; marker for table of constants.dw dmxinit ; call dmxinit(bit period us)).db "dmxinit", 0.dw dmxen ; call dmxen(flag).db "dmxen", 0, 0, 0.dw MAPbuf ; address of buffers.db "dmxmap", 0, 0.dw DMXInBuf.db "dmxin", 0, 0, 0.dw PARAInBuf.db "parain", 0, 0.db 0, 0, 0, 0 ; marker for end of table ; ************************************************************************ ; ; DMXEn(flags) ; dmxen: cpi tmp, 1 jz PC+2 rjmp dmrac ; ldd ZH, Y+0 ldd ZL, Y+1 ld XL, Z+ ld XH, Z+ ; argument in X sbrs XL, DMXEN_DIRX ; If disable, do it else rjmp PC+2 rjmp disable_rx sbrs XL, DMXEN_ENRX ; if enable, do it rjmp endmx1 ; try TX enable_rx: cli ; block ints lds tmp, DMXFlags ; RX starts when break received cbr tmp, 1 << Flag_RX_STORE sts DMXFlags, tmp ; disable RX_STORE until break ldiw Y, MAPbuf ; address of MAPbuf ; This whole thing assumes that a DMX ; frame is likely in progress and it ; is bad to catch that frame since we ; cannot know which value it is. RX_STORE ; is set by break detect so the frame ; begins there. -8-

9 stsw DMXInPtr, Y ; as starting lds tmp, UCSR1B ; Enable RX and RXInt sbr tmp, 1 << RXEN1 sbr tmp, 1 << RXCIE1 sts UCSR1B, tmp ; ready to receive sei rjmp disable_rx: endmx1 ; allow ints cli lds tmp, UCSR1B ; shutdown the RX cbr tmp, 1 << RXEN1 ; cbr tmp, 1 << RXCIE1 ; and it's int sts UCSR1B, tmp sei endmx1: sbrs XL, DMXEN_DITX ; If disable, do it else rjmp PC+2 rjmp disable_tx sbrs XL, DMXEN_ENTX ; if enable, do it rjmp endmx2 ; exit enable_tx: ldiw Y, MAPbuf stsw DMXOutPtr, Y ; init pointer lds sbr sbr tmp, UCSR1B tmp, 1 << TXEN1 tmp, 1 << TXCIE1 cli ; prevent the int here in case sts UCSR1B, tmp ; the TX is already empty. Send ldi tmp, 0 ; one char in case we are just from sts UDR1, tmp ; power up sei endmx2: clc ret ; done disable_tx: lds tmp, UCSR1B cbr tmp, 1 << TXEN1 ; stop TX cbr tmp, 1 << TXCIE1 ; disable ints cbr tmp, 1 << UDRIE1 ; sts UCSR1B, tmp clc ret ; dmrac: ldi tmp, ErrArgCount ; argument count error -9-

10 sec ret ; DMXINIT _ initialize DMX ; ; call dmxinit(uc) ; ; uc = microcycles / Bit transmitted ; ; uc = 16mHz (16,000,000 / 16 / 4 = 250,000) ; uc = 8mHz (8,000,000 / 16 / 2 = 250,000) ; uc = 4mHz (4,000,000 / 16 / 1 = 250,000) ; ; uc = 8mHz (8,000,000 / 16 / 50 = 10000) dmxinit: cpi tmp, 1 jz PC+2 ; one argument only rjmp twrac ldd ZH, Y+0 ; first arg ldd ZL, Y+1 ; address ld XL, Z+ ; load value ld XH, Z+ stsw DMXDivisor, X ; save divisor (as entered) ; Compute the delay counts for the break and the gap based upon the divisor supplied ; by the user. These are used in delay loops to send break and gap. rol XH ; * 2 rol XH ; * 4 rol XH ; * 8 rol XH ; * 16 = CPU Cycles per bit ldiw Z, 0 ; compute *2 and *22 rol XH ; *2 add ZL, XL adc ZH, XH ; (*2) stsw DMXGapDly, Z ; *2 = Gap Delay rol XH ; *4 adc ZL, XL adc ZH, XH ; (*2)+(*4) rol XH ; *8 rol XH ; *16 adc ZL, XL adc ZH, XH ; (*2)+(*4)+(*16) = *22 stsw DMXBrkDly, Z ; *22 = Brk Delay -10-

11 ; Load the divisor for baud rate ldsw Z, DMXDivisor sbiw ZL, 1 ; divisor_1 stsw UBRR1L, Z ; load clock divisor ldi tmp, (1<<UCSZ11)+(1<<UCSZ10)+(1<<USBS1) ; 8bit 2stop sts UCSR1C, tmp ldiw Y, MAPbuf ; fill buffer stsw DMXInPtr, Y ; pointers stsw DMXOutPtr, Y ; here ; fill buffers ldi tmp, (1<<PILE_PARA) ;+ (1<<PILE_DMX) ; enable input and both PILEs fl1: st Y, tmp adiw YL, 1 cpi YH, high(mapbuf+512) jnz fl1 ldi tmp, 0x00 ; starting values = 0 fi2: st Y, tmp adiw YL, 1 cpi YH, high(parainbuf+512) jnz fi2 sts DMXFlags, tmp ; start with flags = 0 ldiw Y, MAPbuf_1 stsw Var_End, Y ; reduce size of Var area ; Link the interrupt service routines ldiw X, TxDRE_Int ; link the Tx Data Register Empty Int ldi tmp, UDRE1addr/2 call SetIntVect ldiw X, TxC_Int ; link the Tx Complete Int ldi tmp, UTXC1addr/2 call SetIntVect ldiw X, RxC_Int ; link the Rx Complete Int ldi tmp, URXC1addr/2 call SetIntVect sbi DDRD, 3 ; set TXD1 to output clc ret ; no error ; TxDRE_Int: push tmp in tmp, SREG push tmp push tmp1 push tmp2 pushw Y -11-

12 ldsw Y, DMXOutPtr ; Out Pointer cpi YH, high(mapbuf+512) ; Past the end of MAPbuf? jnz dre1 ; No, PILE and send ; Yes, switch to TXC Int lds tmp, UCSR1B ; interrupt enables cbr tmp, 1 << UDRIE1 ; disable UDR int sbr tmp, 1 << TXCIE1 ; enable TXC interrupt sts UCSR1B, tmp ; switch interrupts drexit: ; restore and exit w Y tmp2 tmp1 tmp out SREG, tmp ; so we can't get an Int tmp ; until after the RETI reti ; Under the control of the MAP bits, PILE DMXIn and PARAIn values dre1: ld tmp, Y ; MAP bits ldi tmp1, 0x00 ; PILE here (larger value) addi YH, high(dmxinbuf - MAPbuf) ; advance to DMXIn sbrs tmp, PILE_DMX ; skip to PILE DMXIn rjmp dre2 ; don't PILE DMXIn ld tmp2, Y ; load DMXIn value cp tmp1, tmp2 ; compare for larger jnc PC+2 ; take the larger mov tmp1, tmp2 ; value dre2: addi YH, high(parainbuf - DMXInBuf); advance to PARA In sbrs tmp, PILE_PARA ; skip to PILE PARAIn rjmp dre3 ; don't PILE PARAIn ld tmp2, Y ; same as above, take the cp tmp1, tmp2 ; larger value as the PILE jnc PC+2 ; result mov tmp1, tmp2 dre3: sts UDR1, tmp1 ; load PILEd value into Tx lds YH, DMXOutPtr+1 ; reload high address adiw YL, 1 ; increment it stsw DMXOutPtr, Y rjmp drexit ; TxC_Int: push tmp in tmp, SREG push tmp push tmp1 push tmp2 pushw Y -12-

13 lds tmp, UCSR1B ; Int mask bits cbr tmp, 1 << TXCIE1 ; turn this interrupt off cbr tmp, 1 << TXEN1 ; turn off transmitter sts UCSR1B, tmp ; so we can sei ; turn the others back on cbi PORTD, 3 ; and set the port bit (break) ldsw Y, DMXBrkDly ; count for break timing tx_1: sbiw YL, 4 ; count cycle, each time around jnc tx_1 ; takes 4 uc sbi PORTD, 3 ; clear break ldsw Y, DMXGapDly tx_2: sbiw YL, 4 jnc tx_2 lds tmp, UCSR1B sbr tmp, 1 << TXEN1 sts UCSR1B, tmp ; turn back on the Tx ldi tmp, 0 sts UDR1, tmp ; send the address byte cli ; no ints please lds tmp, UCSR1B sbr tmp, 1 << UDRIE1 ; enable UDR int sts UCSR1B, tmp ldiw Y, MAPbuf ; reset pointer stsw DMXOutPtr, Y ; to beginning of MAPbuf w out reti Y tmp2 tmp1 tmp SREG, tmp tmp ; RxC_Int: push tmp in tmp, SREG push tmp push tmp1 push tmp2 pushw Y lds tmp, UCSR1A ; check for errors sbrc tmp, FE1 ; framing error is BREAK rjmp rx_2 sbrc tmp, DOR1 ; overrun is program error rjmp rx_1 lds tmp, UDR1 ; read data ldsw Y, DMXInPtr -13-

14 cpi jnz YH, high(dmxinbuf+512) rxx lbrk rxx: lds tmp1, DMXFlags ; ready for store? sbrc tmp1, Flag_RX_HDR rjmp rxdisc sbrc tmp1, Flag_RX_STORE ; don't begin store until after 1st break st Y, tmp ; save data adiw YL, 1 stsw DMXInPtr, Y rxexit: w out Y tmp2 tmp1 tmp SREG, tmp tmp reti rxdisc: ; discard the header byte which is cbr tmp1, 1 << Flag_RX_HDR ; the first byte after break sts DMXFlags, tmp1 rjmp rxexit rx_1: rx_2: rjmp rxexit lds tmp, UDR1 ; read in data ldiw stsw lds sbr sbr sts rjmp Y, DMXInBuf DMXInPtr, Y tmp, DMXFlags tmp, 1 << Flag_RX_STORE tmp, 1 << Flag_RX_HDR DMXFlags, tmp rxexit -14-

15 This code is assembled with the AVRA assembler version 1.22 when it is part of EEBasic. It has been tested in that environment on an Mega644P CPU running at 16 mhz using USART1 and DS8921 RS-422 drivers. The specific user application was a House Light override system that could be controlled by a PC type computer. When the RX and TX are both running at full throughput (44 frames / second), the mainline program still had 79% of the CPU bandwidth to handle the mainline functions. It was also tested at 8 mhz and found to run properly with 58% bandwidth available. An EEBasic chip with this driver installed is available from Dandy Solutions if desired (dandysolutions.com). The 2 USART version of the chip (based upon the Mega644P) should be specified since that provides a the second USART and allows the first USART to be the console. Andy Miyakawa is the Director of Software Development for Eclectic Electric / Dandy Solutions. His computer background extends from 1972 across desktop programmable calculators, minicomputers, microprocessors and microcontrollers and was part of the development team that created the 3270 interface IRMA for early era PCs. Questions and comments can be directed to him at andy@dandysolutions.com. All code and flowcharts within this document is placed in the public domain so that they can be used by anyone for any product. However, this application note remains the copyrighted property of A.S.Miyakawa. It may be distributed freely as long as it remains unmodified and this ownership statement remains attached. Copyright 2008 A. S. Miyakawa, All Rights Not Specifically Granted Above Are Reserved -15-