0:00 Hi all and what we are going to do 1:50 Log messages 25:10 Include our Wifi component in the main app and the main CMakeLists.txt 26:00 Add wifi constructor in main.h 26:35 Add call in main.cpp 27:55 Check if wifi.begin is safe to call multiple times 28:30 Compile 28:55 Build flash monitor 37:00 Next video The satisfaction is incredible (even if we just copy and paste code). Your explanations are legendary thanks Simon!
My background is electronic design and started with programming using Arduino. Soon I grow out of that world and found ESP32. Now I have designed a couple of boards using ESP32 that I am using in my home Diy projects. Started in the Arduino world I still dependent of the Arduino-Esp library. I find the Arduino - esp library very badly documented with a legacy that not always good. So.. I find your videos highly educative and really hope you will continue your serial.
Dude you put out the most thorough videos out there on ESP-IDF development. Don't stop, hope you're feeling a bit better, and great job on amazing work! But do maybe focus on speeding through wifi to other tools...
Thanks for the lovely comment! It's a fine line between being thorough and going too fast. I know I'm well on the slow side at the moment but I'm hoping that because we've covered so many programming methodology bits in this wi-fi class, then next bits will go a lot faster. We'll only need to talk about functionality and design choices, not language related stuff. I'll keep your comments in mind and endeavour to improve.
I'm a computer science student and I'm currently working on a course work project which involves some embedded esp programming. Although I had a lot of experience with electronics and different programming languages I never had my hands on C++. And now it seems to me as strange overcomplicated but very interesting world where is no one right way of solving problem. Anyways, I got it running and connected from the first try same as on video, that was kinda pleasing. Thanks a lot for these videos)
Thanks for the comments! C++ is without doubt more complicated than C, because it has more stuff. Stuff that you don't have to use of course, so then the complexity reduces and can actually be lower than C. Completely depends how you use it. The main thing I love about C++ over C is the compile time catching of bugs. It saves so much time, effort and headache when it comes to debugging code running on the micro
Hi Simon, also send you a request in LinkedIn :) So great and happy I found your videos. I'm moving from arduino I to more advanced topics now and wld be happy to stay in contact with you :)
Hi Simon. Great videos. A doubt. There is something I couldn't understand about the code synchronization. What happens if WIFI_EVENT_STA_START occurs after calling wifi::begin() in main()? As READY_TO_CONNECT would not be set yet, would the call to esp_wifi_connect() not occur? Is it necessary, for security, to use a delay between wifi::init() and wifi:begin(), in main(), to guarantee the esp_wifi_connect() call?
Thanks for the comments! How much delay would you add is the question. That said, and it was a long time ago I wrote this so I may be misremembering, I seem to recall WIFI_EVENT_STA_START being triggered inside the call of esp_wifi_start(). So before init() returns. Worst case is that the call to begin() fails and returns an error (albeit not a particularly helpful one, I could've added the state to the debug!) I am not a big fan of delays unless they are necessary for hardware IO, which are typically in the microsecond order. In my opinion, they normally either unnecessarily slow code down and in threaded code cause context switches which can be a pain, or are not quite long enough so you get an intermittent fault where sometimes it works and sometimes it doesn't.
Maybe is it useful i use it myself: target_compile_definitions(${COMPONENT_LIB} PUBLIC "-DLOG_LOCAL_LEVEL=ESP_LOG_VERBOSE") this way the local log level is for all the files the same. Makes it really easy to switch log levels. you need to put in in cmake file. Great Video btw! im really looking forward to implement my own wifi class. but first i have to learn much more :)
Yes this is certainly a way of doing it. Personally, I like the ability to configure things at a module (component) level, rather than globally. I also like like defines etc all being in the source code rather than compiler directives, but of course that is personal preference too.
@@DrGreenGiant yesterday i tried it youre way with making my #defines constexpr static const and it broke my code. You need to be really careful that you dont do any calculations with them because it will mess up youre code and the compiler won't tell you :( Back to #defines again :) The old C way ;)
@@vincentdeman5225 were you compiling for c++17? If it was C++11 then for class members I think they also need declaring in the .CPP file. I can't quite remember off the top of my head. Would be interesting to find out what was causing your issues though. If you want to, make a snippet on Godbolt and drop me a link and I'll take a look. Defines still work just as well, they can get messy though if they're in the header, something to be aware of
@@DrGreenGiant I was able to replicate the problem i have. There are no compiler error's or warnings and i still dont get the right result. The expected result is 0.0 & 0.0 It is a class to interact with a joystick and has a calculation to convert the raw adc value to something in the range of -5 to 5. i hope youtube let me send links :| godbolt.org/z/cKo6o9z4T here is my github repo if the sample code isn't sufficiënt. github.com/vincentdman/S4project thanks for helping!
@@vincentdeman5225 Sorted for you. There were two issues I spotted; VR_Range was 50 in your #define but 5 in the constexpr, and, your constexprs were ints but being assigned a decimal value so would have been rounded down to a whole number. Making them floats and changing the VR_Range to 5 gives the expected result. godbolt.org/z/nnMfr146Y
0:00 Hi all and what we are going to do
1:50 Log messages
25:10 Include our Wifi component in the main app and the main CMakeLists.txt
26:00 Add wifi constructor in main.h
26:35 Add call in main.cpp
27:55 Check if wifi.begin is safe to call multiple times
28:30 Compile
28:55 Build flash monitor
37:00 Next video
The satisfaction is incredible (even if we just copy and paste code).
Your explanations are legendary thanks Simon!
My background is electronic design and started with programming using Arduino. Soon I grow out of that world and found ESP32. Now I have designed a couple of boards using ESP32 that I am using in my home Diy projects. Started in the Arduino world I still dependent of the Arduino-Esp library. I find the Arduino - esp library very badly documented with a legacy that not always good. So.. I find your videos highly educative and really hope you will continue your serial.
Dude you put out the most thorough videos out there on ESP-IDF development. Don't stop, hope you're feeling a bit better, and great job on amazing work! But do maybe focus on speeding through wifi to other tools...
Thanks for the lovely comment! It's a fine line between being thorough and going too fast. I know I'm well on the slow side at the moment but I'm hoping that because we've covered so many programming methodology bits in this wi-fi class, then next bits will go a lot faster. We'll only need to talk about functionality and design choices, not language related stuff.
I'll keep your comments in mind and endeavour to improve.
I'm a computer science student and I'm currently working on a course work project which involves some embedded esp programming. Although I had a lot of experience with electronics and different programming languages I never had my hands on C++. And now it seems to me as strange overcomplicated but very interesting world where is no one right way of solving problem. Anyways, I got it running and connected from the first try same as on video, that was kinda pleasing. Thanks a lot for these videos)
Thanks for the comments! C++ is without doubt more complicated than C, because it has more stuff. Stuff that you don't have to use of course, so then the complexity reduces and can actually be lower than C. Completely depends how you use it.
The main thing I love about C++ over C is the compile time catching of bugs. It saves so much time, effort and headache when it comes to debugging code running on the micro
Hi Simon, also send you a request in LinkedIn :) So great and happy I found your videos. I'm moving from arduino I to more advanced topics now and wld be happy to stay in contact with you :)
Awesome, thank you! I don't really use LinkedIn but I will accept next time I go on :)
Hi Simon. Great videos. A doubt. There is something I couldn't understand about the code synchronization. What happens if WIFI_EVENT_STA_START occurs after calling wifi::begin() in main()? As READY_TO_CONNECT would not be set yet, would the call to esp_wifi_connect() not occur? Is it necessary, for security, to use a delay between wifi::init() and wifi:begin(), in main(), to guarantee the esp_wifi_connect() call?
Thanks for the comments!
How much delay would you add is the question. That said, and it was a long time ago I wrote this so I may be misremembering, I seem to recall WIFI_EVENT_STA_START being triggered inside the call of esp_wifi_start(). So before init() returns.
Worst case is that the call to begin() fails and returns an error (albeit not a particularly helpful one, I could've added the state to the debug!)
I am not a big fan of delays unless they are necessary for hardware IO, which are typically in the microsecond order. In my opinion, they normally either unnecessarily slow code down and in threaded code cause context switches which can be a pain, or are not quite long enough so you get an intermittent fault where sometimes it works and sometimes it doesn't.
Maybe is it useful i use it myself:
target_compile_definitions(${COMPONENT_LIB} PUBLIC "-DLOG_LOCAL_LEVEL=ESP_LOG_VERBOSE")
this way the local log level is for all the files the same. Makes it really easy to switch log levels.
you need to put in in cmake file.
Great Video btw!
im really looking forward to implement my own wifi class.
but first i have to learn much more :)
Yes this is certainly a way of doing it. Personally, I like the ability to configure things at a module (component) level, rather than globally. I also like like defines etc all being in the source code rather than compiler directives, but of course that is personal preference too.
@@DrGreenGiant yesterday i tried it youre way with making my #defines constexpr static const and it broke my code. You need to be really careful that you dont do any calculations with them because it will mess up youre code and the compiler won't tell you :(
Back to #defines again :)
The old C way ;)
@@vincentdeman5225 were you compiling for c++17? If it was C++11 then for class members I think they also need declaring in the .CPP file. I can't quite remember off the top of my head.
Would be interesting to find out what was causing your issues though. If you want to, make a snippet on Godbolt and drop me a link and I'll take a look.
Defines still work just as well, they can get messy though if they're in the header, something to be aware of
@@DrGreenGiant I was able to replicate the problem i have. There are no compiler error's or warnings and i still dont get the right result. The expected result is 0.0 & 0.0
It is a class to interact with a joystick and has a calculation to convert the raw adc value to something in the range of -5 to 5.
i hope youtube let me send links :|
godbolt.org/z/cKo6o9z4T
here is my github repo if the sample code isn't sufficiënt.
github.com/vincentdman/S4project
thanks for helping!
@@vincentdeman5225 Sorted for you. There were two issues I spotted; VR_Range was 50 in your #define but 5 in the constexpr, and, your constexprs were ints but being assigned a decimal value so would have been rounded down to a whole number. Making them floats and changing the VR_Range to 5 gives the expected result.
godbolt.org/z/nnMfr146Y