MicroPython Forum

PR = Pull request. So you can get this fixed permanently.

But to solve the problem you just need to add
to the top of mphal.h

uintptr_t comes from stdint.h

I'm not sure why mphal.h doesn't include stdint.h -- it probably should, otherwise unix_mphal.c needs to. Could you send a PR?

You'll need to short the BOOT0 pin to VCC then reset. That will put the board into the ST DFU bootloader so you can use "make BOARD= deploy" via the device usb port.

Otherwise you can use the stlink usb port any time with "make BOArD= deploy-stlink"

hi Christian,

Did you make more progress with https://github.com/micropython/micropyt ... -492205467

This sounds like it would be really useful for the device-initiated case described here?

Upycraft just updates the Python files on the device. The one board I know of where everything is flashed at once (the interpreter and your code) is the micro:bit. You will need to flash the device to upgrade the MicroPython version. You can download the firmware from here: http://micropython.org/do...

-SPI flash - plenty of space, very cheap (£0.50) and very reliable, but it isn't readily supported by the looks of it so would need to do a fair bit of development in an area I don't know much about. I think this is probably your best option, and it should be fairly straightforward to implement thi...

If your modules are already frozen, then your strings have already been QSRT-ified.

Because interrupts run at an unknown point innthe Python VM's cycle, they disable memory allocation (otherwise the GC would have to be reentrant). Unfortunately, the generator needs to do an allocation (I'm unsure if this is related to the floating point calculation or the generator itself). The eas...

Did you have any luck with https://github.com/kfricke/micropython-sht31

It just uses machine.I2C, so it should work on the ESP8266.

See my reply to the other thread, but yes this could very well be caused by increasing the heap size too far.