How to Create a DAQ without Interrupting Data Streams

  • Thread starter Thread starter taupune
  • Start date Start date
Click For Summary

Discussion Overview

The discussion revolves around the challenges and considerations involved in creating a data acquisition (DAQ) system. Participants explore technical issues related to data transmission protocols, microcontroller selection, and the design of the main program structure, including the use of loops versus interrupts.

Discussion Character

  • Exploratory
  • Technical explanation
  • Debate/contested
  • Mathematical reasoning

Main Points Raised

  • One participant expresses concern about interrupting SPI communication to send digital I/O data, which could spoil the bit rate of the data stream.
  • Another participant suggests that sharing serial communication lines with digital I/O could lead to confusion, particularly with I2C communication.
  • There is a discussion about the choice of microcontroller, with one participant indicating a preference for PIC due to cost, but considering ARM for future upgrades.
  • Participants discuss the potential need for a USB interface and various communication protocols, including SPI, I2C, CAN, and Ethernet.
  • One participant raises the question of whether to use polling or interrupts for the main program, emphasizing the importance of timing and resolution for data acquisition.
  • Another participant highlights the need to consider the timing overhead of data acquisition and the number of inputs when designing the system.
  • Concerns are raised about handling situations where a digital signal needs to be latched during an ongoing SPI data transfer, questioning how to manage timing without losing data integrity.

Areas of Agreement / Disagreement

Participants express various viewpoints on the best approach to handle data acquisition and communication protocols, with no clear consensus on whether polling or interrupts are preferable. The discussion remains unresolved regarding the optimal design choices for the DAQ system.

Contextual Notes

Participants mention several technical considerations, such as the timing requirements for data acquisition, the resolution of ADCs, and the potential impact of communication speed on data integrity. There are also references to the limitations of using certain microcontrollers and the challenges of integrating multiple communication protocols.

Who May Find This Useful

This discussion may be useful for individuals interested in designing data acquisition systems, particularly those exploring the integration of various communication protocols and microcontroller options.

taupune
Messages
25
Reaction score
0
Hi,
I am wondering and been thinking and planning to make a daq for quite a while this couple of months. How can you make one?
I know how to program but a few technicalities are on my way, for example:
When I am sending data through SPI and than I need to send something through digital I/O , the spi has to stop, send my I/O data and than finish with my SPI. The problem is that, SPI has to have a certain speed , and by interrupting it to deliver my I/O data i am spoiling the bit rate of SPI or I2C ( or any serial data stream for that matter).
Another issue and probably the biggest one.
I would like to make an infinite loop that would run all the time and the type of ports that need to be used would be inputs to this main program. The reason would be , so that the end user won't have to program the specific chip and also they won't have to compile anything. He/she/it would just pick up the data type they need , and if they need any other port they can do that later at any time. So what can I use for this main program? Loops, or interrupts?

Are these all the challenges I am going to face or I will have abundantly more?

Thank you.
Looking forward to your inputs.
 
Engineering news on Phys.org
taupune said:
Hi,
I am wondering and been thinking and planning to make a daq for quite a while this couple of months. How can you make one?
I know how to program but a few technicalities are on my way, for example:
When I am sending data through SPI and than I need to send something through digital I/O , the spi has to stop, send my I/O data and than finish with my SPI. The problem is that, SPI has to have a certain speed , and by interrupting it to deliver my I/O data i am spoiling the bit rate of SPI or I2C ( or any serial data stream for that matter).
Another issue and probably the biggest one.
I would like to make an infinite loop that would run all the time and the type of ports that need to be used would be inputs to this main program. The reason would be , so that the end user won't have to program the specific chip and also they won't have to compile anything. He/she/it would just pick up the data type they need , and if they need any other port they can do that later at any time. So what can I use for this main program? Loops, or interrupts?

Are these all the challenges I am going to face or I will have abundantly more?

Thank you.
Looking forward to your inputs.

By DAQ, do you mean data aquisition device? Like a general digital IO device?

You would not normally share serial communication lines with general digital IO -- that would confuse whatever was on the other end of the serial communication lines. At least with SPI comm, you can de-select all slave devices, and the master could then re-use the MOSI, MISO and CLK lines for some other purposes, I suppose. But with I2C comm, I don't think you would be able to effectively use the SCL and SDA lines without causing problems at the slave devices.

