This seems to be in drv_bl_shared.c . I can easily fix this.
What about this - can we merge your charts changes and Makefile changes first, let's ignore OBK_DISABLE_ALL_DRIVERS and charts on W800/etc for now, and later I will fix OBK_DISABLE_ALL_DRIVERS myself?
I think it's a missing "../src/driver/drv_bl_shared.c", where this is defined.
So I think the correction would be to check for "#if ENABLE_DRIVER_BL09..."?
There seems to be no "upper" define, so we need to check for "ENABLE_DRIVER_BL0937" or "ENABLE_DRIVER_BL0942"??
Added after 2 [minutes]:
You won
p.kaczmarek2 wrote:
can we merge your charts changes and Makefile changes first, let's ignore OBK_DISABLE_ALL_DRIVERS and charts on W800/etc for now, and later I will fix OBK_DISABLE_ALL_DRIVERS myself?
Good idea, can you include only the first commit of PR 1360 ?
As long as OBK_DISABLE_ALL_DRIVERS is enabled, this will mean e.g. a W800 build will include the driver if it's "defined" in obk_config.h, but you won't be able to start it ...
If all was merged, that should be enough so that we could enable charts in obk_config now.
I just tried to download simulator, but it's not found. Hopefully I didn't break anything there?
Added after 6 [minutes]:
Ah, yes, the merges are "only" in the sdks git...
So the submodules should be updated now..
Oh well, it seems you are right that simulator link is dead, but was it ever working? Now when I check it I can clearly see it was not working before in the public releases list? So that may be a separate issue to fix?
I'm not sure, but for release 1.730 I can download the simulator zip file.
And 731 is the one introducing the new "platforms" folder.
Does simulator need to "exclude" some files?!?
I'm not sure, but for release 1.730 I can download the simulator zip file.
And 731 is the one introducing the new "platforms" folder.
Does simulator need to "exclude" some files?!?
I don't think so, but you are indeed right. Maybe it's just a coincidence?
There is something strange at play because I can see that artifacts zip of 1.17.731 still contains obkSimulator_1.17.731.zip, so why would obkSimulator_1.17.731.zip not appear on public releases? Strange.
No, I didn't change anything. Maybe the version number somehow affects the release, wrong wildcards and sometimes zip is not seen correctly? Filename does not match?
Is there a reason for two "*" in path wildcard? But I don't see, why this should be a problem.
And does "can not be read" mean " not found" or maybe " no access" (ownership...)?
Added after 1 [hours] 3 [minutes]:
If I didn't miss something, the sdk updates are still missing to complete the latest changes?
Probably two wildcards means that it's a recursive wildcard, so it matches all directories, but I am not sure. I am not the original creator of this releases code snippet.
It would be very strange if it were an ownership issue, because why then it would first work, then fail, and then again work?
Thank, great. Just trying with a charts build for W800 and LN882H
Added after 56 [minutes]:
ok for LN882H, forgot the discussion about W800 and "ENABLE_DRIVER_BL0937" - next try fixing the for OBK_DISABLE_ALL_DRIVERS
Added after 32 [minutes]:
Found quite some points where the presence of BL09XX was instead "overwritten" by only looking for "OBK_DISABLE_ALL_DRIVERS".
Hopefully I'm finished soon ...
ATM I'm just using "#ifdef ENABLE_DRIVER_BL0937" instead ...
Added after 22 [minutes]:
... hoping for 10th commit now ...
Added after 29 [minutes]:
Yes, finally I did it: W800 is showing charts and I removed "#define OBK_DISABLE_ALL_DRIVERS 1".
So PR#1368 might be a starting point to fix the "misuse" of "OBK_DISABLE_ALL_DRIVERS" instead of checking for energy drivers.
It's not tested with other devices and only tested with BL0937 on one LN882H (and it will definitively fail if only BL0942 is used, for I'm only testing for BL0937).
But it's a start ...
Added after 23 [minutes]:
LN882H with running BL0937 printing the values to charts
Some pin roles requires like two channel fields so I hope this change respects that
Yes, that should work exactly as before:
Therefore the sorted driver selection is still using the original values which are set by the enum in C code. The number of channels is linked to the original list.
BTW: There is one entry I was wondering about: BL0937SEL_n is actually showing 1 channel, while BL0937SEL is configured with 0 channels.
And we could even fix and shorten the text on the page:
Only for button roles another field will be provided to enter channel to toggle when doing double click. It shows up when you change role to button and save.
The last part ("It shows up when you change role to button and save.") is not true any more, number of needed channels now is changing together with the selected role:
Charts should be possible now for every platform with defining it in obk_config (with the known issues on W800 with DISABLE_ALL_DRIVERS defined.
Ring buffer is in testing.
So if you maybe could take a look at PR1368 for some ideas to fix the DISABLE_ALL_DRIVERS issue that would be great.
I can later dedicate some time to testing various combinations (e.g. check if it really compiles on Beken with BL0937 disabled, etc) but that's not a priority.
No, I didn't set them, but these defines are set in obk_config.h for various platforms using energy metering.
The only change to obk_config.h left is commenting out "#define OBK_DISABLE_ALL_DRIVERS 1" for W800.
The change worked as expected for W800:
Drivers are usable now, DS1820 and charts are working.
The change didn't break BL0937, at least for my LN882H smart plug.
Added after 9 [hours] 15 [minutes]:
When waiting for the checks to run on an "online build" I remembered a point seen on local docker builds and maybe there is someone who can decide whether my idea is stupid, impossible or maybe can be implemented:
Every single build will allways download/install the sdks for all platforms and then clear all sdks during a make.
My idea/question is: can a build for a specific platform only install the single sdk needed for this platforms?
There is an option to streamline the build process with what you suggested and also to possibly cache some of the files to speed up the build process as well. But it will entail a lot of changes so that is on a todo list for now. There are also some build actions that are being deprecated soon so I am working on that first and will look into the other stuff soon or "soon" as I am in severe time deficit.
So that the submodule doesn't need updating, could the values for the ota/rf/net start and length be moved into OpenBK7231T_App so a quick easy patch PR in the browser is an option to get a build going with different values?
beken378/func/user_driver/BkDriverFlash.c:46:9: note: #pragma message: DEBUG: The value of START_ADR_OF_BK_PARTITION_OTA: 0x12A000
#pragma message "DEBUG: The value of START_ADR_OF_BK_PARTITION_OTA: " XSTR(START_ADR_OF_BK_PARTITION_OTA)
For the second wish, you need to give input to the build scripts and "forward" it to the chain, or change the build.sh to "import" a file with the values you want.
OpenBK7231N/platforms/bk7231n/bk7231n_os/build.sh
is called from
OpenBK7231N/build_app.sh
which is called by
OpenBK7231N/bXXX.sh (b_full.sh, b_rebuild.sh ...)
I stopped here ...
Added after 2 [hours] 18 [minutes]:
... or you can put a file "key.txt" in /platforms/BK7231N/key.txt and alter build.sh to read it (if that's what you wanted).
No problem.
I must admit I maybe didn't totally understand the question, never having to do changes there.
If you could explain it a bit more, I can find a more intuitive solution.
The main point will probably be the same:
Put the information/values to a place in app repository and change the code in SDK to get the information from this source.
For the first part e.g. I didn't know, if you meant what I tried to code:
In ota.h is the define line with START_ADR_OF_BK_PARTITION_OTA
and I understand you may need to change the value, which needs to be changed in the SDK file BkDriverFlash.c, too?
So I made BkDriverFlash.c to import the header file ota.h and then used the definition from there instead of the value here.
So if you change ota.h at anytime, BkDriverFlash.c will use the changed value w/o any change inside the SDK.
For the key it's a bit more tricky, for the scripts in question are called daisy chained, and you would need to change all scripts if you e.g. want to extend the arguments (though in this case you might also add another function to the BUILD_MODE argument).
I tried another way: if you put a key in the file key.txt in the platforms folder of your device, the build script checks if it's present ( "-e" means if a file exists) and in this case read the content to a variable if it matches the format of a key as I understood it (4 times 8 hex [0- f] and then 5 numbers).
If key is "valid", it's used, if not, it defaults to the value in the script now.
Enjoy your trip!
Added after 10 [minutes]:
Maybe you have an example in a PR to the SDK were I can see the changes you needed?
The discussion focuses on creating a custom driver for OpenBeken (OBK) devices without the need for a toolchain, utilizing online builds. Users share insights on troubleshooting compilation issues, including missing files and incorrect paths. Key points include the importance of proper file organization, the need for specific libraries like OneWire and DS18B20, and the challenges of ensuring accurate timing for sensor readings. Participants also discuss the differences between DS1820 and DS18B20 sensors, emphasizing the need for precise timing in the OneWire protocol. Solutions involve modifying driver code, implementing a pre-build script for SDK management, and optimizing build processes to reduce overhead. The conversation highlights collaborative efforts to improve driver functionality and streamline the development workflow. Summary generated by the language model.