element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
    About the element14 Community
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Japan
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      •  Vietnam
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Raspberry Pi
  • Products
  • More
Raspberry Pi
Raspberry Pi Forum TCP/IP commnunications while GPIO interrupt
  • Blog
  • Forum
  • Documents
  • Quiz
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Raspberry Pi to participate - click to join for free!
Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • State Not Answered
  • Replies 20 replies
  • Subscribers 708 subscribers
  • Views 4960 views
  • Users 0 members are here
  • raspberry_pi_b+
  • raspberry_pi
  • raspberry-pi
Related

TCP/IP commnunications while GPIO interrupt

e14 Contributor
e14 Contributor over 11 years ago

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
  • Sign in to reply
  • Cancel
  • rew
    0 rew over 11 years ago in reply to michaelkellett

    The ADC is very likely just a slave. I searched for "SPI adc 16 bit" on farnell and chose the cheapest (about EUR 3.50) of 30 options and ended up with the ADS1118 from TI.

     

    If you have that one, I THINK you can set up a big SPI transfer, and make sure that you transfer exactly 32 bits every 60 microseconds. Then, when the 32 bits are done, you can hope the next ADC is already done, so DOUT/DRDY will immediately signal "new data" and you can continue to clock it.

    Ok. With this chip that won't work. It won't be ready after 60 microseconds: It requires 1.2 miliseconds for a conversion. I should have chosen the EUR 5.50 BB/TI ADS8320, which DOES have the performance that our thread-starter here requires). On the other hand, It is not immediately clear in that datasheet that keeping CS low will work.

     

    So.... With knowing what chip, and some trickery something will be possible...... But... you have to "know your ***".

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • michaelkellett
    0 michaelkellett over 11 years ago in reply to rew

    Well, in real life, where I do a lot of this kind of thing, I very often have an FPGA to take care of cranking the ADCs. But then the problems come from things like trying to clock serial data out of the ADC at 100Mhz or faster .......

     

    Not much more to be said until the OP tells us more about his ADC.

     

     

    MK

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • clem57
    0 clem57 over 11 years ago in reply to e14 Contributor

    May I ask this one question: Is this data being used in real time on the PC server?

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • e14 Contributor
    0 e14 Contributor over 11 years ago in reply to clem57

    I am implementing a 4- or 8-channel acoustic data acquisition system.

    The transferred multichannel data are analyzed on the PC server to determine the acoustic source position in real time.

    Thus, the data transmit should be done in maximum 100 ms interval.

     

    Thank you Clem for your interst in my problem !!

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • michaelkellett
    0 michaelkellett over 11 years ago in reply to e14 Contributor

    Can you tell us what ADC you are using and possibly post a schematic of how it is connected to the PI.

     

    MK

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • e14 Contributor
    0 e14 Contributor over 11 years ago in reply to rew

    Unfortunately, I am trying to acquire acoustic data using external ADC and SPI communications, not in ADC in BCM2835.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • rew
    0 rew over 11 years ago in reply to e14 Contributor

    Can you tell us what ADC you are using and possibly post a schematic of how it is connected to the PI.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • clem57
    0 clem57 over 11 years ago in reply to e14 Contributor

    After thinking over this, I would get a UART on the Pi side(Tx,Rx) to USB 2.0 adapter on PC Server. I hope the two can be close to each other. The software setup would look like a COM port on the PC and GPIO pin logic on the Pi side. Runnin this at a high rate should be little trouble up to 250+ megabytes per second.

     

    image

    Micro SATA Cables - USB 2.0 to TTL UART 6PIN Module Serial Converter CP2102 Personal Computer Product

     

    $4.97 by Micro SATA Cables

     

    Clem

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • michaelkellett
    0 michaelkellett over 11 years ago in reply to clem57

    I'm not quite sure how this would help, first of all USB 2 UARTS can't manage anything like 250Mbytes/second - the top rate in theory would be be about 50Mbytes/sec but in practice will be much lower. FTDI's FT2232H chip can only manage a maximum of 12Mbit/s in UART mode although its USB side can go at the full 480Mbit/s USB2 High Speed rate.

     

    And then the problem is not so much getting data out of the Pi at the required rate but one of transferring it into the PI without getting interrupt/latency induced glitches.

     

    MK

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • Problemchild
    0 Problemchild over 11 years ago

    16 K interrupts per second is a very large number for a whole Linux infrastructure to be disrupted. The overhead is quite probably eating right into your available CPU power just there. Rather than a simple ADC I would suggest you use an audio CODEC IC which although a little more complex than a simple ADC has everything already sorted and probably a big buffer meaning that you can sample at higher rates with out excessive interrupt overhead. Take a look at the Wolfson Codec strapped to the Audio board that E14 sell this would sort you out if it does recording ....Yes it does image

     

    Signal conditioning and everything else in one ready for your application.  This will reduce your overheads supporting realtime sampling costs of construction etc even if you change after prototype stage!

     

    John A

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
<
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2026 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube