SDK 1.0 header mayhem

[nekromant]

@darkbyte-ru @pastcompute @d-a-v People, it looks like with all the SDK version bumps we've been actually NOT updating the SDK headers inside antares (doh!). Since there was some hackery going on there with c_types.h header that defines things like sint32_t etc. It's a miracle we haven't hit any hard to trobleshoot issues so far. I've bumped all the headers with SDK 1.0 version headers, fixed all the warnings I could and added missing definitions. See if you can fix the remaining ones I've missed.

I've also added some convenience hackery that allows you to get firmware size and address of the first flash block that starts after the firmware. See src/flash_end_marker.c

So far everything seems to be working, but please tripple check. I had only time for a quick check.

[darkbyte-ru]

Oh, so may "implicit declaration of function" after updating astares sources. I will fix it soon. Maybe "make clean" must remove antares folder too?

[d-a-v]

On Mar, mar 24, 2015 at 07:21:35 -0700, Andrew wrote:

@darkbyte-ru @pastcompute @d-a-v People, it looks like with all the SDK version bumps we've been actually NOT updating the SDK headers inside antares (doh!). Since there was some hackery going on there with c_types.h header that defines things like sint32_t etc. It's a miracle we haven't hit any hard to trobleshoot issues so far. I've bumped all the headers with SDK 1.0 version headers, fixed all the warnings I could and added missing definitions. See if you can fix the remaining ones I've missed.

I've also added some convenience hackery that allows you to get firmware size and address of the first flash block that starts after the firmware. See src/flash_end_marker.c

Thanks, should we update esp-open-sdk to use v1.0.0 of espressif's SDK too ?

Should we put missing declarations in a specific file that you'd move to antares later (I just saw that atoi, esp_isr_un/mask esp_delay_us are missing) ?

I for example put vsnprintf in console.h some while ago with a comment that it should go to antares, but console.h is not a good place for that.

What about main.h, user_config.h, or a shiny new frankenstein.h for that purpose or anything you advise ?

david (BTW: I tested current/old DHT-11 driver and it's working here

• directly on 3.3v)

[nekromant]

@darkbyte-ru Update antares as well, Most of vital changes have been done to antares tree!

cd antares && git pull

@d-a-v I used esp-open-sdk with a patch for 1.0 SDK. I guess @pfalcon will merge it some time soon. Meanwhile we can build patched esp-open-sdk. I suggest that we just stick to the most recent SDK available and build everything against it.

atoi should be declared in stdlib.h, vsnprintf - stdio.h. There are all there, just include them. They shouldn't break anything. They come with the toolchain. And all the missing ets/esp stuff - let's just extend the espmissingincludes.h in antares tree with them.

Regarding the includes - main.h, user_config.h and the rest are relics of the past experiments. Even I don't remember what hackery is there in some files. I hope I'll find a few hours to give all those things a good look and clean up.

I'll add all the things that are on y TODO list as issues, so that we can keep track on them.

[pastcompute]

@nekromant if you are talking about cleaning things up, in my own fork I was playing with decoupling a few more things, e.g. a log.c to put the global log flag for example. I can propose that as a change if you want. What I am working toward is using frankenstein as a base for specific application(s), so when I built it during development I will have telnet and network commands and ds18b20, etc, but for production use most stuff will be compiled out expect the bare minimum needed to run one specific program at boot. So I was looking at achieving that by adding a means of hooking or even replacing main.c into kcnf somehow. I can post more ideas about that as things develop...

[nekromant]

@pastcompute Antares (on architectures other than esp8266) has a special set of macros called ANTARESINIT* just for that purpose. See this doc https://github.com/nekromant/antares/blob/master/doc/en/startup.txt However, on esp8266 since there's some internal event loop in play, I can only add very limited support to ANTARES_INIT* macros.

[nekromant]

@pastcompute Please also mind that antares is mostly GPLv2, since it reuses some code from linux kernel and other GPL projects. So if something you're working will be proprietary and closed source some of those who will buy he product may ask for the sources.

[pastcompute]

My thing will be GPLv2 so no problem there

[pastcompute]

I am trying to work out how to have my own project with frankenstein a nested dependency like how antares is a nested dependency to frankenstein (turtles all the way down!) So that way I can keep the application stuff specific. I know you added that make rebase but I try and avoid rebasing too much if I can especially when things change a lot

[pastcompute]

Should we add a github LICENSE.md file for GPLv2? Or is it more complicated (I noticed the espressif sdk was GPL3)

[nekromant]

@pastcompute Espressif's SDK is a screwed up GPLv3. Screwed up since we still have to link in blobs. So I guess frankenstein can be GPLv3. Antares itself is made of GPLv2 pieces, GPLv2+obdev exception (for vusb stack for avr), BSD/MIT/permissive pieces (e.g. ST Periph libraries), lwip.
I'm not a huge software licensing guru, but since Espressif's SDK is stated as GPLv3, so GPLv3 would be the rational choice for frankenstein and we can add a LICENSE.md with GPLv3

[nekromant]

Regarding nesting - it's not something I really kept in mind when creating antares. It over complicates the buildsystem a lot. I think the easiest thing to do - clean up most of the stuff that can be called libraries and integrate it into antares. Namely: microrl, environment, i2c are all just asking to be cleaned up and moved into antares tree.

[pastcompute]

Well FWIW it doing the job for me - for my own project I now have a makefile that symlinks $(FRANKENSTEIN)/.config to a config and then patches $(FRANKENSTEIN)/Makefile to include ../my.mk and patches main.c to do what I want, and that gets the job done - and whenever frankenstein gets updated I can choose to update my submodule and get the latest stuff. Makes it nice and easy to push any generic improvements I find back upstream to you as well

[pfalcon]

Regarding licensing mumbo-jumbo: @nekromant, what about splitting off lwip-for-esp8266 into separate project to avoid GPL vs BSD doublethink? Though looking at its changelog in frankestein, e.g. seeing that entire lwip codebase was added with commit message "tftp: Implement firmware update over tftp", I don't really hold my breath, and would probably follow rule "if you want it done well, do it yourself".

[nekromant]

@pfalcon LwIP for esp8266 != upstream LwIP. Their changes are not just plain adding of ICACHE_FLASH_ATTR to each and every function possible that really complicates diffing with upstream (sigh!). Antares itself has lwip inside and even a whole menuconfig with every possible option for it, yet I couldn't find a few spare evenings to get it fully working at that time and properly test on other platforms (e.g. stm32). For frankenstein (Up until I find a moment to properly fix lwip) we're just using lwip that was opensourced by Espressif at some moment with a few dirty hacks. It is yet another ugly placeholder (Guess why it was called frankenstein after all!). And that's the sole reason why Espressif's lwip was NOT moved into antares.

[nekromant]

@pfalcon I try to keep code inside antares itself as clean as possible to allow maximum seamless reuse for other architectures as well, but frankestein was born ugly from the very beginning.

[pfalcon]

Thanks for response.

[nekromant]

Hopefully fixed after cmake switch