Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 4 of 4

Thread: Ethernet Audio library and web server in one project(?)

  1. #1

    Ethernet Audio library and web server in one project(?)

    Before I go down the rabbit hole, I figured I'd ask....

    Are there any technical limitations of having a small web server running parallel to the Ethernet Audio library?

    The web server example works fine on the hardware. But when I try to integrate it into my ethernet audio project, the setup works (server.begin()), but the first time it calls
    Code:
    EthernetClient client = server.available();
    the teensy crashes.

    Aside from letting the EthernetAudio handle setting up the SPI, MAC and IP, my code is copied and pasted from the webserver example. I recognize the way the example is written, it's blocking so I would rewrite it to keep loop times low. But it's not getting past the first line.

  2. #2
    Correction, it actually loops about 80 times before it crashes.

    It crashes in socket.cpp EthernetClass::socketStatus()

    Code:
    uint8_t status = W5100.readSnSR(s);
    I don't see a function called that so I don't know were else to go.

    Going to assume this is some SPI collision again. uhg.

  3. #3
    I was able to get this to work intermittently by NOT calling
    Code:
    EthernetClient client = server.available();
    every loop, but every 1000 loops. Now I know that's a terrible idea but it was just a test.
    It is still very flaky. Most of the time it still crashes shortly after boot.
    Other times it goes for a while. But while the few times it doesn't crash right away, it will serve the web page, but it won't close the connection.

    You can see the two sockets..
    Code:
    Socket#0:0x22 8888 D:10.0.0.255(8888)
    Socket#1:0x14 80 D:0.0.0.0(0)

    I think I just need to take a deep dive into how the ethernet and ethernetaudio library work. I need to figure out what is clashing. People wonder why I always tend to write everything from scratch whenever possible. Libraries are great time savers, until they aren't. Sure it would take me a long time to write my own library, but at least then I'd know how it works when something breaks. It takes just about as long to troubleshoot someone else's library...

    Back to work.

  4. #4
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,491
    @wwatson did a USBHost lib for USB using a dongle to wired ethernet that worked well. Not sure if that experience relates?

    That example used the TeensyThreads to periodically call some check polling/update funcs and over calling that was bad. That was on the USB side of things and may not directly relate ... so just FYI. The change that made it work there was this well named '#ifdef HACKED' add I tried and found to work in that code that limited loop cycles per time slice:
    Code:
        #ifdef HACKED
        cc++;
        if ( cc > 20 ) {
          cc=0;
          threads.yield();
        }
        #endif
    Anything called in loop() - depending on the Teensy and what else happens each loop cycle can call 50K to 5+ million times per second if not gated. So rate limiting calls to some functions can be important - saves cycles and some things go bad when over polled.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •