Any change log of "Firmware Updater" 1.16.4 & 1.16.5 ?
I see a new feature to erase config and nvram.
Does this mean that :
$ pycom-fwtool-cli -p /dev/ttyACM0 erase_all
isn't needed anymore ? (To avoid bugs migrating from firmware v1.18.x)
Re: lopy4 RTC
@Martinnn asked for this a year ago, here is another try :
I have the impression that many people here are struggling with low power deep sleep designs. It would be great if pycom could provide some reference designs for a device that wakes up every xx minutes/hours, sends some data (like from an analog input) via Lora/Sigfox/LTE NB and runs off a battery (like a LiTCL D size https://ch.rs-online.com/web/p/d-batterien/6684550/ ) for a year or two.
Did you end up with a design you're happy with @Martinnn ?
Is access to the DMA exposed in the API? If yes, could you provide an example?
I am specifically wanting to sample at 48KHz on a sweep across 4 ADC inputs for a communication application.
I have done it on the nrf52832 and 40 in C++ in the Arduino environment, and will be willing to beta test if you have a rough library.
@Thosch42 I'm working on this https://github.com/buzzware/pycom-docker-firmware-build
I can't vouch for it being correct or the output being functional or running on Windows, but it does complete the build on my Mac.
@mogplus8 P18 is an input-only pin. You cannot set it to output mode. That applies to P13-P18. See the pin-out sheets.
Edit: I agree that the firmware should raise an exception on the attempt to set output mode on P18.
I believe the documentation is outdated. To circumvent it, you can use a try-except statement like here: (You can also specify the exception in more detail)
counter = pycom.nvs_get('count')
counter = 0
Could the issue be clock stretching?
The SCD30 docs read the following:
Clock stretching period in write- and read-frames is 30ms
However in the source code I read that clock stretching only goes up to 10 ms
Do i understand this correctly?