What microcontroller (uC) are you targeting? Have you looked at commercial DAQ units from Omega, National Instruments and other manufacturers to see what features you want to include in your device?
 
Yup , DAQ = data acquisition device
I am planning on using Pic since they are dirty cheap, but later on, once I have some solid code, I might upgrade to arm since they are quite powerful, and not that expensive at all.

I have seen online some DAQ and the options and features they give seem to be the same ones that come from pic families. I can't afford to buy and peak what's inside.

I have some experience with NI daq's and I cannt backbite the company but I wasnt that happy with what I had. I got the cheapest though, but it was still a couple of hundred bucks ( I didnt buy it , my prof bough for some work in the lab).

The SPI and I2C have their own pins. While sme pins have dual use I don't intend to use them that way, they will have only one function their entire code, till the device restarts.I would like to have USB ( for connection to PC), digital i/o , SPI, I2C, probably CAN and even ethernet ... I know I am pushing it to far. I am a little concerned about the speed and the interface that will have with the user, i.e the main executable program.

A side question for you berkeman, is it helpful to have radio license to land a job in communication ( does it impresses the interviewer) ? I just graduated and need to keep my mind fresh.
 
Is there a relatively inexpensive PIC eval board with the USB interface chip and connector already on it? That would seem like a good platform to use for your initial DAQ module development work.

On the amateur radio license question, I don't think having the HAM license by itself will stand out on a resume. If you were a HAM who had built a lot of RF projects on your own (especially a software defined radio, or a full-featured digital+analog radio setup), then that would stand out on a resume for general EE work and especially RF EE work. But it's the project experience that would stand out, not just having the basic license.
 
I have a development board for PIC already, but it uses serial , which is not of big concern to me at the moment. So what would be your suggestion at developing my main prrogram? Should it run interrupts or using a loop to check the status for any new inputs?

How can I avoid interrupting sending some serial data, in order to send a digital i/o signal? I thought of parallel programing but an old TA of mine advised me to stay away or I will get a let of mess and i won't ever be able to do it, which I agree.

Thanks for the HAM tip. Doing a software radio is in my to do list, but will take some time. :(
 
As far as polling or interrupt structures for your DAQ, the main questions to ask are:

What kind of timing do you want (new data every xxx us) - or do you even care?
What kind of resolution for your ADC are you running?
What is the timing overhead of the data acquisition (each ADC reading takes xxx us, etc.)?
How many inputs do you intend to carry? (x analog and x digital)?
What kind of speed do you want to carry for your communication?

Based on the above you can start to break down how you want to execute the code. If you don't care if the sampling occurs at precise intervals, than polling works best. For consistency's sake, I would most likely use an interrupt structure, but you could always start with polling and change the code later.

Remember that the number of channels and resolution will alter how long it takes to sample your inputs. In addition, depending on your communication protocol and speed, you might end up sending 'old' data multiple times prior to getting new data.

If you go the interrupt approach, be sure to check the interrupt priority between the communication interrupt and the data acquisition interrupt.
 
I would like to have the serial communications ( SPI, I2C) the fastest, probably above 1MHz, and the digital I/O ... i want them fast , but don't have to be as fast.
Oh, about precision, I want it to be as accurate as possible. Thats one design criteria. For analog, I might include 1 input at about 1-10 khz.

One issue i will face for sure. What can I do in such situation: 1 mb of data going through SPI , and sometime in the middle of data transfer , a digital pin has to latch.I will I handle it? If i stop the SPI data, the speed and timing will go bad, and if i wait till data is finished ... well by that time the digital signal would be waste. How can I handle this?

Thank you.
 

Similar threads

Replies
7
Views
3K
Replies
5
Views
2K
  • · Replies 22 ·
Replies
22
Views
5K
  • · Replies 4 ·
Replies
4
Views
3K
Replies
7
Views
2K
  • · Replies 31 ·
2
Replies
31
Views
3K
  • · Replies 8 ·
Replies
8
Views
2K
  • · Replies 7 ·
Replies
7
Views
2K
  • · Replies 2 ·
Replies
2
Views
1K
  • · Replies 2 ·
Replies
2
Views
2K