Component build fails #2
Comments
|
You probably did not miss anything, I believe this driver has been neglected for a while. The DHT-11 is a bit of a flakey sensor, usually something like a BME-180 (280 or BMP-180/280), or SHT-3x are more reliable. There are drivers for these in the atomvm_lib repo. I will try to get this driver updated soon, it had not been updated to work with IDF-v5.x yet, but that should be a small fix. 🤞 |
|
It's the only type of temperature sensor I have lying around at the moment and I thought it would be a good exercise to familiarize myself with building custom components. When you'd be able to fix it great! Or point me in the right direction to make a PR that's fine too. Thanks for your time! |
|
Completely understandable! I would want to try any sensor I had access too. ;-) If you are already familiar with ESP-IDF it is a matter of making the changes necessary to migrate from ESP-IDF v4.x to version 5.x builds. There were changes to the way libraries are linked in version 5. If not, this may not be the best first PR for you attempt for an AtomVM project. I have not looked closely yet to know if there are any differences among supported 5.x versions, that apply to this driver, which need to be handled differently with some ifdef macros, but I suspect not. |
Adds changes necessary to build with ESP-IDF v5.x but still retains compatablility with ESP-IDF 4.x versions. ESP-IDF-v4.x has been EOL for some time now and support for that can be removed in a future PR. Closes atomvm#2 Signed-off-by: Winford <[email protected]>
|
I don't have a DHT-11 handy at the moment to test the functionality, but PR #3 should take care of any build problems. If you don't mind testing it and reporting the results. ;-) |
|
The build itself seems to go fine, but running into some issues further down the line. For reference: Earlier I was able to flash a 0.6.5 release image with these steps Then I created a new mix project, added to the project settings in mix and the actual module then flashed it And I could see from console that I was able to flash sucessful After some failed attempts getting dht lib with a basic code on the target, I went back to try to get the official release back like above. But now whenever I try to flash it I get or I suspect something in my setup has changed but I cannot pinpoint what exactly. What I do notice is that it tries to find the entry point from 0x250000 instead of 0x210000. And related to that did find I understand this is not directly related to the original issue but I'd like to be able to review the changes. Any idea what I might have messed up? :) |
|
Ah, seems the entry point addres had changed (maybe I had a bit older AtomVM image version earlier because of trying different things) my bad, and now when I return :ok from the start function I do get a wonderful error message:
UPDATE: change and then it works. |
|
Ok. I just submitted a PR to update the ExAtomVM README and the AtomVM documentation with the new correct offset to use. It should actually be Also the avm_dep folder is not needed (except for stm32) if you are using a release image. That should get you working as expected. |
|
You will need to reflash the image one more time first... when you flashed the app to 0x210000 some if the boot.amv partition (the area Elixir modules occupy) would have been overwritten with your application... also note that if you are working with rebar3 and the atomvm_rebar_plugin with an Elixir support image it defaults to the Erlang only image default of 0x210000, so be sure to change the offset in rebar.conf or with the --offset parameter, or you would encounter the same problem. |
|
I managed to create a esp32 build with the component based on AtomVM sources on master and creating the specific esp32 build but this seems to look at old address for the application: And needed to set instead of But seems to work: |
|
My apologies, I have been helping resolve a few issues here on GitHub as well as in the AtomVM Telegram chat and I think I got my wires crossed and was thinking you were using an Elixir supported image... they use a different offset to accommodate the extra modules. If you are using the non Elixir images then 0x210000 is the correct offset. Glad to hear you got it working despite my bad advice! 😂 |
|
No apologies needed, you got me on the right track! |
|
If you want to build an elixir supported image you first need a version of elixir (compatible with your OTP version) installed on your system. Then you either need to copy partitions-elixir.cvs to partitions.cvs or just select partitions-elixir.cvs as the custom partition map in menuconfig. And then when using build/mkimage.sh you need to pass the path to the elixir_esp32boot.avm that is created when doing the initial generic_unix/libraries build... like this (from inside the AtomVM/src/platforms/esp32 directory): The advantage is you can use either Erlang or Elixir applications with these images... Our Elixir support has been rapidly catching up with our Erlang support, and is getting a lot of attention lately... not to say Erlang support is slowing down either, we hope to have disterl support in the next 0.7.0 release. But if you are mostly interested in Erlang development you are better off just sticking with the thinner images, as our atomvm_rebar3_plugin defaults to using the Erlang only 0x210000 offset. This way you don't need to remember to change your rebar.config file or pass the parameter every time. |
|
Got the Elixir build to work as well, thanks for your help! Did some more test runs, now reading in a spawned loop: The bad_read should probably a bad_breath :) but it seems to be working fine. |
|
🎉That's great! This reminds me that I need to see if our Elixir build instructions are correct and up to date. Thanks for the feedback! |
Have the AtomVM (0.6.5) repo and IDF (5.4) related dependencies/tools installed on a Mac (using fish shell)
When I. add this repo to components and run menuconfig I see this component checked. But building it give me the following error:
Did I miss anything?
The text was updated successfully, but these errors were encountered: