RGB lightsaber

What are you developing?
racemaniac
Posts: 622
Joined: Sat Nov 07, 2015 9:09 am

Re: RGB lightsaber

Post by racemaniac » Fri Sep 08, 2017 5:53 am

currently both will be a bit underwhelming XD.
the current source code is just setting up everything and doing basic tests (playing some music, using the motion sensor to light the led when the board moves, doing a test pattern on a few leds). This is enough to know it all works, but not much of a program yet.
and the only video i have is thus the board playing the starwars soundtrack :). Nice to know it works, but not much to show yet.

v4 of the boards just shipped, i hope that will be the final revision, i think it's compatible with the v3's, and once they arrive, i'll assemble a few, and start building a real lightsaber and some proper software to drive these boards XD.
and atm this project is more about learning how to make pcb's & how to solder them than it is about lightsabers XD. but the end of that tunnel is finally approaching, and then i can put all my attention again on making it a nice lightsaber XD.

victor_pv
Posts: 1746
Joined: Mon Apr 27, 2015 12:12 pm

Re: RGB lightsaber

Post by victor_pv » Tue Sep 12, 2017 4:49 am

Slightly offtopic, what's the max speed at which you overclocked the i2c interface?
I was just testing and I can go up to 1.3Mhz. Over that either it slows down, or directly stops working.

racemaniac
Posts: 622
Joined: Sat Nov 07, 2015 9:09 am

Re: RGB lightsaber

Post by racemaniac » Tue Sep 12, 2017 6:05 am

victor_pv wrote:
Tue Sep 12, 2017 4:49 am
Slightly offtopic, what's the max speed at which you overclocked the i2c interface?
I was just testing and I can go up to 1.3Mhz. Over that either it slows down, or directly stops working.
i got up to 1.2Mhz, and then it stopped working for me (not sure if the stm32 or the DAC was the issue)

victor_pv
Posts: 1746
Joined: Mon Apr 27, 2015 12:12 pm

Re: RGB lightsaber

Post by victor_pv » Tue Sep 12, 2017 10:27 pm

Similar results with the DAC then. I am using a FRAM that's supposed to work up to 1Mhz in specs, that's mostly why I wanted to test overclocking, then decided not to stop at 1Ghz and keep pushing up.
I suspect the limit is the MCU since we both hit it at around the same speed.

stevestrong
Posts: 1824
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: RGB lightsaber

Post by stevestrong » Wed Sep 13, 2017 7:33 am

At that speed the pull-ups should be less then 1k...

racemaniac
Posts: 622
Joined: Sat Nov 07, 2015 9:09 am

Re: RGB lightsaber

Post by racemaniac » Fri Oct 13, 2017 5:06 pm

After a long wait (~5 weeks? damn you postal services), the next iteration of my lightsaber boards finally arrived :)
looking forward to assembling a few of these, and have a look at how well they work :). I hope these well be my final revision for a while (but as you may have seen in the other thread, i'm now trying to make the next bluepill :) ).

besides the lightsaber boards, the panel also contains 2 small boards which are very minimal stm32f103c8t6 boards (just the stm32, with decoupling caps, a resistor to pull boot0 down, and a button on the pcb, and the pins that i was interested in broken out). It's made so that it can be connected to the main lightsaber boards, and have them communicate via SPI. not sure if i'll need it, but it's not much work to make.
and besides that some small boards for putting decoupling caps on the neopixel power supply cables, and some adapters for ams1117 -> ap2112k. i like the maple mini, but the ams has to go :p. so i made some adapter boards, now i should be able to replace it by an ap2112k, which seems to be much better up to the task :).
pcbv4.jpg
pcbv4.jpg (179.09 KiB) Viewed 178 times

racemaniac
Posts: 622
Joined: Sat Nov 07, 2015 9:09 am

Re: RGB lightsaber

Post by racemaniac » Tue Oct 31, 2017 5:08 pm

found some time to assemble the above boards :)
looking pretty good :). when doing a full test however i had to put an extra capacitor on the 3v3 rail since the sd card managed to pull enough current to restart the stm32 >_<
besides that, everything seems to be working (i still have to test usb, but sd card, sound, motion sensor, ... are all ok).

still really happy with the ability to cut my own stencils using a silhouette portrait cutter :). and the loctite solder paste is great :).
applying the solder past stencils is still a delicate job, but when i carefully do it, and i get a really clean result, it's awesome to see (ans also nice to see even the QFN chips solder nicely without shorts then ) ).

User avatar
zoomx
Posts: 541
Joined: Mon Apr 27, 2015 2:28 pm
Location: Mt.Etna, Italy

