Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
Forum Thread Details
  • State Not Answered
  • Replies 20 replies
  • Subscribers 677 subscribers
  • Views 3984 views
  • Users 0 members are here
Related

TCP/IP commnunications while GPIO interrupt

Former Member

Hi,

 

I am developing an audio recording system using Raspberry Pi B+.

 

To guarantee the sampling rate, an external GPIO interrupt with 16 kHz  was implemented.

Then, for each interrupt, A/D conversion having 16-bit resolution was followed to get a sample.

Finally, for every 100ms, the buffered 1600 samples were transmitted to the server PC by applying TCP/IP-based communications.

 

However, I found that several samples were missed whenever the buffered samples were transmitted by TCP/IP.

I doubt that the GPIO interrupt for A/D conversion was missed whenever the TCP/IP socket communications are executed.

 

The core program codes written in C are as follows.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

        struct sockaddr_in server_addr;

 

        //External GPIO interrupt setting      

        wiringPiSetup();

        pinMode(5, INPUT);

        wiringPiISR(5, INT_EDGE_FALLING, &ISR);

 

         //Setting for TCP/IP socket communications

        Socket = socket(AF_INET, SOCK_DGRAM, 0);
        bzero((char *)&server_addr, sizeof(server_addr));

        server_addr.sin_family = AF_INET;
        server_addr.sin_addr.s_addr = inet_addr("192.168.0.3");
        server_addr.sin_port = htons(8101);

        connect(Socket, (struct sockaddr *)&server_addr, sizeof(server_addr);

 

        while(1)

        {

              //Buffered samples transmitting

              if(buffFullFlag == TRUE) write(Socket, buf0, BUF_LEN*sizeof(unsigned short));    

         }

 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

The attached file shows an example of the waveform of transmitted data.

 

Could you tell me the reason and solution about my problem ??

Attachments:
imageGPIO interrupt error.pdf
Parents
  • 0

    Hi Sam,

     

    You'll see this issue because while you may be using an ISR in the WiringPi library, your code is still running in user space (as I understand) and thus has to still battle with other processes. I'm not familiar with WiringPi however so I could be wrong. You could run as root user to see if this makes a difference. Linux user apps are not suited for such responsiveness where jitter is a concern - you will need to either do this in a custom driver, or use an external microcontroller perhaps.

  • 0 in reply to shabaz

    and @

    are both right. In computer parlay, we call this "two ships passing in the night". With the interrupts coming in at 16 Hz and being higher priority than the TCP/IP task(s) this can be trouble. Keep in mind that TCP/IP is layered and heavy in code. It will under the covers break up the stream of bits into packets of around 1500 bytes on average. So if you look at the gaps, I can imagine they are about this much in length. Another issue is reliability since IP level is not reliable. If the transmits get garbaged, a retransmit occurs. You are at the mercy of these things.

     

      So what can you do? Double buffering would be great. Or barring that, start your code with a memory copy from receiving buffer to a separate transmit buffer before sending. This would have a better chance of being done without an overwrite (99 44/100%)image.Could leave a flag set for the interrupt routine to know the sending buffer is not yet flushed to log how many times this occurs. See this, maybe play with buffer size to optimize the code.

     

    Clem

  • 0 in reply to clem57

    Thank you Clem !!

     

    First, I want to tell you that I am developing sample acquisition using

    external A/D chips and transmission of the converted samples through the Internet.

     

    But, I already applied the "double buffering" scheme you have told.

    That is, when the number of  ADC samples are 1600, the buffer is

    copied to another buffer for TCP/IP transmission.

     

    Just now, I modified my source codes to use UDP instead of TCP/IP.

    Although the sample missing is reduced, it does not disappear perfectly.

     

    In my opinion, one strong candidate solution of my problem is to use DMA

    for SPI communicatrions.

     

    Could you tell me where I can get the related source codes ??

  • 0 in reply to Former Member

    Your current "architecture" has userspace code running in places that are VERY time critical.

     

    Just because I say that "using DMA" may solve your problem. doesn't mean that your problems go away if you still have the userspace triggeriung the SPI transfer, and then having to store the results.

     

    As long as you're storing the results in userspace you're going to miss samples.

     

    To make this work perfectly you should set a timer to go off at 16 kHz,  start the SPI transfer in the interrupt routine (i.e. in kernel space) and of course use DMA for input and output of the SPI.

     

    But... If you are sampling AUDIO at a rate, between "good for voice" and "good for music", why not use an AUDIO ADC and connect it to an I2S port? I2S is sufficiently like SPI that the module in the chip is usually combined. Maybe the SPI module of the BCM2835 can do I2S?

Reply
  • 0 in reply to Former Member

    Your current "architecture" has userspace code running in places that are VERY time critical.

     

    Just because I say that "using DMA" may solve your problem. doesn't mean that your problems go away if you still have the userspace triggeriung the SPI transfer, and then having to store the results.

     

    As long as you're storing the results in userspace you're going to miss samples.

     

    To make this work perfectly you should set a timer to go off at 16 kHz,  start the SPI transfer in the interrupt routine (i.e. in kernel space) and of course use DMA for input and output of the SPI.

     

    But... If you are sampling AUDIO at a rate, between "good for voice" and "good for music", why not use an AUDIO ADC and connect it to an I2S port? I2S is sufficiently like SPI that the module in the chip is usually combined. Maybe the SPI module of the BCM2835 can do I2S?

Children
No Data