MicroPython Forum

That's strange. With the 11db setting, you could try to connect the ADC input to GND and 3.3V. Then you should read 0 and 4095 as adc.read() value. That's what I tried here.

Both is possible with machine.freq().
machine.freq() returns the actual setting
machine.freq(HZ-value) sets the new frequency. The suitable range is 12 - 270 MHz, but not all values in that range will be accepted.

Generally the ESP32 supports flash encryption, and the Pycom variant has a build option for it. Only that Pycom supports only it's own hardware. Modified their scripts supporting generic ESP32 too. Using that required you to build your own images. And the Pycom MP version lags behind the the genuine...

There is a problem with Pico, dual thread mode and memory management. The code may either stop or behave otherwise weird. Nothing related to the actual code itself. At the moment, the only choice you have is to use single thread only or to rewrite the program to allocate all memory at the beginning ...

The best results that you can achieve is using machine.time_pulse_us(). See https://docs.micropython.org/en/latest/ ... e_pulse_us.

So I made some further tests: Using the previous version for machine.uart does not change the picture a lot. The crashes and lock-ups occur too. Only I have not seen the character doubling. So the latter seems just one variant of misbehavior caused by the underlying bug in threading. Nevertheless I ...

Esptool just copies data to the flash memory and does not care about the type of the data.

You can try to use a single thread only with sufficiently large transfer buffers. If that does not fit, I could make a firmware version with the previous version of uart.write().

It seems to depend on the code size as well. With a minimal code I see no error. If I just add some non-executed code lines, I get errors. So there seems to be something fundamentally wrong with threading and interrupts.

When enabling threading I see all kinds of errors, very rarely character doubling, more often just lock-up of the sending thread, or sending completely wrong data. So there seems to be a general issue or challenge with threads and interrupt. Maybe a stack overrun. It does not matter in which thread ...