Re: RGB lightsaber

Post by zoomx » Mon Nov 06, 2017 2:41 pm

Well done!

racemaniac
Posts: 622
Joined: Sat Nov 07, 2015 9:09 am

Re: RGB lightsaber

Post by racemaniac » Mon Nov 06, 2017 3:01 pm

zoomx wrote:
Mon Nov 06, 2017 2:41 pm
Well done!
thanks :)
now back to improving my software for the board :)
did some test in mixing multiple soundchannels, and it was a bit slow. So now rewriting that part (now working with the i2s in a circular dma loop, and using the xfer half complete & xfer complete interrupts to fill in parts of the buffer, so i can do it in larger (and hopefully more efficient chunks), not sample per sample as i was doing now :).
i was already able to mix 2 48khz channels together, a 3rd channel was too much ^^'.
i'm also considering making a "dev" board of this: a larger version, with all interesting points to measure easily reachable. then when working on it, i can hook up a logic analyzer to the digital signals i want to investigate, hook up a oscilloscope to check the analog parts, etc... :). it's sometimes annoying when working on it that i can't easily measure all those things ^^'. on such a small board, nothing is easily reachable >_<.

racemaniac
Posts: 622
Joined: Sat Nov 07, 2015 9:09 am

Re: RGB lightsaber

Post by racemaniac » Sat Dec 09, 2017 8:43 am

Just gonna vent here a bit XD
Took me Waaaay too long yesterday to get the filestreaming from fat32 completely working (was wise enough to write a proper test so i could find any and all errors, and boy, i found them all XD). Somewhere in the future i want to come back to this as i finally have a good view on what's required to stream multiple audio channels from a sd card and be able to mix them :). (my first attempt was way simpler: under interrupt fetch sample per sample from the buffer and try to mix them, but it's sloooooow....)

For those interested, my current system (let me know if you know of better ways):
Memory arrangement:
Per file i stream, i've got the following buffers:
- FileStart
- Buffer1
- Buffer2
- Buffer1StartRepeated

the reasons for these buffers:
- buffer 1 & 2 are just standard double buffering, nothing special
- the filestart buffer, is for supporting looping the audio. The last buffer i fill can literally contain 1 sample, so if i don't have the start data ready, i'm screwed.
-Buffer1StartRepeated: The only way i can get good performance, is if i can just take a pointer to a block of samples, and can just use them, not having to switch to another buffer midway or so. Since i sometimes get offsets (file header, file not repeating in exact multiples of the blocksize i'm streaming in, ...), i can want the data at the start of buffer 1 to be behind buffer2 so i can just give a pointer near the end of buffer2 and know the start of buffer 1 is also after it in memory.

Currently the above buffers are all 4K in size (this is how much data i request per call to the sd card), except for the repeated part which is as large as the blocks i request from this streaming system(this is half the size of the I2S buffer, currently 256bytes).

How it works:
Upon loading a file, you load the startbuffer & buffer 1 (and technically should fill buffer1start repeat to, but i won't have such short files and i'm being lazy :p ).
The I2S port is in looping dma with half transfer & tranfer complete interrupts on.
On each of the above interrupts, you read a block from the files, and can then know it is contiguous sound data, no catches, so just add the data together according to volume of each channel, and copy it to the I2S buffer.
As you move from one sd card block to the next, as in standard double buffering, the other buffer gets loaded. If buffer 1 gets loaded, after its load it also triggers a memory 2 memory dma to fill in the repeated buffer part.
As the last block of a file is loaded, after its end a part of the startbuffer is copied behind it, so you can loop the file seamlessly (if you don't want to loop the file, and empty buffer could also be copied after it to make sure it only returns 0).
That's the basic operation.

Everything is running on DMA (I2S is in a DMA loop, for SDIO i created a queue of DMA calls so whenever a new chunk if data is needed, the system adds a call to be done to the queue, the memory copies for the repeat of buffer 1 & the copying of start data is a memory2memory dma call (should also make a queue for that)).

besides the above high level stuff, there are also nasty things such as offsets compared to the buffer you develop and have to take into account, which really gave me some frustrations to get it completely running without errors ^^'.

Currently the code is a bit atrocious ^^', but at least it's working XD. It evolved trough a lot of getting stuck at points, noticing what tanks the performance (basically anything you have to do per sample. If i work in blocks of 128 samples, any extra instruction there is just killing the performance. I now went for a solution where i could just take the data, know it's consecutive audio data, and not have to check anything at all, just read the buffer and be done with it XD.)

I can now successfully stream four 16 bit stereo 48khz audio files simultenously without issues :). goal accomplished ^^.

Post Reply