Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Michael Miller
@Makuna
consider exposing another function like CoDelay ().
geman220
@geman220
Serial.begin(115200); I changed my monitor to 115200 still not seeing anything for some reason
Michael Miller
@Makuna
@geman220 backup, try a simple example with Serail output and see if it works.
geman220
@geman220
Okay, one second
Michael Miller
@Makuna
@baruch but as you said, it won't effect others who are using your replacement.
Baruch Even
@baruch
@Makuna but then I need to modify every library I use, I can do that and will if the weak symbol is not acceptable, it's just a bit more tedious and requires a review of each library I integrate. I'm not espousing making everyone use such a threading library as it requires some care, but given the right care it makes other code simpler and easier to follow. Which means I can care once for the hard part of the threading and coroutine and later on enjoy easier development.
I'm too lazy to work hard to code a state machine for each sensor I want to monitor :-)
I'm also used to using coroutines elsewhere and find them very appealing
geman220
@geman220
If anyone can point me in the direction of what I'm doing wrong I'd be very appreciative. My ultimate goal is to have my Wemos subscribe to a topic and turn a servo based on a message published to that topic. My Wemos is connecting to my WiFi and it is connecting to the MQTT broker. I have a topic /log and /status and when I send a message to the command topic the Wemos is responding correctly in the log topic with "Command [command] received". In my status topic the Wemos is reporting "Connected" once it's rebooted. The problem I'm obviously having is making the Wemos turn the servo when a specific command is received. I'm new to this and I thought what I had would work, but obviously it's not. Also for some reason my Serial monitor refuses to work. If anyone can take a look at my code it would be a massive help, thanks. https://www.pastery.net/hxerce/
Michael Miller
@Makuna
@geman220 servo is on pin 1, comment states pin 5. You reset the pin after calling servo.attach, don't do that.
geman220
@geman220
Yea sorry I didn't change my comment the problem was I needed to specify 'D1' not 1
Works now
Ivan Grokhotkov
@igrr
@baruch yes, making delay a weak function is totally okay.
geman220
@geman220
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
@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
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
Micro switches are more reliable. Search, you will find this to be common issue. Some people use steppers instead of servos.
geman220
@geman220
okay ty
Ivan Grokhotkov
@igrr
@/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
@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
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
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
@Makuna noted! I will think more about this.
Michael Miller
@Makuna
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
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
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
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
Whit the new licence the arduino API remain in the core ?
So we will have analogRead(); or Serial.print ?
Ivan Grokhotkov
@igrr
@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
@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
if you can relicense the peripheral drivers you've written for the 32, that would be cool.
Me No Dev
@me-no-dev
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
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
do you have any info if anything that we have so far in the esp31b hat will chhange in the final?
Ivan Grokhotkov
@igrr
I have. Yeah, a bunch of things will change. But I can't tell which ones exactly :)
Me No Dev
@me-no-dev
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
Not huge, no. At least not in the peripheral domain.