Choosing which chipset to integrate into my design

Designing hardware and software for systems that use the VS1010 MP3 Audio DSP Microcontroller.
Post Reply
treverwagenhals
Senior User
Posts: 20
Joined: Thu 2018-03-01 15:45

Choosing which chipset to integrate into my design

Post by treverwagenhals » Thu 2018-03-01 16:46

Good morning,

### BACKGROUND FOR MY SITUATION. CAN SKIP TO TLDR IF DESIRED ###

I am a senior Computer Engineering student at my college and have to complete a senior Capstone Project to graduate. Our task is to develop a modular mp3 player that has the ability to range from operating as a full featured device down to a simplistic 2 button device, and many steps in between.

My group is picking up this project from a group from last semester. They designed, fabricated, and (somwhat) presented a working solution.

At the heart of their device is an STM32F405 microcontroller. They utilize a platform known as micropython, where the firmware written to the microcontroller (in C) is designed to be able to interpret the python language. To operate, a python script is placed on an SD card and the microcontroller interprets this file.

As far as audio playback, this platform that they leveraged did not include an I2S library withing their C firmware, and so most of their project software wise focused on designing that. Currently, their designed library only supports the capability to read a .wav file and, even more extreme, a single file name is hard coded to get the one file to play. The codec that they chose to use does not support mp3 decoding, and so at this point, the options are to design an mp3 decoder in software, or determine a new chipset to use to overcome this.

There are also multiple hardware issues that they came across during their testing, requiring resistors to be soldered/desoldered, etc. Because of this, a respin of the board is looking inevitable. Since we are already re-spinning the board, it seems logical to look into the integration of some kind of mp3 decoder to alleviate the need to design this feature in software. So, this is where VLSI.FI comes in!

### END BACKGROUND ###

TL;DR - I have to design an mp3 player and don't think the design I am leveraging is the best solution hardware wise, making me consider one of these devices.

I have been looking at various chipsets and have not been able to determine the best solution for me and was looking for some advice.

It appears that one of my options is to get a chipset such as the VS1011B (discontinued), or VS1011E. This device, from my understanding, would act as a co-processor to my already implemented microcontroller, replacing the codec currently on board. I would still use the I2S library to read the music stream in a similar fashion as for the .wav file, then send it this unit to decode the file, which is then passed to my onboard amplifier before reaching the speakers. This would allow me to continue using the firmware that was previously written and make minimal design changes (although I'm not committed to the firmware as it's not fully written and lacking comments). My question here then is what the disadvantages of getting a discontinued chipset is, as my primary concern is keeping the cost very low. I see that for the VS1011E, there is a Tray and Tube product as well, but I do not know what exactly that means for its price to be so much lower. Can that be explained as well?

My other option is to go with one of the SoC products, such as the VS1005. This would alleviate the need for my microcontroller, codec, and amplifier from my understanding. The cost is slightly higher than the previous chipsets, but because it replaces 3 components, it should actually drive cost down. The disadvantage is that a complete redesign of the schematic is required, shifting the work from firmware to hardware. I am completely okay with this, assuming that the firmware provided for this device meets a few criteria: Easily accessible and understandable, easily editable, and the ability to add features to it. I don't want to try to save cost and and implement a cleaner solution hardware wise if it's just going to make the firmware take longer for me.

Currently, the system requirements that our current microcontroller meets that would have to be matched by the SoC if chosen are:

- Ability to be powered via USB
- Ability to read mp3 file off of an SD card and process it via I2S (or some similar protocol)
- At least 19 free GPIO after other feature implementations (16 for buttons, 3 for switches)
- Firmware editing to alter what the buttons do based on the 3 switch positions

So, is there any guidance in the route I should take?

Thanks in advance.

User avatar
Panu
VLSI Staff
Posts: 2523
Joined: Tue 2010-06-22 13:43

Re: Choosing which chipset to integrate into my design

Post by Panu » Mon 2018-03-05 10:44

Hi!

