These are chat archives for esp8266/Arduino

1st
Sep 2015
ElimsV
@ElimsV
Sep 01 2015 06:48
@chadouming hi there, i am using client.write(buffer,len) in my sketch and run into some compiling error you have once talked about:
C:\Users\smile\AppData\Roaming\Arduino15\packages\esp8266\hardware\esp8266\1.6.5-947-g39819f0\libraries\ESP8266WiFi\src/WiFiClient.h:113:36: error: request for member 'available' in 'source', which is of non-class type 'unsigned char [128]'
size_t left = source.available();
C:\Users\smile\AppData\Roaming\Arduino15\packages\esp8266\hardware\esp8266\1.6.5-947-g39819f0\libraries\ESP8266WiFi\src/WiFiClient.h:117:5: error: request for member 'read' in 'source', which is of non-class type 'unsigned char [128]'
source.read(buffer.get(), will_send);
cant figure out whats happening, thinking if u guys may help me with that, thanks!
Ivan Grokhotkov
@igrr
Sep 01 2015 07:11
@ElimsV add explicit casts:
client.write((const char*) buf, (size_t) size);
write takes (const char* buf, size_t size), and you are passing it unsigned char* for the first argument.
Michael Miller
@Makuna
Sep 01 2015 07:14
@igrr @tzapu for function call backs, you can also use lambdas, I went this way with NeoPixelBus in my animator branch. A compiler feature rather than some template libraries.
Ivan Grokhotkov
@igrr
Sep 01 2015 07:16
Usually passing an std::bind(&Class::fn, this) and [=](){this->fn();} results in identical generated code
also since ESP8266WebServer takes an std::function<void(void)>, you are using standard library anyway, even if you pass a lambda.
basically the compiler will generate a structure to hold the function call context in both cases.
the only case when you can see some benefit in not using std::bind is when you pass a lambda as a templated argument, then the actual lambda will usually be inlined. however with ESP8266WebServer this is not the case, since it stores it as std::function.
ElimsV
@ElimsV
Sep 01 2015 07:29
@igrr Thanks for the point. However, I need to send the content in buffer to the server. I can't do something like const byte* buffer[128];, can I? At the beginning of my sketch, I declare that byte buffer[128]; , this goes well with Serial.write (buffer,buf_len);.
Ivan Grokhotkov
@igrr
Sep 01 2015 07:31
You can do that, but when you pass that buffer to the client, you need to pass using correct type:
client.write((const char*) buffer, (size_t) buf_len);
just add (const char*) and it will work
ElimsV
@ElimsV
Sep 01 2015 07:33
it really passes the compilation, i'll try with esp8266, thanks a lot!
Ivan Grokhotkov
@igrr
Sep 01 2015 12:33
Screen Shot 2015-09-01 at 15.32.53.png
this was officially the first HTTPS request sent using ESP8266 Arduino framework :)
sending events to https://maker.ifttt.com works like a charm
torntrousers
@torntrousers
Sep 01 2015 12:44
@igrr woot! excited to see that
Harrison Mclean
@h4rm0n1c
Sep 01 2015 12:45
cool.
Neil Kolban
@nkolban
Sep 01 2015 12:46
nice
Juppit
@Juppit
Sep 01 2015 12:56
congratulations
Angus Gratton
@projectgus
Sep 01 2015 13:04
igrr: nice work
is libaxtls.a the same binary as libssl.a from IoT SDK?
Ivan Grokhotkov
@igrr
Sep 01 2015 13:05
no i have rebuilt it myself from axTLS source code, so it lacks espconn_secure* stuff and some other modifications
Angus Gratton
@projectgus
Sep 01 2015 13:06
I noticed the lack of espconn_secure in your client code, was wondering about that
Ivan Grokhotkov
@igrr
Sep 01 2015 13:06
i'm cleaning up my changes, will push to github.com/igrr/axtls-8266 in a few minutes
Angus Gratton
@projectgus
Sep 01 2015 13:06
so you patched it for lwip raw sockets?
I'm impressed, I started doing that back in May but got too annoyed
am keen to see what you did
Ivan Grokhotkov
@igrr
Sep 01 2015 13:07
not really :) i thought about that route, but decided to use the fact that WiFiClient API already provides nice blocking APIs which axTLS expects.
so the changes to axTLS were minimal (i removed a select call in one place)
Angus Gratton
@projectgus
Sep 01 2015 13:08
aha, nice
Ivan Grokhotkov
@igrr
Sep 01 2015 13:09
So basically raw lwip sockets are wrapped with blocking Arduino ClientContext/WiFiClient APIs, which are then used by axTLS
which is then wrapped into WiFiClientSecure API
Angus Gratton
@projectgus
Sep 01 2015 13:09
that's a clever approach
I guess I did the same thing really, only I took the lwip posix sockets layer instead :)
Ivan Grokhotkov
@igrr
Sep 01 2015 13:10
yep, that's right. you have the benefit of an RTOS.
there are some issues left, i.e. i don't know how to implement int available()
but that will be done eventually
Angus Gratton
@projectgus
Sep 01 2015 13:12
have you patched my else? I have some more general patches for the axtls and a lot of TODOs that I want to clean up and try to point upstream at some point
and I'd actually like to try and abstract out the sockets part of axtls also, so it can be switched to use the lwip netconn API (which would probably work with arduino as well)
(having the socket part abstracted would work with arduino i mean, not the netconn api)
oops, s/my else/much else/
Ivan Grokhotkov
@igrr
Sep 01 2015 13:15
not really. i tried to restrict my edits to os_port.c/h so i can upgrade to 1.5.3 easily.
will check out your patches.
perhaps we can make a single version of axTLS which could be built both in RTOS and Arduino versions.
Angus Gratton
@projectgus
Sep 01 2015 13:16
I think that would be great :)
the original axTLS author doesn't seem very active any more, I think esp8266 users are a big chunk of the axTLS user base
but I have a lot more stuff in a not-done form
Ivan Grokhotkov
@igrr
Sep 01 2015 13:17
i think another important point is TLS 1.2 support, but that's obviously a bigger chunk of work
Angus Gratton
@projectgus
Sep 01 2015 13:17
the next TODO I have is to make the configuration more granular, rather than the current options where you select one of a few levels and get a whole bunch of things
and also to try and find a way to do a lot of the cert management stuff with less dynamic allocation
Ivan Grokhotkov
@igrr
Sep 01 2015 13:17
agreed.
on the cert side, i'm going to keep it simple for now, and require the user to provide certificate fingerprint which is to be expected.
i.e. i'm not going to do CA verification
Angus Gratton
@projectgus
Sep 01 2015 13:18
that sounds like a good approach