|
|
Post by J.B. Kuma on May 9, 2018 15:07:34 GMT
|
|
|
|
Post by jcwentzel on May 9, 2018 16:04:43 GMT
I'm currently developing a board using the following setup;
Adafruit Feather M0 Datalogger
MAX98357A
MPU6050
The board is the easy part I guess what I'm really currently working on is a new OS that supports 32bit boards
|
|
|
|
Post by protonerd on Aug 7, 2018 10:25:45 GMT
I'm now close to start working on the SAMD21 based integrated board. I consider this to be a joint, fan made project, where I will act first and foremostly as a hardware designer, but for sure will take my share of porting FX-SaberOS to the new platform as well. I hope you guys (the two Jasons) are in into this collaboration. The basic board setup will be very similar to the MKZero, as it has: - USB charger, like my Stardust and Proto line saber boards, a feature I want to keep, of course up to team decision - integrated SD-card holder, again same type of slot as on the Stardust V3, which opens up vistas for synergies for manufacturing of different board types - a lot of breakout signal To not overcomplicate things for the V1, I will be using the MPU6050 too, it can be connected up to the MKZero without any trouble and the code in FX-SaberOS for the MPU will stay nearly the same. I consider wiring it up with the I2C interface, fully knowing that it can be interacted with over SPI as well, which would be faster. Idea to be explored maybe for a v2. The audio amp will be the MAX98357A, it is such a well documented low hanging fruit. Wiring-wise I need your inputs. I managed to make it play wav files, but I haven't gotten as far down the path as you guys. I foresee 6 PWM controlled output stages to enable all blade types. I know it comes with an area tag, but I frankly do not care. I'm willing to exploit the full size limitation of the board, which is somewhere around 65mmm (size of a 18650) x 22mm. I contemplate swapping one of the small MOSFETs for a big one which could act as a standalone neopixel shut-off stage. Open topic is how to generate 6 independent PWM signals, it is a bit more tricky (or less explored) than for the legacy 8-bit cores. I contemplate as nice-to-have a DC/DC converter, of type TPS61202, like the one used in this breakout: www.sparkfun.com/products/10255It adds to the complexity, but can be used to supply the audio amp with a higher voltage, i.e. louder sound, the amp can work with 3.3V control signals and 5V end stage supply. This DC/DC has a few nice functions, like a short circuit protection, undervolate shut down to protect the battery from deep discharge, low quiescent draw in power saving mode etc. |
|
|
|
Post by J.B. Kuma on Aug 7, 2018 14:23:01 GMT
I wonder if pushing the amp will be worth the effort. It's hard to find even 3w speakers to fit inside the saber. On a project not related to sabers I used a wifi chip to control a DF player connected to a 32mm speaker. It sounded decent, but once I closed up the project it wasn't quite as loud as I wanted. I changed to a 50mm speaker and didn't change anything else, and the different in the quality and volume were significant. Both are 3w 4ohm speakers. The size rather than the power of the amp seemed to be the differentiator. We may already be at the limit of what we can expect from a speaker of this size.
For the amp, while Mr Wentzel and I have both had great success with the I2S amp in running the sound with smooth loops and gapless playback, clear, loud sound, etc, as soon as pixel code is introduced we run into issues. The interference comes when the program attempts to update the pixels. It doesn't matter if it's 1 or 120, and it doesn't matter if they are connected. I've tried the adafruit library and FastLED and ws2812light. The problem seems to be with pausing interrupts in order to maintain proper timing in the pixel signalling. There may be tweaks we can make or other libraries to try, but in the time I've been able to put into it I haven't had any luck. There are DMA libraries for pixels, but they are not compatible with the I2S libraries and claim all 8 pins that can be controlled this way. I haven't had time to learn enough about it to know if tweaks can be made to get it working together.
I don't think we'll have to worry about the MPU6050 any time soon, it's so commonly used that we should have plenty of availability for the foreseeable future.
I would like to build in a voltage divider for the battery as well. The reason I've selected 470k and 120k is that it gives a value under 1.1v which was required to use the internal reference rather than input voltage, and the high value keeps consumption to 7ua. 1M and 220k would cut this to about 3ua, but if I recall correctly this would start giving more dubious results.
I won't ever use the charger if it's under 1A, but I understand that it can be useful.
|
|
|
|
Post by protonerd on Aug 8, 2018 9:43:30 GMT
I think your assessment of the potential root cause for the pixel noise is correct. And now I'm pretty much sure that it was the same reason which forced Plecter Labs to invent what they call the 0-CPU load neopixel library. It is an educated quess from me that they use a timer module - like those used to generate a PWM - overcome this problem. Probably a timer module can generate the right sequenc of signals without needing to disable all interrupts and can do it even without the CPU if the CPU defines an array with the values the stripe has to be updated with.
I think we will find a solution for this. Alternatively we can also creative borrow ideas from the Teensysaber, as it also uses the same I2S amp and so far no one complained about the noise. It uses a Cortex M4, but I guess the similarities in CPU architecture are such that solutions can be ported.
As mentioned, the DC/DC is a nice to have. I'm open to suggestions guys. Charger-wise, I need to see if the current can be pushed up to 1A, but I doubt. Goal should be 500mA at least. I'm a bit reluctant to push it to extremes, as going higher needs a very careful layouting else the charger will overheat, what happened with the Stardust v1 (hence it never went into "mass production").
MPU6050 can stay, I also do not think they will discontinue it from one day to the next, but it is damn expensive! It costs over $5 , unless you order a lot, but even then you cannot push it below $4.5, it is alone more expensive than the PCB...
|
|
|
|
Post by J.B. Kuma on Aug 8, 2018 19:38:32 GMT
I think we can borrow from Teensy to some extent. I have opened up the code, but there is quite a lot to look through and I haven't had time to get much further. Much of the Cortex code should be portable according to the data sheets. I have an STM32 board as well, when I get a moment I will try setting up a basic I2S + pixel sketch with the basic libraries and see what happens.
|
|
|
|
Post by protonerd on Aug 9, 2018 12:32:42 GMT
Just an idea occured to me: what if you remove the disabling of interrupts from the pixel library? Will the interrupts from the sound generation disturb the pixel updates to an extent that chaotic, unpredictible pixel colors will be the result? It is worth a try!
Another thing I will experiment with on the 8-bit platform is how much we can replace a constant stream of programming to the pixels when imitating blade flickering with a simply adjustments of the supply voltage by altering the PWM on the kill-key transistors. I have no clue what is going to happen, there are a lot of ifs, but if it works, system performance will increase a lot. Nevertheless for the 32-bit platform an idea is needed which does not rely on loading the CPU with the actal slow programming of the pixels.
|
|
|
|
Post by J.B. Kuma on Aug 9, 2018 14:43:12 GMT
The pixel libraries all disable the interrupts to guarantee signal integrity. I'm sure modifications can be done to it, but I haven't had time to look very closely and I have been looking at alternative approaches. The DMA style libraries pack the information and release it as timing becomes available (as I understand it) but none of the one's I've tried are compatible. Some libraries rely on SPI, but I don't know if that is any better or worse and haven't gotten to them yet. There is a library for ESP32 that uses RMT, which I know basically nothing about (even less than the other things I know basically nothing about).
|
|
|
|
Post by J.B. Kuma on Aug 10, 2018 3:10:16 GMT
It looks like we should be able to use Adafruit Zero I2S with Adafruit_NeoPixel_ZeroDMA, but I can't get even the basic example sketch on the Zero I2S library to compile on it's own. There are a lot of "member does not exist errors" but there is are no issues reported on the git right now. I'll post the issue and hopefully try compiling a sketch that at least includes both an I2S audio and pixel libraries that are compatible.
|
|
|
|
Post by jcwentzel on Aug 11, 2018 17:53:36 GMT
I had some semblance of success with Adafruit_NeoPixel_ZeroDMA and ArduinoSound libs but I had to hack them. If I recall I managed to get it all to compile but had some issues getting sound to even play. I didn't get too far with it though as I got swamped with some other projects.
|
|