I think you've perfectly grasped the situation. Indeed you have two choices; either replace your codec with VS1011e (MP3, WAV), VS1003 (MP3, WAV, WMA) or VS1053 (AAC, MP3, OGG, WAV, WMA) or VS1063 (all of the above plus MP3 recording), or pursue the SoC path.

The codec path allows you to write firmware for the platform you're familiar with. The SoC requires learning new skills (but offers costdown and smaller and more integrated final product).

If you want to take the SoC path, I'm willing to help you a lot to get you started. For that I recommend that you use VS1010 as it's easier in many ways for simple music players. For the VS1010, if you like, I can write a skeleton source code for your solution, which you can elaborate. If you need more advanced features and more complex software and a fully modular operating system, you can use VS1005. For that, there's a lot of source code already available.

If you want to take the codec path, I don't foresee much problems. The net is full of code for interfacing VS10x3 with microcontrollers.

-Panu

PS. The difference in price comes from the larger minimal order quantity for those options.
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

treverwagenhals
Senior User
Posts: 20
Joined: Thu 2018-03-01 15:45

Re: Choosing which chipset to integrate into my design

Post by treverwagenhals » Mon 2018-03-05 18:56

Hi Panu,

Thanks for the response.

I went ahead and purchased a VS1011E chipset and the VS1005 breakout board to test their functionality a bit more. I also went ahead and purchased a breakout board with the VS1053 from Adafruit to allow me to quickly test each option.

I am not committed to the firmware I was supplied for the design I currently have, and it may be more difficult to expand off of then a different chip's firmware, which is why I decided to purchase a few to test. This is why I bought a codec that can be integrated with my current design, a breakout board that would utilize your firmware source code, and a breakout board for a codec that would utilize a 3rd parties firmware for their microcontroller (Adafruit).

What are the differences between the VS1005 and VS1010? To me it appears that you only sell a development board for the VS1010. Is that why you said the VS1005 would be more modular? Because my final design will have to be on a custom pcb so that in the future my professor may fabricate 100+ at a time to distribute.

I noticed that on the VS1005 development board you sell, there is also an LCD implemented that has a generic mp3 player menu shown. Is there source code for the display implementation that could be referenced? Also, does the display have to be resistive, or is capacitive an option as well (forgive me if the screen technology does not have anything to do with the implementation). If this is the case, then the benefits of having source code for the screen implementation would make this product seem the best fit for our design, even if it requires a completely new schematic design.

So far I'm leaning mostly towards the VS1005, but your response to my new questions and testing when my breakout board arrives will ultimately decide.

User avatar
Panu
VLSI Staff
Posts: 2523
Joined: Tue 2010-06-22 13:43

Re: Choosing which chipset to integrate into my design

Post by Panu » Tue 2018-03-06 16:32

Hi!

Whew, quite a few topics in your post! :) Let's see if we can sort something out..
What are the differences between the VS1005 and VS1010?
VS1010 is cheaper since has only about half the memory of VS1005 and does not have analog audio inputs. Both run VSOS operating system, which is loaded to RAM in the VS1005 and in ROM in the VS1010. With the larger memory, VS1005 supports shared libraries, loadable device drivers and multitasking. It's very configurable. VS1010 on the other hand is limited to a single loadable executable, although an executable can call other executables and return to caller, which can be used to allow more complex programs to run. Both have MP3 decoder in ROM.
To me it appears that you only sell a development board for the VS1010.
We're ramping up VS1010 production, making final adjustments and sell developer boards and chips in limited quantities on a case by case basis until we're in full production mode. VS1005 is in production.
in the future my professor may fabricate 100+ at a time to distribute.
No problem.
I noticed that on the VS1005 development board you sell, there is also an LCD implemented that has a generic mp3 player menu shown. Is there source code for the display implementation that could be referenced?
Here: viewtopic.php?t=1501 Mind you, it's a bit old, hope all the binaries still work with the current kernel. At least it did before our last major overhaul a couple of months ago.
Also, does the display have to be resistive, or is capacitive an option as well (forgive me if the screen technology does not have anything to do with the implementation).
Loadable device driver TOUCH.DL3 returns touch location information to the player. We've only used the one lcd with the resistive touch. To target other touch panels, the TOUCH.DL3 driver needs to be rewritten. All source codes are available in the VSOS libraries source code zip packages or included in the VSIDE.

