These are chat archives for esp8266/Arduino

28th
Apr 2016
Ivan Grokhotkov
@igrr
Apr 28 2016 02:42
@baruch yes, making delay a weak function is totally okay.
geman220
@geman220
Apr 28 2016 02:47
I have a full rotation servo, I have it working and it's turning open/close perfect. The servo is turning my blinds open/closed essentially, but since it's a continuous rotation servo I thought of a possible problem. If the blinds are fully closed and the message is sent to close the blinds the servo will obviously attempt to make a rotation, but will be unable to. Is there a way to read the servo position say at the open position, and recall that position? So that I could, in theory make the blinds recall the "safe" position before making another rotation? This way if the blinds try to rotate closed and are already closed the servo will first move to the safe position then close. Is something like that possible? I read into servo.read() but it doesn't seem like that will work.
Michael Miller
@Makuna
Apr 28 2016 02:52
@geman220 not using standard hobby servos. There are smart servos that support this, but they use a different protocol and cost much more. This is why early on I mentioned you would need switches, end stops, so at least you would know the fully open or fully closed state.
geman220
@geman220
Apr 28 2016 02:53
I see what you mean now, it was hard to understand exactly what you meant before I could have it up and running, sorry.
Could I attach like a paper clip to the servo in the down position, make it hit something metal, wire it to the esp and measure continuity?
So when the metal is touching don't spin
Michael Miller
@Makuna
Apr 28 2016 02:55
Micro switches are more reliable. Search, you will find this to be common issue. Some people use steppers instead of servos.
geman220
@geman220
Apr 28 2016 02:55
okay ty
Ivan Grokhotkov
@igrr
Apr 28 2016 02:56
@/all I'm planning to ask each person who contributed to this esp8266 core for a permission to relicense the code under Apache 2.0 license.
This obviously excludes any code inherited from arduino.cc, and any libraries which were not originally written in the scope of this project.
The reason behind this request is to reuse esp8266 code in the upcoming ESP32 core. I would like to make it easier for people to use this new core in commercial projects.
If anyone has some thoughts/questions/objections, please follow up :)
andig
@andig
Apr 28 2016 05:37
@igrr for the purpose of being able to distribute derived work without making he sources available? I wouldn't object to that as it doesn't hinder the core development in any way and may attract new talent.
Ivan Grokhotkov
@igrr
Apr 28 2016 05:44
Yes, for that purpose. From the emails i get, i see there is interest for using the core in commercial projects. But LGPL terms mean that you have to publish your object files at the very least. Since we have flash memory encryption in the ESP32 for the purpose of readback protection, it would be nice to give people an option not to publish their code, even in the form of object files.
Michael Miller
@Makuna
Apr 28 2016 06:44
While my contribution is not as great as some here, I have issues with people making a profit off work I have given to the community without themselves giving back to community. But I know of no way to police such contributions without licensing contracts which currently I don't believe is possible. As long as the accreditation is followed so at least it points people back to the community then as far as this project, I am ok with it.
Ivan Grokhotkov
@igrr
Apr 28 2016 06:48
@Makuna noted! I will think more about this.
Michael Miller
@Makuna
Apr 28 2016 06:53
Also, I don't have ANY concerns over someone selling a 100 units of something; They are more doing it for passion at those numbers and these kinds of people tend to contribute back.
Ivan Grokhotkov
@igrr
Apr 28 2016 06:56
The best (IMO) thing which i came up with goes like this.
Companies which want this core in their project and want to get some support while doing that, pay Espressif for the support. Espressif then gives back to the community by paying someone to work on the core.
So while they don't pay the people who contributed to the project directly, they do help the project as whole
Michael Miller
@Makuna
Apr 28 2016 07:01
Can you add something about them paying someone "competent" to work on the core ;-)
(that was a joke if it wasn't obvious)
seclorum
@seclorum
Apr 28 2016 07:09
greetings platformio'ers .. is there any word on when pio will catch up with the Espressif SDK .. which seems to be quite a few versions ahead of things ..
Testato
@Testato
Apr 28 2016 07:11
Whit the new licence the arduino API remain in the core ?
So we will have analogRead(); or Serial.print ?
Ivan Grokhotkov
@igrr
Apr 28 2016 07:42
@Makuna if you ever decide to switch jobs, then this can be arranged ;)
@Testato LGPL (and GPL as well) permit the use of header files which contain function prototypes, enumerations, and structure layouts, without having to license all the work under LGPL. So the plan is to take header files of Arduino core classes, and do a TDD-based clean-room implementation of them, under new license.
this isn't an awful lot of work, there are only a few classes (String, Stream, Print, IPAddress)
Me No Dev
@me-no-dev
Apr 28 2016 08:21
@igrr I would like to switch jobs :D
and what about all of the code I have written so far for the esp32?
Ivan Grokhotkov
@igrr
Apr 28 2016 08:34
if you can relicense the peripheral drivers you've written for the 32, that would be cool.
Me No Dev
@me-no-dev
Apr 28 2016 08:37
yes I can :) i believe we have talked about it before
don't i need to relicense the ones in this core too?
Ivan Grokhotkov
@igrr
Apr 28 2016 08:38
That's what i meant about peripheral drivers :)
i.e. "hal"
other stuff like bootloader, main, and some other things have to be done slightly in a different way...
Me No Dev
@me-no-dev
Apr 28 2016 08:39
do you have any info if anything that we have so far in the esp31b hat will chhange in the final?
Ivan Grokhotkov
@igrr
Apr 28 2016 08:40
I have. Yeah, a bunch of things will change. But I can't tell which ones exactly :)
Me No Dev
@me-no-dev
Apr 28 2016 08:41
i have not done any bootloader stuff on the esp32 ;)
it will be sad to see huge changes in the hardware rendering the code obsolete
Ivan Grokhotkov
@igrr
Apr 28 2016 08:42
Not huge, no. At least not in the peripheral domain.
Me No Dev
@me-no-dev
Apr 28 2016 08:46
that is good to hear :)
gitter really needs to add a smiley face ;) it looks like I'm laughing all of the time
Baruch Even
@baruch
Apr 28 2016 11:51
@igrr I'll cook up a patch and send a pull request
Baruch Even
@baruch
Apr 28 2016 11:58
How do you folks test a repository change? I don't want to replace the environment I use normally in platformio but I want to compile some code with the delay modification to make sure everything else compiles and works as usual.
Me No Dev
@me-no-dev
Apr 28 2016 11:59
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
Apr 28 2016 12:00
:-P
That sounds dirty...
Me No Dev
@me-no-dev
Apr 28 2016 12:01
it's pretty good actually ;) because it compiles all examples in the core against your patch
Ivan Grokhotkov
@igrr
Apr 28 2016 12:01
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
Apr 28 2016 12:14
@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
Apr 28 2016 12:15
@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
Apr 28 2016 12:15
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
Apr 28 2016 12:23
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
Apr 28 2016 12:28
Does what I say make sense?
Baruch Even
@baruch
Apr 28 2016 12:34
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
Apr 28 2016 12:38
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
Apr 28 2016 12:40
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
Apr 28 2016 12:41
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
Apr 28 2016 12:42
Let me sleep on it first, I'll see if I can wrap my head around this
geman220
@geman220
Apr 28 2016 14:22
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
Apr 28 2016 16:15
Baruch Even
@baruch
Apr 28 2016 17:56
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
Apr 28 2016 21:06
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.