Page 4 of 10

Re: Updated SD driver SDSD.DL3

Posted: Mon 2014-11-24 12:58
by Henrik
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

Re: Latest VSOS Kernel (3.19) available here.

Posted: Thu 2014-11-27 19:11
by Panu
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

Re: Latest VSOS Kernel (3.19) available here.

Posted: Tue 2014-12-02 12:24
by penoud
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

Re: Latest VSOS Kernel (3.19) available here.

Posted: Mon 2014-12-08 8:47
by Panu
Hi!
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.
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?

-Panu

PS. After a few days, this branch of the topic will be moved to a new topic.

Re: Latest VSOS Kernel (3.19) available here.

Posted: Mon 2014-12-08 15:45
by penoud
Dear Panu,
Thank you for your answer. I'm looking only for the FSEEK working function.
Best regards

New SD driver for VSOS 3.19.1

Posted: Mon 2014-12-08 15:55
by Henrik
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

Re: Latest VSOS Kernel (3.19.1) available here.

Posted: Thu 2014-12-11 11:01
by Panu
Hi!
Dear Panu,
Thank you for your answer. I'm looking only for the FSEEK working function.
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.

-Panu

Re: Latest VSOS Kernel (3.19) available here.

Posted: Sun 2014-12-14 2:09
by Passionate Jaguar
Hi , Panu,
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:
Unable to play any mp3 files using mp3gui.ap3
and
Controlling MP3 playback: a Model-View-Controller approach
Version 3.12+ SD including Henrik's SimpleMp3Recorder with VU Meter and libraries.
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
Or - I am unconsciously causing this somehow.
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.
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.

Scott

Re: Latest VSOS Kernel (3.19.1) available here.

Posted: Sun 2014-12-14 9:43
by Panu
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

Re: Latest VSOS Kernel (3.19.1) available here.

Posted: Sun 2014-12-14 10:08
by Passionate Jaguar
Panu,

Thanks for your speedy reply, I found part of the problem:
It may be a pointer you're passing to the model doing something unexpected.
Exactly as you said. See update above I was writing as you posted this reply.

Thanks, Scott