Please keep in touch when you get the breakout board. We use it less than the developer board so if you end up scratching your head, just ask for help!

-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

treverwagenhals
Senior User
Posts: 20
Joined: Thu 2018-03-01 15:45

Re: Choosing which chipset to integrate into my design

Post by treverwagenhals » Sat 2018-03-10 21:56

Good day,

I have been playing with my breakout board and have gotten audio to play in almost all of the supported file types, which is awesome.

I'm now looking into SPI flash since the internal flash is so small. I was thinking of getting at least a 16Mbit SPI flash since the last released kernel SYS_everything file was about 1.3Mbytes (10.4 Mbits). I figured this would give me room pull everything currently available and have space to expand.

Are there any particular recommendations for SPI flash?

I've looked around the forums and this looked like one that was recommended at one point:
https://www.digikey.com/scripts/DkSearc ... 6870506441

I just want to verify that this one meets the requirements (I saw a 4k erase requirement somewhere within the threads). Also, if there are any other ones that you know of that are supported that may be lower in cost per unit, a recommendation would be appreciated. I'm less concerned with speed than the price point for this specific part (although if it's a few cents/ unit for much better speeds, I will consider it)

Also, right now I am using GPIO0_0 to toggle internal flash at bootup. What pin settings would I need to do to get external flash to come up? In the videos I watched, it's referenced as S1 from the developer board, but I have the breakout board so that doesn't really give me a clue.

I'm also a little confused about the kernel/eeprom/driver/flashing terminology. Clarifying it once would probably do me a lot of good in terms of my own development then. I watched your video where you stated that you were loading the newest kernel to the system. There also seems to be multiple downloads for the newest kernel. The internal and external flash zips contain a bunch of .c files. The root and libraries source code contains the file structure that I've seen on the flash which contains the .dl3 files. So, how are these two sets of files related, if they are? Are the .dl3 driver files what are generated from the .c files once they are built? And then is the kernel the bundle of all of the drivers in one package that is loaded to the flash?

In the same video you also used the prommer/flasher utility. Is this flashing the EEPROM? And is the EEPROM located at the beginning of the internal SPI flash then, or is it separate on the board? How does this programmed EEPROM correspond with the kernel version being used? Does the EEPROM need to be flashed with the corresponding kernel version? I'm assuming that the internal SPI flash EEPROM has been programmed with some version, and I must flash it to use a newer kernel version, or something of that nature. I'm also assuming that when I buy an external SPI flash, I will have to do this because the device does not have any EEPROM configuration specific to the VS1005 and needs this to function? Unless the EEPROM is separate on the board. Please confirm/correct any/all of my statements then.

Also, I can't seem to get my device to be recognized within VSIDE consistently for some reason. I can access my device via Termite with just the UART pins plugged in to play music. If I try to scan for my device on VSIDE though, it doesn't show up. The only way I can get it to show up is if I plug in the mini USB cable with GPIO0_0 pulled high to show the internal flash, and then I connect the UART up after. Even though, as soon as I go to use the prommer tool and click start, it says my USB device malfunctioned and is not recognizable.

Lastly, I purchased the same 2.88" display as the development board and would like to test it out. I'm not sure how the pinout should be done since the development board does not have any schematics to reference.

The pins on my board are:
T_IRQ
T_D0
T_DIN
T_CS
T_CLK
SDO(MISO)
LED
SCK
SDI(MOSI)
D/C
RESET
CS
GND
VCC

Some of these are obvious (MISO, MOSI, LED, DC, RESET, GND, VCC). I'm more asking about the touch pins, and CS.

Thanks.

