Please welcome the Stardust V2 - an USB system prop board

[jbkuma]

I might know a guy.

[Obi_1]

I have a very intimate contact to a guy who might be willing to volunteer :)

[Obi_1]

There is a new update to the Stardust v2 User Manual. Due to popular demand  I added a chapter named "Getting Started" so that folks can start using their boards right away after they pull it out from the box.
Please all users, read it and follow the steps (you have been warned :) )

https://github.com/Protonerd/DIYino/blob/master/DIYino_Stardust_v2_User_Manual_v1.pdf

[messiahlad]

High Andras,

I love the Homebrew version so much I was about about to order the stardust V2, but I read one thing that prompted me to ask about it: the 16mb Flash size.

As I have been spoiled by having access to a larger flash storage with the micro SD cards and the wonderful (and generously provided) soundfonts exceed the size of the onboard flash, weighing in at approx 22m, will this mean we need to prune our font choices?

I cant see how more than 3 fonts would fit on 16mb or am I misreading the situation. The size isn't a deal breaker, but in the V3 is there a chance it might get increased past 64mb?

Any way, due its size and given how much I love FX-saberOS, it will be needed for the next saber that I am building as its hilt is a bit smaller.

Thanks for ready and great work on the boards.

[Obi_1]

Yes, you've read it right, the on-board SPI-flash has 16MBytes. On the bright side you can load it via USB, and you do not have mechanical parts, not to mention the additional costs of buying a uSD card.

Technically speaking the limitation to 16MBytes comes from the MP3 chip, it can access an SD-card of any size, but can interface to an SPI-Flash the size of max 16MBytes. It is a very generous size for blaster props. When it comes to lightsabers, with careful hum extension you can still fit in up to 3 sound fonts. Look at the provided free sound fonts:
https://github.com/Protonerd/FX-SaberOS/blob/master/soundfonts/DIYino_Stardust_SPIFlash_image.7z

In my experience loading a lot of sound fonts is a good game, that is why in the original design I opted to place an SD-card on the Prime. As time goes by, most saber smiths settle down to a couple of favorite sound fonts, sometimes exchanging one to try a new release. Therefore I was quite confident that most saber builders will not see it as a limitation and will be glad of the extra space saving.

[Danlim]

How to place order...

[jbkuma]

US promotion: 20 pcs DIYino Stardust v2 - an USB system board

[Obi_1]

How to place order...

As jbkuma said, there is a sell thread, follow the link to see the conditions. There is a special promotion going on until EP VIII. comes out, so hurry up not to miss it.

[JakeSoft]

So, now that I am officially on vacation, I may actually have some time to tinker with my StarDust board! I have been reading the manual and trying to get a good grip on how it works.

Would it work to jumper CHR to D13 so I can programmatically detect when the battery is charged (digitalRead(D13))? The manual suggests jumping CHAR to A0, but the A0 breakout is not in the most convenient spot. My sketch isn't using D13, so that would be easier if it would work.

Also, can someone please verify these mappings?

***Edit: < Incorrect code deleted to avoid confusion >

[jbkuma]

LEDs are 5,6,9

MP3 switch is A3 on the Stardust

I think A1 is hard wired for reading the battery on the Stardust

[JakeSoft]

LEDs are 5,6,9

MP3 switch is A3 on the Stardust

I think A1 is hard wired for reading the battery on the Stardust

Thanks, jbkuma. Does this look better?

Code: [Select]

/**
 * These pins are hard-wired by the Stardust V2 board.
 */
#define SOUND_TX_PIN   7   //Serial TX pin for sound chip
#define SOUND_RX_PIN      8   //Serial RX pin for sound chip
#define BATTERY_PIN      A1   //Battery power level sense pin
#define FTDI_PSWITCH_PIN A2   //Power control for FTDI chip
#define MP3_PSWITCH_PIN  A3   //Power control for MP3 chip
#define MPU_SDA_PIN      A4   //I2C serial data line for MPU6050
#define MPU_SCL_PIN      A5   //I2C serial clock for MPU6050
#define SPK1_PIN         A6   //Speaker feedback input 1
#define SPK2_PIN         A7   //Speaker feedback input 2
#define LED_LS1_PIN       5   //Low-side 1 for LED control
#define LED_LS2_PIN       6   //Low-side 2 for LED control
#define LED_LS3_PIN       9   //Low-side 3 for LED control

/*
 * These pins are user-defined.
 */
#define ACCENT1          11   //Accent LED (could also be another button)
#define BUTTON1_PIN      12   //Input for Button 1
#define CHR_PIN          13   //Input for Battery Re-charge Complete signal


[Obi_1]

Hey Jake, so good to hear from you, Merry Xmas!!! I went down to my workshop where I have a printed out version of the schematics, just to verify: now the list is perfect.

Maybe 2 notes:

A1 is really connected to BAT+, but I'm going to remove it from the next version of the board. Reason is simple: a.) it's of no use, the battery voltage can be measured using another method which does not need any analog input pin b.) battery metering anyway does not work with analog pins, except if a resistor divider is used (and I still did not figure out why...) c.) it can cause back-supply to the uC which I do not like.

The A2 and A3 can stay as they are, but I have some doubts still if it's not the other way around. The power switch chip does not have a unambigous pinout, so I need to make some measurements to make sure.

[JakeSoft]

Hey Jake, so good to hear from you, Merry Xmas!!! I went down to my workshop where I have a printed out version of the schematics, just to verify: now the list is perfect.

Maybe 2 notes:

A1 is really connected to BAT+, but I'm going to remove it from the next version of the board. Reason is simple: a.) it's of no use, the battery voltage can be measured using another method which does not need any analog input pin b.) battery metering anyway does not work with analog pins, except if a resistor divider is used (and I still did not figure out why...) c.) it can cause back-supply to the uC which I do not like.

The A2 and A3 can stay as they are, but I have some doubts still if it's not the other way around. The power switch chip does not have a unambigous pinout, so I need to make some measurements to make sure.

Thanks, Obi_1 and merry Christmas to you too!

This way this project is planned, I'm going to end up wiring this all up and testing it while it's inside an actual saber, doing code updates with the external USB port if I can get it to work. I will wire the external USB in "parallel" mode as described in section 4.5 and shown in Figure 9 (part B). As such, it's going to be important to get it right the first time to avoid tearing down a fully built saber! If all goes well, I'll use it as my test platform for S.T.R.E.A.M. with the goal of getting a public release package ready for beta testing some time in 2018.

About the A2 output and FTDI chip power, I'm basing that by the manual you have posted on GitHub (also in section 4.5). It says that setting A2 HIGH will disable FTDI, setting it LOW will turn on the FTDI chip. I hope that's right, or I'll be burning bootloader with my AVR programmer to recover it from "brick mode"!

[Obi_1]

The two power saving signals are also accessible on the board as PFM and PSF, you can brigde them with a piece of wire to 5V to disable one or both of the 2 modules. They have pull-down resistances, so if they are not actively driven/bridged, they will default to enable both modules.

If you use the parallel method, it works principally, but the two ports fight over the right to communicate with the USB, therefore sometimes if both are enabled the PC might recognize one but not the other (obviously they cannot be used at the same time over the same USB port). In the FX-SaberOS code I included 2 config modes,one for programming which disables the MP3 chipset and the audio amp and one for sound file upload, which disables the FTDI.
But very honestly I have my doubts if the code really disables the right module. So please check, it's for sure A2 and A3, but which controls which I'm not so sure about. I need to test it out still.