Page 2 of 4

Re: Questions and wish list about Pyboard D

Posted: Sat Feb 09, 2019 9:52 am
by pythoncoder
I'm not in a position to answer this definitively but I suspect it still isn't implemented. Some years ago a user built an I2S skin and attempted an I2S implementation for the Pyboard. Alas he never completed it to the point where the code was reliable. It needs someone with C skills and a good understanding of the DMA mechanism to develop and contribute an I2S module.

Re: Questions and wish list about Pyboard D

Posted: Mon Feb 11, 2019 12:59 am
by Hanilein
The opportunity to switch off peripherals with a port pin is brilliant.

I'd like to have the same opportunity with the processor itself, to achieve a zero-power system.
Here is my idea (which I have not tested yet, but will soon): The processor (F405 on the pyboard 1.x) offers one particular pin (X18), which can be used by the RTC as an alarm output. I was thinking of using this pin to switch the processor, if possible...

Re: Questions and wish list about Pyboard D

Posted: Mon Feb 11, 2019 10:04 am
by pythoncoder
The Pyboard 1.x has great support for micropower modes. I have four which have been working continuously for a couple of years. Three of them are powered by 3 AA cells - these last well over a year. The four boards wake up once an hour and communicate by radio. The fourth board can also be woken by a pushbutton: it displays results on an e-paper display so is also micropower. This repo has a tutorial and code for using this mode.

I should add that I had to provide some electronics to switch off the peripherals and to disable the I2C pullups: hopefully none of this would be needed in a Pyboard D implementation.

I haven't yet tested this on the Pyboard D but I see no reason why it shouldn't work.

Re: Questions and wish list about Pyboard D

Posted: Mon Feb 11, 2019 1:32 pm
by OutoftheBOTS_
pythoncoder wrote:
Sat Feb 09, 2019 9:52 am
I'm not in a position to answer this definitively but I suspect it still isn't implemented. Some years ago a user built an I2S skin and attempted an I2S implementation for the Pyboard. Alas he never completed it to the point where the code was reliable. It needs someone with C skills and a good understanding of the DMA mechanism to develop and contribute an I2S module.
Reading the reference manual for the STM32F405 the SPI peripheral does have an I2S mode i.e the SPI can be uses as I2S but it just has been wrapped up to be callable from python.

Reading the reference manual for the STM32F7 it has a SAI (serial audio interface) that will do a number of different audio protocols including I2S

So on both version of the pyboard the MCU has the hardware capabilities for I2S it is just a case of someone writing the software to utilize it.

Re: Questions and wish list about Pyboard D

Posted: Mon Feb 11, 2019 2:21 pm
by pythoncoder
Yes.

Re: Questions and wish list about Pyboard D

Posted: Mon Feb 11, 2019 10:22 pm
by OutoftheBOTS_
So I have only used I2C, SPI and UART but I would assume software wise I2S implementation would be very similar infact on the STM32F405 it is a type SPI transfer. Without reading the details in the reference manual I would assume it could be as simple as setting the I2S bit in the SPI configuration register then SPI can be used as I2S

Re: Questions and wish list about Pyboard D

Posted: Mon Feb 11, 2019 10:45 pm
by blmorris
I would assume software wise I2S implementation would be very similar infact on the STM32F405 it is a type SPI transfer.
You might assume that... until you realize that I2S is used for streaming audio and is therefore necessarily isochronous, and if you want to listen to your audio track for any significant period of time (say, more than 0.5 seconds) you are going to need a lot more data than fits into the Pyboard RAM. :lol:
So in order to be useful, you need to be able to buffer data into or out of the SD Card (ideally both, to enable both playback and record) while also keeping your I2S buffers filled 48000 (or 44100) times per second. This means interrupts, and DMA, and also a good way to schedule reads and writes to SD as a background task so that you don't have to stay stuck in the ISR waiting for your SD file transfer to complete. And this is where my project broke down, because at the time there was no way to schedule a background task as a soft IRQ and I didn't have the skills to implement it at the time.

The I2S project that pythoncoder referred to is mine (Hi Peter! Miss hanging out here with you guys! :D )
I've since left the audio industry and my new job keeps me almost completely busy with electronics design work, so I have very little free time to think about coding... but I keep telling myself that I want to come back to this project and make it work.

If anyone is interested, check out https://github.com/micropython/micropython/pull/1361 if you are interested in what is involved (or even better, picking it up and running with it! But you might need some hardware to make it work, I might be able to help out with that as well if you ask nicely...)

-Bryan

Re: Questions and wish list about Pyboard D

Posted: Tue Feb 12, 2019 4:36 am
by OutoftheBOTS_
ok then a little more complex than just using current SPI function and altering them to be I2S

For a continuous flow of data like I2S needs then double buffering DMA can be used where it uses 2 different RAM buffers and when it is finished transferring 1 buffer it flags an interrupt then moves to the second buffer then when it is finished then it flags an interupt again before moving back to the first buffer in a circular buffer mode. When the interrupt fires from the DMA finishing a buffer anf moveing to the other buffer that interrupt can be used to up date the buffer.

It would have to be implemented in C as python callback have too high latency for this sort of stuff. So definitely not a super quick bit of code to develop.

From the reference manual
Double buffer modeThis mode is available for all the DMA1 and DMA2 streams.The Double buffer mode is enabled by setting the DBM bit in the DMA_SxCR register.A double-buffer stream works as a regular (single buffer) stream with the difference that it has two memory pointers. When the Double buffer mode is enabled, the Circular mode is automatically enabled (CIRC bit in DMA_SxCR is don’t care) and at each end of transaction, the memory pointers are swapped.In this mode, the DMA controller swaps from one memory target to another at each end of transaction. This allows the software to process one memory area while the second memory area is being filled/used by the DMA transfer. The double-buffer stream can work in both directions (the memory can be either the source or the destination) as described in

Re: Questions and wish list about Pyboard D

Posted: Tue Feb 12, 2019 8:36 am
by pythoncoder
blmorris wrote:
Mon Feb 11, 2019 10:45 pm
...The I2S project that pythoncoder referred to is mine (Hi Peter! Miss hanging out here with you guys! :D )...
Hi Bryan, good to know you're still around. :D

It would be great to see this working - it seemed to me that you were very close.

Cheers, Pete

Unofficial guide to the Pyboard D.

Posted: Sun Feb 17, 2019 11:30 am
by pythoncoder
I've posted this unofficial guide to the Pyboard D. Some of the content is based on my testing, the rest on information from Damien (reproduced with his permission).

Any additions/corrections/PR's/comments from those with boards are welcome.