P.S. sorry if you can see each post I delete. I keep asking questions and figuring out the answers through tinkering. Also, sorry for the wall of text. I figured you its best to have all of my questions together so you can answer them all at once whenever you get the chance.

User avatar
Panu
VLSI Staff
Posts: 2523
Joined: Tue 2010-06-22 13:43

Re: Choosing which chipset to integrate into my design

Post by Panu » Sun 2018-03-11 19:35

Display board schematics:
http://www.vlsi.fi/en/support/evaluatio ... board.html
http://www.vlsi.fi/fileadmin/evaluation ... 11_sch.pdf
The 2.88 inch display is connected with the 8 bit parallel bus and the driver is LCD288.DL3. The 1.44 inch display is connected with SPI bus and the driver is LCD144.DL3.

External and Internal SPI flashes are basically mutually exclusive. If the board can boot from the internal flash, it will. This is for software protection: if you've put software to the internal flash, it's always booted so you can't inject your own code running against the internal software's will, so to say.

To use external SPI flash for system file storage, comment out the #define USE_INTERNAL_FLASH or something like that in the vsos_vs1005g.c file in the VSOS kernel. The kernel can still be in the internal flash, and that's actually quite good idea because it's better protected in there.

You can't detect your device with VSIDE if it's running the command line shell. When you boot it to the USB mode, it's not running the shell, so it's easier to detect. But it's not without problems as you've found out. You can reliably connect with VS3EMU if you run the VS3EMUC program from the command line. Make sure VS3EMUC.DL3 is in the SYS folder. When you run VS3EMUC, it disallows other interrupts except UART RX, which it points to the debug monitor handler in the ROM.

In the VS1005 Developer Board we have a pin to disconnect the SPI flash from the VS1005 so that it cannot boot from the flash and load VSOS - it's then trivial to connect with VS3EMU. But with the internal flash you don't have that option, again because of software protection features.

-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

User avatar
Panu
VLSI Staff
Posts: 2523
Joined: Tue 2010-06-22 13:43

Re: Choosing which chipset to integrate into my design

Post by Panu » Sun 2018-03-11 19:49

I'm also a little confused about the kernel/eeprom/driver/flashing terminology. Clarifying it once would probably do me a lot of good in terms of my own development then. I watched your video where you stated that you were loading the newest kernel to the system. There also seems to be multiple downloads for the newest kernel. The internal and external flash zips contain a bunch of .c files. The root and libraries source code contains the file structure that I've seen on the flash which contains the .dl3 files. So, how are these two sets of files related, if they are? Are the .dl3 driver files what are generated from the .c files once they are built? And then is the kernel the bundle of all of the drivers in one package that is loaded to the flash?
The difference is in how everything is loaded.

The ROM loader inside the VS1005g can only load what's called "boot records" from the beginning of the flash, internal or external. That must contain a statically linked executable - the VSOS kernel. That's built from a Kernel solution with VSIDE; it contains files such as vsos.c, vo_fat.c, devhwspi.c, apploader.c etc. What it contains is not set in stone - basically it contains enough to set up some kind of a file storage and a file system that is capable of reading from that storage. And these must be directly built into the kernel, because without them we can't load anything. So the VSOS kernel contains a FAT filesystem handler, application loader and a driver for an SPI flash. And the other necessary basic essentials of an OS kernel.

When you build the kernel, it makes an eeprom image. This is then prommed into the beginning of the flash, as boot records, and the ROM code can load these when the chip powers up.

So, at boot, the ROM loads the VSOS Kernel. Then the kernel takes over and sets up file storage as a block device in the SPI flash. The kernel contains enough USB code to bring up USB Mass Storage so you can use your PC to format the flash as FAT and copy files into it.

When the kernel starts, it looks for a file CONFIG.TXT in the storage. If one is found, it's parsed and additional drivers and executables are loaded and run from the SYS subfolder, from various .DL3 (VSOS Dynamic Library version 3) files. The DL3 files are each compiled separately from a separate project in VSIDE.

-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

Post Reply