The firmware continuously sends and receives eight bytes of data to and from the PC. Ports C and D of the microcontroller are connected to CON1 digital I/O pins. The first two bytes from the PC contain data for data direction registers (DDRs), namely, DDRC and DDRD. The next two consecutive bytes, i.e., the third and the fourth bytes, contain the value that is to be written to each port. Each bit in the register DDRx and PORTx values corresponds to a physical pin of the microcontroller’s ports C and D. For example, to set the fourth and sixth pins as outputs, you need to write to the DDRx register a value equivalent to the binary value ‘00101000.’ To set the fourth pin ‘high’ you need to write to the corresponding PORTx register a value of ‘00001000.’ Writing ‘1’ at any other place in the PORTx register will enable the pull-up at the corresponding physical pin. The pins are input pins by default.
The remaining four bytes are the values for DAC outputs. These are transferred to TLC7226’s parallel input pins via port A of the microcontroller. To write a value to the DAC output, select the DAC output by A0 (pin 17) and A1 (pin 16) of the chip TLC7226, make the selected pin active by lowering WR pin (pin 15) of the chip, write the value to data pins of TLC7226 (DB0 through DB7) and finally make WR pin high before exiting the write subroutine.
The firmware sends in the first six bytes data collected from the analogue input pins of the microcontroller. The remaining two bytes sent by it contain the pin status of 8-bit wide port C and port D, respectively.
If you are not using the digital input pins, the firmware can be modified to read all the available eight analogue inputs of the microcontroller. By receiving and sending ten bytes, the code can be extended to use all the analogue inputs without disturbing the digital inputs. However, this reduces the sampling speed.
All the analogue inputs are sampled one by one and copied to the send buffer. It is advised to connect the unused analogue inputs to ground, to make the sampling stable. You are requested to go through the files board.c and GenericHID.c in LUFA101122\Demos\Device\LowLevel\GenericHID folder of the project for extensive reference. The codes are well remarked for future modifications. All the relevant source codes are included in this month’s EFY DVD.
As the microcontroller has its own timers, the code can be extended to have a fixed sampling speed for any real-time application. Filters can also be implemented in the firmware itself for noiseless sensing.
The software implements the ATMEL application note on USB generic human interface device (HID). It uses functions findHidDevice, readData, writeData and closeDevice defined in ATUSBHID.DLL. As shown in the GUI screenshot, the software connects to the DAQ board through USB vendor ID for ATMEL (03EB in hexadecimal) and product ID for the microcontroller (204F in hexadecimal).
An 8-byte send-buffer is prepared based on the settings of digital input/output selections, their corresponding values and analogue output values. This is sent continuously through a timer event in C# routine, within an infinite loop in LabView scheme.
Similarly, the incoming eight bytes are read to obtain the six 8-bit analogue input values corresponding to the voltage available at ADC pins and two 8-bit values for the input pin status. The graphical user interface (GUI) shows the various ADC inputs and DAC outputs.
Fig. 7 shows the front-end GUI screenshot of C# program output. Fig. 8 shows the block diagram for LabView VI, which generates a GUI analogous to that generated by the C# program. Additionally, it explores the digital input and output capability as well. LabView being a block-diagram-based programming language, it explains the functional implementation of the software very clearly. A 30-day evaluation version of the latest LabView version can be freely downloaded from the Internet.
The C# program and the LabView VI are used only to demonstrate the correct functioning of the board. On similar lines, you can develop your own code in various other programming languages. (Note that LabView was not tested at EFY Lab.)
Testing and test results
Before getting started, using a multimeter you need to measure the USB voltage that your system is supplying. Save this value in the parameter V_Max_USB of the program.
The developed prototype was tested with various sensors like potentiometer, LDR and analogue accelerometer. The sensed ADC output shown by the software was found to be closely matching with the physical measurements.
Similarly, the DAC outputs were tested physically using a digital multimeter and found to be in agreement with the desired voltage values set in the software. Maximum variation from the actual value was found to be within ±0.02V. Apart from the ADC and DAC tests, the digital inputs and outputs were found to be responding properly to the software. Figs 9 and 10 show the plots for the ADC and DAC tests, respectively.
With Generic HID mode of USB communication, the device runs at 9.6 kilo-samples per second, which is good enough to handle a situation where the inputs and outputs are dynamically varying. Though the developed DAQ device is quite basic compared to the existing technology, it can be very helpful for everyday use where one needs an inexpensive device with reasonably good reliability and precision. It has the potential to replace advanced DAQ devices like NI USB 6008/6009 (which it closely resembles to) in smaller enterprises that don’t have much stringent demands and certification requirements.
If the software on your PC doesn’t respond, first check the circuit for proper connections. You can also try closing the application and restarting it. If the problem persists, check voltages at various test points as per Table II.
The author has uploaded on YouTube videos of this DAQ device being tested using C# and LabView interface. You may watch the same for better understanding.
The board can be reprogrammed for different purposes with different customised programs for the connected I/Os.