Latest VSOS Kernel (3.66) available here
Re: Updated SD driver SDSD.DL3
Hello!
There is an important update to one of the drivers in the VSOS 3.19 Libraries Source code package.
Attached to this message is a new version of the SD driver SDSD.DL3. Copy that in your SYS folder on top of your old SD driver. The new driver enhances write compatibility with several SD and MMC cards, for example SanDisk Ultra 8 GB Class 10 microSD cards.
Unfortunately the driver is currently in a state that doesn't allow it to compile on a standard VSIDE installation, so for the time being I have only included the DL3 itself and not its source code.
EDIT: Note that this driver is compatible with VSOS versions 3.19 and older. There is a new driver with source code in the Libraries Source Code package in Panu's next VSOS 3.19.1 message, but that driver requires VSOS 3.19.1 or newer to work!
Kind regards,
- Henrik
There is an important update to one of the drivers in the VSOS 3.19 Libraries Source code package.
Attached to this message is a new version of the SD driver SDSD.DL3. Copy that in your SYS folder on top of your old SD driver. The new driver enhances write compatibility with several SD and MMC cards, for example SanDisk Ultra 8 GB Class 10 microSD cards.
Unfortunately the driver is currently in a state that doesn't allow it to compile on a standard VSIDE installation, so for the time being I have only included the DL3 itself and not its source code.
EDIT: Note that this driver is compatible with VSOS versions 3.19 and older. There is a new driver with source code in the Libraries Source Code package in Panu's next VSOS 3.19.1 message, but that driver requires VSOS 3.19.1 or newer to work!
Kind regards,
- Henrik
- Attachments
-
- SDSD_DL3.zip
- (5.36 KiB) Downloaded 484 times
Good signatures never die. They just fade away.
Re: Latest VSOS Kernel (3.19) available here.
Dear Members,
We've done a lot of progress towards VSOS 3.20, but we're not there yet. First and foremost, the FAT write seeking is not working yet, but we're working hard to get it fixed. We've done a lot of other kinds of progress, however. In fact so much that we're now releasing a maintenance release of VSIDE and libraries source code. This is because internally some functionality has been added to the kernel, which is required by those who develop the new drivers.
Attaching another disk than the SPI flash System Disk (for example Nand Flash, ramdisk or SD card) to USB at boot time (for file upload from a PC) is now handled by pressing [S1] and [S2] together at the developer board. This causes configuration [5] to be loaded from CONFIG.TXT, which should load a new storage driver to S: which replaces the System Disk. This new disk will then be shown in USB.
Also a new SD card driver has been released, which is very important. It fixes a bug which caused broken files at large block boundaries. And there's a speed-improved version of the K9F4G nand driver, which is now fast enough to be usable as a media to play songs from.
We only recommend you to download and install this version if you are having problems with the current version or if someone from VLSI instructs you to install it (because some new driver requires it). Those developing new drivers should install it.
We will make an official 3.20 release when we get the FAT seek bug fixed.
-Panu
We've done a lot of progress towards VSOS 3.20, but we're not there yet. First and foremost, the FAT write seeking is not working yet, but we're working hard to get it fixed. We've done a lot of other kinds of progress, however. In fact so much that we're now releasing a maintenance release of VSIDE and libraries source code. This is because internally some functionality has been added to the kernel, which is required by those who develop the new drivers.
Attaching another disk than the SPI flash System Disk (for example Nand Flash, ramdisk or SD card) to USB at boot time (for file upload from a PC) is now handled by pressing [S1] and [S2] together at the developer board. This causes configuration [5] to be loaded from CONFIG.TXT, which should load a new storage driver to S: which replaces the System Disk. This new disk will then be shown in USB.
Also a new SD card driver has been released, which is very important. It fixes a bug which caused broken files at large block boundaries. And there's a speed-improved version of the K9F4G nand driver, which is now fast enough to be usable as a media to play songs from.
We only recommend you to download and install this version if you are having problems with the current version or if someone from VLSI instructs you to install it (because some new driver requires it). Those developing new drivers should install it.
We will make an official 3.20 release when we get the FAT seek bug fixed.
-Panu
- Attachments
-
- vside_win32_v231.exe
- VSIDE 2.31 (Win32 executable) containing VSOS kernel update 3.19.1 and corresponding system header files.
- (12.32 MiB) Downloaded 550 times
-
- VSOS 3.19.1 Libraries Source Code.zip
- Libraries source code for 3.19.1. Contains VSOS root image and VSIDE solutions.
- (3.15 MiB) Downloaded 538 times
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo
Panu-Kristian Poiksalo
Re: Latest VSOS Kernel (3.19) available here.
Dear Panu,
Could you inform if you have a release date estimation for the VSOS 3.20. We have to deliver our product next year and we want to know if we have to use an another IC for our design.
Best regards.
Sébastien Pernecker
Could you inform if you have a release date estimation for the VSOS 3.20. We have to deliver our product next year and we want to know if we have to use an another IC for our design.
Best regards.
Sébastien Pernecker
Re: Latest VSOS Kernel (3.19) available here.
Hi!
-Panu
PS. After a few days, this branch of the topic will be moved to a new topic.
Regarding the FAT fixes, I think we're just a few days away. But which features of 3.20 are you looking for to make your product more feasible?Could you inform if you have a release date estimation for the VSOS 3.20. We have to deliver our product next year and we want to know if we have to use an another IC for our design.
-Panu
PS. After a few days, this branch of the topic will be moved to a new topic.
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo
Panu-Kristian Poiksalo
Re: Latest VSOS Kernel (3.19) available here.
Dear Panu,
Thank you for your answer. I'm looking only for the FSEEK working function.
Best regards
Thank you for your answer. I'm looking only for the FSEEK working function.
Best regards
New SD driver for VSOS 3.19.1
Hello!
There is a new update to the SD driver for VSOS 3.19.1 or newer. (It will NOT work under VSOS 3.19 or older!)
The new driver is split into three pieces: SDSD.DL3, SDSDR.DL3, and SDSDX.DL3.
SDSD.DL3 offers the same functionality as the old driver, but after startup it will use 42% less instruction space (about 1100 I-words).
SDSDR.DL3 is a read-only version of the driver, and it will use 57% less instruction space (about 800 I-words).
When SDSD.DL3 / SDSDR.DL3 starts, or whenever the SD card has problems or a new SD card is insterted, SDSDX.DL3 is temporarily loaded and called to initialize the card.
For further instructions, read the readme.txt file in the package.
Kind regards,
- Henrik
There is a new update to the SD driver for VSOS 3.19.1 or newer. (It will NOT work under VSOS 3.19 or older!)
The new driver is split into three pieces: SDSD.DL3, SDSDR.DL3, and SDSDX.DL3.
SDSD.DL3 offers the same functionality as the old driver, but after startup it will use 42% less instruction space (about 1100 I-words).
SDSDR.DL3 is a read-only version of the driver, and it will use 57% less instruction space (about 800 I-words).
When SDSD.DL3 / SDSDR.DL3 starts, or whenever the SD card has problems or a new SD card is insterted, SDSDX.DL3 is temporarily loaded and called to initialize the card.
For further instructions, read the readme.txt file in the package.
Kind regards,
- Henrik
- Attachments
-
- SDSD.zip
- SDSD.DL3 and SDSDR.DL3 drivers for VSOS 3.19.1 or newer.
- (50.12 KiB) Downloaded 493 times
Good signatures never die. They just fade away.
Re: Latest VSOS Kernel (3.19.1) available here.
Hi!
-Panu
Some progress. fseek in writable files seems to work now, at least in the current fragment. Also writing a zero length file is now ok and doesn't crash the system.Dear Panu,
Thank you for your answer. I'm looking only for the FSEEK working function.
-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo
Panu-Kristian Poiksalo
-
- Senior User
- Posts: 78
- Joined: Sun 2014-05-04 9:17
Re: Latest VSOS Kernel (3.19) available here.
Hi , Panu,
Thanks. This is a perfect solution for field testing.
Regarding an apparent problem noted in two other different threads but seemingly still connected to the upcoming 3.20 release:
The very first executable in .AP3 file is a string -static char[]- array of 70 button text labels used for dynamic button name/function changes such as switching from Play Line In to Rec Line In. This work great until a decoder or encoder is executed. The music plays but after running either endode or decode StartTask, the first 5 button cap texts gets corrupted with garbage. The application can still run because the button functions are called from a different array of function pointers much later in the code listing. The corrupted strings get changed again each time I call StartTask. Board reset restores char array - obviously.
I did notice strange behavior before, but lacking any hardware diagnostic tools, I found no repeatable evidence to give you until after moving the button string array to the head of the program. It only seems to corrupt the first approximately 40 words (chars) of the array (not yet switched to reading 2 chars per word).
Most significant is that the only readable characters that often show up on button caps are ".AP3" - the rest appear as random pixels, so it seems the corruption is coming from the OS level. The corruption appears completely repeatable (disclaimer at end of this post).
Update: I found the repeatable problem: I did not allocate enough chars to a button text string used for user messages and longer ones from the encoder grabbed more memory than I gave it! Unfortunately, the strange behavior after calling StartTask for the decoder is back as before.
In my earlier post, the StdButtons lockups appear to be caused by the same problem. But there I had file pointer declarations at the beginning of the .AP3 file that were being corrupted and would lock up the Dev Board 1.8 and force a reset. Now it just mislabels the button texts.
Update: Now the decoder locks up the Dev 1.8 board when it finishes playing forcing a reset. Seems there is a conflict between playing Line In and Mic In with reading stdaudioin/writing stdaudioout and switching to a different process for encode/decode.
My code is like Henrik's VU Encoder from October except I use the ESRead function also for Line In/Mic In/FM In through DSP (gain, AGC, VU Meter, etc) to Line Out. This Read-DSP-Write loop is my highest priority as sound to the user should not be interrupted when recording stops. Is there a way of splitting this up:
So SD input is defined by: ioctl(stdaudioin, IOCTL_AUDIO_SELECT_INPUT, (void *)(SD | MP3_DECODE));
And SD output is def by: ioctl(stdaudioout, IOCTL_AUDIO_SELECT_OUTPUT2, (void *)(SD | MP3_ENCODE));
OUTPUT2 would be in parallel with Line Out as in Henrik's example. To stop encode/decode, read/write 0 samples. When samples are read again, encode/decode restarts.
If the encode/decode tasks are one level lower, operating as an SD driver plus "Plug-In", the Read-DSP-Right loop remains continuously operable and can be simply operated with global flags. This works perfectly for me right now with other inputs. This selectable input/output is the reason I selected your product.
Or - I am unconsciously causing this somehow.
Scott
Attaching another disk than the SPI flash System Disk (for example Nand Flash, ramdisk or SD card) to USB at boot time (for file upload from a PC) is now handled by pressing [S1] and [S2] together at the developer board.
Thanks. This is a perfect solution for field testing.
Regarding an apparent problem noted in two other different threads but seemingly still connected to the upcoming 3.20 release:
andUnable to play any mp3 files using mp3gui.ap3
Version 3.12+ SD including Henrik's SimpleMp3Recorder with VU Meter and libraries.Controlling MP3 playback: a Model-View-Controller approach
The very first executable in .AP3 file is a string -static char[]- array of 70 button text labels used for dynamic button name/function changes such as switching from Play Line In to Rec Line In. This work great until a decoder or encoder is executed. The music plays but after running either endode or decode StartTask, the first 5 button cap texts gets corrupted with garbage. The application can still run because the button functions are called from a different array of function pointers much later in the code listing. The corrupted strings get changed again each time I call StartTask. Board reset restores char array - obviously.
I did notice strange behavior before, but lacking any hardware diagnostic tools, I found no repeatable evidence to give you until after moving the button string array to the head of the program. It only seems to corrupt the first approximately 40 words (chars) of the array (not yet switched to reading 2 chars per word).
Most significant is that the only readable characters that often show up on button caps are ".AP3" - the rest appear as random pixels, so it seems the corruption is coming from the OS level. The corruption appears completely repeatable (disclaimer at end of this post).
Update: I found the repeatable problem: I did not allocate enough chars to a button text string used for user messages and longer ones from the encoder grabbed more memory than I gave it! Unfortunately, the strange behavior after calling StartTask for the decoder is back as before.
In my earlier post, the StdButtons lockups appear to be caused by the same problem. But there I had file pointer declarations at the beginning of the .AP3 file that were being corrupted and would lock up the Dev Board 1.8 and force a reset. Now it just mislabels the button texts.
Update: Now the decoder locks up the Dev 1.8 board when it finishes playing forcing a reset. Seems there is a conflict between playing Line In and Mic In with reading stdaudioin/writing stdaudioout and switching to a different process for encode/decode.
My code is like Henrik's VU Encoder from October except I use the ESRead function also for Line In/Mic In/FM In through DSP (gain, AGC, VU Meter, etc) to Line Out. This Read-DSP-Write loop is my highest priority as sound to the user should not be interrupted when recording stops. Is there a way of splitting this up:
So SD input is defined by: ioctl(stdaudioin, IOCTL_AUDIO_SELECT_INPUT, (void *)(SD | MP3_DECODE));
And SD output is def by: ioctl(stdaudioout, IOCTL_AUDIO_SELECT_OUTPUT2, (void *)(SD | MP3_ENCODE));
OUTPUT2 would be in parallel with Line Out as in Henrik's example. To stop encode/decode, read/write 0 samples. When samples are read again, encode/decode restarts.
If the encode/decode tasks are one level lower, operating as an SD driver plus "Plug-In", the Read-DSP-Right loop remains continuously operable and can be simply operated with global flags. This works perfectly for me right now with other inputs. This selectable input/output is the reason I selected your product.
Code: Select all
[0]
lcd288
lcdcon
touch288
stdbtch
#stdbbtn
audio
S:revmenu.ap3
I thought I was alone in suffering this paradox. I am continuing to investigate this myself and any ideas you or your crew may have are greatly appreciated.But it seems that always when I test it with the engineer who wrote that code, it suddenly works and I can't get it to fail and thus it remains unfixed. Maybe it detects that it's in the same room with the engineer.
Scott
Last edited by Passionate Jaguar on Sun 2014-12-14 10:05, edited 1 time in total.
VS1005 Demo Board v1.8, custom designed VS1005 boards, with VSOS 3.55 - VSIDE v2.43
Re: Latest VSOS Kernel (3.19.1) available here.
Hi!
Can you take a back snapshot of all your S:files (and source code) from a point where it's failing the way you describe? If we get a reproducible situation, I'm sure we'll be able to fix it. It may be a pointer you're passing to the model doing something unexpected.
If you send your source code to support@vlsi.fi, we'll treat it as confidential of course. Write "Panu" somewhere in the subject so another support engineer will not grab it.
-Panu
Can you take a back snapshot of all your S:files (and source code) from a point where it's failing the way you describe? If we get a reproducible situation, I'm sure we'll be able to fix it. It may be a pointer you're passing to the model doing something unexpected.
If you send your source code to support@vlsi.fi, we'll treat it as confidential of course. Write "Panu" somewhere in the subject so another support engineer will not grab it.
-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo
Panu-Kristian Poiksalo
-
- Senior User
- Posts: 78
- Joined: Sun 2014-05-04 9:17
Re: Latest VSOS Kernel (3.19.1) available here.
Panu,
Thanks for your speedy reply, I found part of the problem:
Thanks, Scott
Thanks for your speedy reply, I found part of the problem:
Exactly as you said. See update above I was writing as you posted this reply.It may be a pointer you're passing to the model doing something unexpected.
Thanks, Scott
VS1005 Demo Board v1.8, custom designed VS1005 boards, with VSOS 3.55 - VSIDE v2.43