Recomended SPI Port for external Display

[Pascal]

Hey everyone,

a week ago an Axoloti came to me by a friend. I did not now about it, but have to admit, that I'm quite amazed.

Since I have some displays laying around, I thought I'm gona write a driver for one, to get started with the firmware.

I tried to using SPI1 on PA4..7 alternate(5), but there is some weird stuff going on on the bus. I assume these PINs are used from somewhere else and keep beeing reconfigured. So I had a look into axoloti-control.c and there SPI3 is used on PB3..5 alternate(6)...

...but for that configuration, MOSI (PB5) is actually boot0, so I would have to patch the board in order to use this port, which I don't want if not absolutely needed. (I guess axoloti core will only be available with a new axoloti-core board revision, but however...)

Is there any recommendation on which SPI should be used for that purpose?

Thanks for any hint!

Regards
Pascal

[johannes]

some weird stuff going on on the bus

My guess, what you're seeing is that they're (re)configured for analog input when starting a patch, in
void adc_configpads(void)

...but for that configuration, MOSI (PB5) is actually boot0

SPI3-MOSI is available on PD6, exposed on header X3. X3 is reserved for the upcoming axoloti-control, and chaining boards. You can use it if you modify firmware, but, err, expect source code merge conflicts in the future...

The reason BOOT0 is wired to PB5, is to be able to use the same switch for user purposes after bootup

[johannes]

I had a look into axoloti-control.c

Some relevant changes are in the "spi_link" branch, if you want to use SPI3 on pinheader X3, but it currently has some merge conflicts with master to be resolved.

[Pascal]

SPI3-MOSI is available on PD6, exposed on header X3. X3 is reserved for the upcoming axoloti-control, and chaining boards. You can use it if you modify firmware, but, err, expect source code merge conflicts in the future...

Ah, stupid me, the bus matrix seems to be more powerful on these STM32 devices, than I expected. I'm totally fine with merge conflicts, as long as git is used

Something else: I have an upcoming project, controlling light over DMX. Since I have this Axoloti to play around now, I thought of using it for that (I know this is not the Idea). So i implemented a dmx out on PA2. Therefore I had to use USARTDriver instead of SERIALDriver, to get DMX's break condition sent properly (keep tx low after last frame for a certain amount of time).

And I have to admit, the GUI is incredibly nice, even to control some DMX devices.

Now the actual question:

I could create a patch series (pull requests) with some proper preprocessor switches for that feature. Is there a desire for such stuff?

Regards
Pascal

[johannes]

Yeah Chibios does not allow to run-time switch between the USART and SERIAL driver unfortunately. I've bumped into this when trying to drive WS2812 led strings. My first solution to drive WS21812, was using the USART to produce the bitstream, but that required the USART driver, the SERIAL driver does not reach the required timing.
The workaround I found, is using SPI, while in master mode that does not allow to set a suitable bitrate, but using SPI in slave mode, injecting clock from a PWM, and the whole data frame can be transmitted in a singe DMA transaction.

"intelligent" LEDs ws2812 driven by Axoloti

Hi, I would like to connect some ws2812 to the axoloti. I think I need to create a new object to get this done. Question is: how do I start? As far as I understand K-rate Code runs at 3000Hz and S-Rate Code runs at 48kHz. Both seems to slow to generate 800kHz for the ws2812? Currently I'm also not entirely sure how the PWM generation of the existing PWM OSCs work. I also don't know what the PWM timers are for.

I believe the same can be done for DMX, but you'll have to shuffle the bits to produce start and stop bits.
Oh, if it just requires keeping TX low for a certain amount of time, and not 100% control over the time-gaps between bytes, this can also be done by changing the pin mode, perhaps another valid alternative. I'm not really familiar with the DMX protocol.

Switching USART vs SERIAL, is that much more involved than changing two lines in mcuconfig.h?

[Pascal]

Yeah Chibios does not allow to run-time switch between the USART and SERIAL driver unfortunately.

Yes. But why not just use USARTDriver instead of SerialDriver? Wouldn't this just mean, that the serial debug code has to be adapted for USARTDriver?

The workaround I found, is using SPI, while in master mode that does not allow to set a suitable bitrate, but using SPI in slave mode, injecting clock from a PWM, and the whole data frame can be transmitted in a singe DMA transaction.

Woohoo, in software I would call this a hack, but if it works

I believe the same can be done for DMX, but you'll have to shuffle the bits to produce start and stop bits.

That's more or less what I do. No bit shuffling involved, obviously. I just move a 513 Byte buffer out, using DMA, triggered by a timer (~40Hz).

Oh, if it just requires keeping TX low for a certain amount of time, and not 100% control over the time-gaps between bytes, this can also be done by changing the pin
mode

That's exactly what I do using USARTDriver. Hmm, actually as I rethink this now, this could have worked with the SerialDriver as well. However I like the USARTDriver more

Switching USART vs SERIAL, is that much more involved than changing two lines in mcuconfig.h?

Exactly.

Which brings me back to the question: Why not just use USART Driver and 'adapt' the serialdebug stuff?

I could create a patch series (pull requests) with some proper preprocessor switches for that feature. Is there a desire for such stuff?

