MicroPython Forum (Archive)

Sure. @dpgeorge: yes you are right - I forgot about that. But even for a Usb<>uart conversion i believe it's not necessary. The rx uart irq can be used to fill the ringbuffer and the endpoint callback can check the status of the buffer and submit the data. So no timer required there. The other direc...

+1 for an mDNS implementation.

Tim3 might be freed up also for USB (CDC) mode. I was porting some of the USB code to an stml151 device (no MSC just CDC) and so I had time to check the need for that callback that ST proposes for CDC mode. I did not understand why there should be a timer reserved to periodically check the usb buffe...

Just to be clear, I have no problem with 192kb Flash left. I love the Wipy and congratulate Dani for this great achievement. So the reliability issue is a bit off topic. Yet interesting to discuss. @pythoncoder: you always have to erase a bank, the difference is where you store the data while erasin...

you need to copy the contents of the old flash block into RAM, modify it, erase the page in flash and write the updated RAM copy back thats one way to do it but it's dangerous and needs careful considerations with the power supply hw. obviously you'll get corrupted data if power is removed during t...

you can write a wrapper class around UART I'm aware of that and that it can be easily done (fortunately!). My question is if it makes sense to add it to UART (since it's a file-like object). I stumbled upon the deinit_uart and that triggered the idea - not that I would have used it I'm coming from ...

not sure myself. in case of a malfunctioning (shorts, no replies etc) it may be better to close the port (use deinit() automatically if an exception occurs) to release the pins/irqs etc. also it would be somehow consistent for people coming from pyserial. I agree though that for most applications yo...

would it make sense to support the 'with' statement for I/O objects such as UART/SPI/I2C?

Currently throws

Then you'll benefit immediately from all changes made to stmhal by other devs (and you can contribute easily too!). Yes I see that point. @dhylands now has the F7 working with USB serial and MSD and there was not much to it in the end (ie not much code change). libopencm3 is yet to support the F7. ...

On the wiki page http://libopencm3.org/wiki/Licensing they say: While esden and others have indicated that they consider linking with libopencm3 to _not_ require the linked application to become lgpl, the lack of an explicit linking exception bothers a few people. So as far as I understand, that's a...