DAC of Atmel xmega 128a3u

Notes about the DAC.

1. 12 bit resolution. -  not adjustable.

2. Conversion rates upto 1 million per second capable(as per datasheet)

3. There be 2 ways to trigger conversion on the DAC.

     a) The data registers are written(when high byte register is updated)

     b) Incoming event from xmega event system.(value in register when event arrives is converted)

Different trigger for the two channels is allowed.

>>>>Trigger mode configured in CTRLB register. 

4. Two data channels but ONLY ONE CONVERSION BLOCK.

>>>>channel operation mode config bits in CTRLB register

4a. Single channel operation - Conversion block always connected to channel 0 register and output channel.

       no sample hold circuit in this mode.

 
5. Refresh Rate -???

6. Voltage references
    a) Bandgap Reference = 1.1V
    b)Analog Vltg supply (Vdd)
    c) External reference(Vref+) >> PIN SHARED WITH THE ADC MODULE.

7. Capable of driving resistive loads of 1 kiloOhm

8. Calibration -
     offset(OFFSETCAL register) and gain(GAINCAL) can be calibrated.
     bit 6 determines direction of calibration, other lower bits decide magnitude.
    *automatic calibration can be done using ADC*
      Manual - 1. set data register value = 0x800 and tune offsetcal till DAC gives exactly half the reference voltage.
                     2. tune the gain value such that 0xFFF gives full reference voltage.
     calibration same for both the channels

9. Right adjusted/ left adjusted values - quite simple to configure.


Reference : Atmel Xmega DAC application notes

Polling based USART

Using the example code from AVR1307 documentation.

In the master side, we continually check for the data register empty flag(DREIF) in a do-while loop.
DREIF = 1  >>> Transmit buffer is empty
DREIF = 0 >>> Transmit buffer contains data to be transmitted.

So, if the DREIF is not set, then the controller is stuck here. Seems like a major problem.
As soon as the DREIF is set, we place the new data to be sent into the data register. and this loops.

On the slave side, we have the timeout and the Receive complete interrupt flag(RXCIF).
RXCIF = 1 >>> unread data is there in the buffer.
RXCIF = 0 >>> data has been read and the buffer is empty.

Either wait for the timeout or for RXCIF to be cleared. then read whatever data present in the data register into your variable. If master screws up, will end up reading zeros into the receive variable.

My problem statement -
If i want to run DAC and polled USART both at the same time, it would cause problems, i suppose.
DAC conversion is based on timer overflow, event based conversion. this exists in the while(1) loop.

I would have to add the USART receive code also in the while loop, as i need to continually monitor the RXCIF flag. once i receive data, i have execute the receiving code for the number of bytes that are to be received. Time out would be needed during reception but not after.

Considering the transmitting controller, it has USB running. every 1 ms the controller is interrupted.
I think i need to figure out exactly how the program execution flows in the USB, so that i know which route the controller is taking and then to catch it between interrupts and send the data to be sent.

Work to be done on both transmitter and receiver side.
Its like whatever i have done for a year makes no sense now.
Crap.

USB development

USB product development has been made extremely easy by Atmel for the XMega series microcontrollers.
Lot of examples and guides to quickly make your own HID device.

In case anybody gets into this, here are some important files you need to look at -

ui.c
conf_clock.h
conf_usb.h
udi_hid_generic.h
usb_device.c
udi_hid_generic.c