As for this, I guess merging such stuff into master is not what you're after?

[Pascal]

That's more or less what I do. No bit shuffling involved, obviously. I just move a 513 Byte buffer out, using DMA, triggered by a timer (~40Hz).

Ah more questions (since you are so refreshing responsive), I was not sure about the locking here. Do I need to lock that buffer? Since writing a byte into the buffer is atomic anyway, isn't it?

[johannes]

The SERIAL driver allows to use printf-style transmission to a buffered queue, I believe most users will prefer this. While I agree, the USART driver is more suitable to pump out DMX.
My concern with exposing a firmware-compile time switch is that this would fork the universe into two incompatible worlds, hurting the exchange of patches/objects.

I was not sure about the locking here.

I believe if you 'd modify memory while it is subject to a DMA transaction, you'll bump into timing dependencies, but not into cpu faults. If my mental image of DMX is correct - a string of 512 values, than I don't see a strict problem with writing to the DMA memory while the DMA transfer is taking place. If you want to produce a jitter free high-speed stroboscopic lightshow, double buffering may be beneficial

[Pascal]

he SERIAL driver allows to use printf-style transmission to a buffered queue

I see. Well then this is very convinient for sure.

My concern with exposing a firmware-compile time switch is that this would fork the universe into two incompatible worlds, hurting the exchange of patches/objects.

Ok, this makes sense, too. I'll keep my own branch for that and rebase it on master from time to time.

If you want to produce a jitter free high-speed stroboscopic lightshow, double buffering may be beneficial

Argh! Very good point! Why didn't I think of that myself...

Ok, so thank you very much! I guess I'm prepared for some exploring then...

[Blindsmyth]

Hey @Pascal using axoloti to control lights via dmx sounds quite intriguing! Did you come furhter with your attempts and would you mind sharing what you already got?

[Pascal]

Hey Blindsmyth,

Yes I got this working, quite well actually. An artist friend of mine is using it from time to time, but I didn't really push it to a point, so it could be merged (and probably it does not really make sense, anyways). If you are familiar with embedded software development, I can push the branch, but it might need some love and you will have to rebase it most likely.

And you also need some HW for that, since DMX is RS485, which should be isolated, too.

Regards
Pascal

[Blindsmyth]

Hi Pascal,

thanks for your reply! I'm not really a developer or something. I want to start with controling the light of an overhead projector via my axoloti for this performance:

Farbenrausch AV Performance @TEDXGroningen

To be honest we never got into digital creation or manipulation of visuals. I'm more musician and my collegue is a more of a painter/sculptor/artist. He experimented a lot with this floating colours and when I saw it I knew we had to turn into a performance. But this OpenCV shure looks interesting. In the end it doesn't matter what tools you use but what you do with it I guess

So I got the tip that I could use dmx and use a dmx dimmer in order to do so. If you would have had anything ready that would have been perfect. But in that sense I'm maybe better of using the pwm, 12v led and a mosfet. It doesn't have to be the overhead, we only need one strong light.

[Pascal]

So I got the tip that I could use dmx and use a dmx dimmer in order to do so.

To do what exactly?

Anyways, you certainly need some hardware like this:
http://www.mathertel.de/Arduino/DMXShield/DMXShieldSchema.png

...and if you want to experiment with that stuff, I can push the software later. I just noticed, that it's probably only on may old laptop and not on github, yet.

[Blindsmyth]

To do what exactly?

To dim the light an overhead projector, wich should work by just scaling up and down the 230V for the overhead.

I've found this one as a kit:
https://www.ebay.de/i/152758190757?chn=ps&dispItem=1

But on the other hand the overhead is over kill too since we only need a light source under an aquarium, so we could do the same with leds maybe. Only problem I see with leds and pwm ist we film and project the aquarium + light and since pwm means quick on and off this might interact with 24fps of the video cam.

But If you could share your work anyways that would be nice, maybe on of my programmer friends could have look at it. DMX seems like a quite versatile format if I want to control more lights

Anyways, you certainly need some hardware like this:
http://www.mathertel.de/Arduino/DMXShield/DMXShieldSchema.png

Would this shield be compatible with axoloti?

[Pascal]

Would this shield be compatible with axoloti?

Well for minimal DMX you only need 1 TxD from 1 UART and GND. This thing basically just adds an RS485 line driver and opto-couplers. This was actually the first hit on google and there might be better/cheaper boards available out there. But it's actually quite easy and I think you could understand it (which is always best) if you read a bit about DMX and RS485. I think this board was 5V logic. Don't remember, if the axoloti was 5 or 3V3, right now.

[Pascal]

So. Here is the branch. (rebased it on v1.0.12):

pascalhuerst/axoloti

I just had a look again and it is quite hackish, but straight forward. If there is any chance, that this might get merged upstream, I would be happy to invest some more time and make it proper, but I seriously doubt it

I also have an .axo file that show how it might be used, but it's not in the tree. (and I don't see how I can upload files here...)

Anyways good luck with it, let me know if you need any help

[weasel79]

Anybody interested in taking this to the finish line? additional SPI ports would be very helpful for a ton of use cases, and this sounds like it's almost there.