ESP8266 Community Forum

- Wed Oct 05, 2016 10:45 am #56104 Hi,

I´m missing my callback from the gpio.serout() function. I´m suspecting the uart is somehow blocking it, since it only disappears once some input is given. Preferrably if much input is given at once. Here some isolated code:

Code: Select allpin = 6;
occupied = false;

-- callback resets the occupied flag
function seroutCallback()
    occupied = false;
end

-- gets run every 50ms
function timerCallback()
    if occupied then
        print("occupied");
    else
        print(" not occupied");

        occupied = true;
        -- gpio.serout() is asynchronus, if a callback is provided
        -- the times dont matter
        gpio.serout(pin, gpio.LOW,{5000,5000,5000,5000,5000,5000,5000}, 1, seroutCallback);
       
    end
end


tmr.register(3, 50, tmr.ALARM_AUTO, timerCallback);
tmr.start(3);

The output looks something like this: ( the numbers are some random input echo´d over the uart)
(run @9600 baud)

Code: Select all 
[...]
 not occupied
 not occupied
 not occupied
 not occupied
 not occupied
 not occupied
 not occupied
 not occupied
1234567890123456789012345678901234 not occupied
567890123456789012345678901234567890123456789011 not occupied
234567890123467890123456789012345678901234567890 not occupied
123456789012345678901234567890123456789012345678 not occupied
901234567890123456789012345678901234567890123456 not occupied
7890123456789012345678901234
stdin:1: unexpected symbol near '12345678901234567890123456789012345678901234567890123456789012345678901234567890112345678901234678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234'
> occupied
occupied
occupied
occupied
occupied
occupied
occupied
occupied
occupied
occupied
occupied
occupied
[...] ( it never recovers, the callback went missing)


In this isolated state you need quite a lot of data to break it. In the application I want to use it , it disappears after a couple of symbols. ( With a server running in the background). Running at 160 MHz improves slightly. Running at higer baud too, but my project requires 9600. The waveform outputted by serout() looks fine. Tried different nodemcu versions. I´m out of ideas.

Another weird thing: Before I implemented this check, (check if the callback finished) I was getting cryptic error messages somewhat like: "already freed 0x[random adress] \n Attempt to call a nil value in LUA Api" (not the exact error message, but google didnt find anything). I suspect the callback didnt get freed properly and was sitting somewhere waiting to crash my project. Digging in the source code i found that the serout_async function emits a low priorty task, but since I´m new to Micros, the source code is more cryptic to me than the error message.

So my question is: Is this a bug or is NodeMCU just not capable of running a reliable uart?

If you are interested: The project is a communication interface to my selfmade drone. Im able to fly it over wifi ( at least in my living room. I need to do some range testing on the weekend, I know it wont be good ), but I´d love to get some telemetry data (9600 baud limitation) back to the ground.

- Thu Oct 06, 2016 2:38 am #56135 Which version of the firmware are you using?

- Thu Oct 06, 2016 8:07 am #56146 Unless its been changed since the last time I used LUA the serial buffer was 256 and could not be changed .
Are you sure you are not over running the buffer ,,,,,, I just got dropouts/ missing data , but no hangs

- Fri Oct 07, 2016 10:06 am #56186 Im aware of the limitation, but

Which version of the firmware are you using?

I´m using the custom build tool nodemcu-build.com and tested with the default modules on master and dev and also with some older firmware i had laying around.

Unless its been changed since the last time I used LUA the serial buffer was 256 and could not be changed .
Are you sure you are not over running the buffer ,,,,,, I just got dropouts/ missing data , but no hangs

In my application i get this also after a couple of symbols, that are send seconds apart. But I´m also using a custom lua callback that processes a couple of symbols. But i thought the overflow would be catched by the mentioned buffer. So maybe a solution would be to create a custom firmware with higher uart priorities?

Nevertheless this seems odd to me, because why should a completely unrelated callback dissapear? I would actually be okay with some corrputed data. I´ll look deeper into the firmware once i have some more time.