Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Me No Dev
@me-no-dev
when you make a PR the system will run a check :)
if it fails, a slightly embarassing message will pop up on the right of the chat to let you know that you failed
message is visible in the PR as well (and you can see what failed where)
Baruch Even
@baruch
:-P
That sounds dirty...
Me No Dev
@me-no-dev
it's pretty good actually ;) because it compiles all examples in the core against your patch
Ivan Grokhotkov
@igrr
You can run the tests locally as well. See .travis.yml for the commands to run tests
Also there is a pull request for the setup to run tests on ESP, which i haven't merged yet.
Baruch Even
@baruch
@igrr I have the patch ready. I can also put forth the cooperative threading code I made, still without making use of the delay override though.
If someone wants to take a look at this it can be seen at https://github.com/baruch/esp8266_smart_home/tree/master/arduino/lib/CooperativeThread
Ivan Grokhotkov
@igrr
@baruch could you take a stab at pulling this into the core, and replacing g_cont with an instance of that thread?
Baruch Even
@baruch
and for comparison you can look at the same directory for the node_soilsensor code which is still a state machine
Not sure what you mean, you want the threading to jump back right to the new coop thread?
Right now I always jump to the main thread and from there jump to the different threads
This means that the main thread can also be the scheduler
otherwise I will need to add a scheduler to the core and it will cost everyone some performance for no benefit to them
Looks like I might need to do something about non-delay users of ets_yield too, or we will not return to the correct code. I thought only delay would use it but others do too.
Ivan Grokhotkov
@igrr
These other uses of esp_yield essentially work like condition variables.
But since there was only one instance of cont_t, these condition variables were not attached to cont_t instance, but were global
I suppose we could implement something like wait_for(condition), and use that in place of esp_yield, that would simplify things
where condition would be an object which would track which cont_t instance is waiting on it and would resume it
then a CooperativeThread would simply have a condition inside and do a wait_for on it, just like all other users
i.e. ClientContext would also have a condition and use it to control the flow of connect, read, write methods
Ivan Grokhotkov
@igrr
Does what I say make sense?
Baruch Even
@baruch
I need to think about it
So far I added a g_cur_cont which is used by all uses of g_cont and will allow to set it externally by the thread code before switching to its own thread. This will allow everything to work, but will simply be blocking inside the thread.
What you suggest seems to allow for complete threading between all threads, but the issue then is that it will require an addition of a scheduler, though it may work naively like it does now without a scheduler.
Ivan Grokhotkov
@igrr
i don't think adding a scheduler is such an overhead. it basically maintains an array of threads and runs the ones which aren't paused in a round robin fashion
Baruch Even
@baruch
It's not a big overhead but for most people (possibly all but me) it is not needed. I'll try to see if I can find a way to make it work as it is now when all inactive and still add a scheduler when one is needed.
I was trying to minimize the impact of my crazy ideas on others
Ivan Grokhotkov
@igrr
I feel like it's a premature optimization. First implement it, measure the impact and then, if it's really noticeable in a real application, do something about it.
But if you'd like to think about optimizing this, i'm not going to stop you :)
Baruch Even
@baruch
Let me sleep on it first, I'll see if I can wrap my head around this
geman220
@geman220
I was reading into the ESP WiFi Mesh but there seems to be almost no documentation on how it functions. Is it just setting the ESP to AP+STA? So say for example you have 10 ESPs all 10ft from each other down the line, and your internet facing WiFi can only reach the first 3/10 ESP. Would WiFiMesh create a unique AP+STA on each ESP basically repeating the signal down the line of ESP? Or is this creating a true mesh network where each node will relay the network information / data.
Ivan Kravets
@ivankravets
Baruch Even
@baruch
I've updated from 2.1.0 to 2.2.0 and now it fails to build under platformio due to includes of ../generic/common.h, did anyone notice this? what's the way to fix this?
seclorum
@seclorum
yeah i just noticed the same problem.
gotta say, i'm a little sad that every time i've updated pio, something breaks and my project suffers
i worked around it by commenting out the #include in arduino_pins.h
this to me seems to be a bug. what a pity that platformio doesn't seem to have appropriate tests in place to catch these sorts of bugs, alas.
Baruch Even
@baruch
Are they repackaging and modifying the code from git or are they using it as is?
Michael Miller
@Makuna
@anyone, is there a limit to the number of arguments to a function? I know with AVR it was small but it might have changed since they moved to C11.
Baruch Even
@baruch
I would think that every argument that can't go to a register will be in the stack (assuming some even go in registers in the first place)
After that you are only limited by stack space...
This is a more modern 32bit mcu so I assume no real limits
Michael Miller
@Makuna
@baruch It would seem so, but many platforms impose a limit; just wondering if anyone has hit it yet. I hit it once with a Win32 App, the limit was due to optimizer and could be increased with a flag.
sticilface
@sticilface
Has anyone had any success in trying to flash an ESP via a TEENSY 3.1... I can get it to kind of work... but it bails mid way, and fails....
Me No Dev
@me-no-dev
how are you trying to flash it "via"?
transparent serial or trying to replicate the protocol?