I mistakenly thought that the SYS folder items VSOS_UART_Shell_Extensions_111.zip project were all that was required to operate, so I deleted the existing SYS folder on the development board and replaced with this project SYS folder. I replaced the original development board SYS folder, THEN copied this project's SYS folder items into the existing SYS folder, now all works as expected. Beginner mistake.

I have had some time to play with the UART Shell Extensions project and have a few comments that may prove helpful. My application for this device may be unique in that it will be under remote control, and I require very little feedback.

1. It would be nice is the (UART) message outputs could be in a more friendly form such that any terminal program (like MTTTY or Terminal) could handle.

2. The machine-controlled silent mode (echo -e) is nice, but still too verbose when playing files. It would be nice to have a "stealth" mode that outputs nothing when play files.

3. It would be nice to be able to persist the echo state on reboot.

4. It would be nice to persist the SD Card as the default directory on reboot.

5. It would be nice to have an option in the directory (dir) command that outputs only the filenames of audio files.

Great feedback. Most of what you suggest could be done by adding commands to CONFIG.TXT if we would do one simple modification to the framework. And that is move the current directory buffer away from shell.ap3 to a different entity that would be loaded before shell.ap3. So we could set up the current directory and appFlags in CONFIG.TXT first, then we could put some commands like "cd d:" etc into the config.txt so that they would autorun.

As for the UART feedback, that's rather easily modified.. you could modify ID3PRINT.DL3 to not output what you don't need. You could suppress output by pointing vo_stdout to nullFile temporarily, stuff like that. Also vo_stderr could point to nullFile to suppress error messages.

1. It would be nice is the (UART) message outputs could be in a more friendly form such that any terminal program (like MTTTY or Terminal) could handle.

What's the problem with those terminals? Can you post a screenshot? Any terminal program should be ok. Could you elaborate what you mean? Do you mean something like adding LF to each CR? That could be done easily in UARTIN.DL3. Or something else?

2. The machine-controlled silent mode (echo -e) is nice, but still too verbose when playing files. It would be nice to have a "stealth" mode that outputs nothing when play files.

Hmm, perhaps. But note that you cannot prevent all surprise messages such as error messages, so your microcontroller code should not choke when it sees something unexpected.

You should write your microcontroller code so that it keeps checking if there are some characters coming from the UART and ignores everything that it does not understand. For example, when the microcontroller sees a tilde (' ~ '), then it knows that it's receiving a uiMesssage, for example the name of the song: "~0503'The Memory of Trees<LF>". After the tilde, it knows that 4 hex characters follow (which specify the uiMessage type), an optional index value, a format character ( ' for strings, = for integers) and then the value of the uiMessage, followed by a line feed. So the microcontroller perhaps can ignore anything that it receives except these uiMessages. Such a parser is generally very easy to write in a microcontroller.

Thank you for the replies. I do believe that it has to do with the CR+LF (when using MTTTY), I will look into this some more. MTTTY is a limited terminal program, and I have had some issues with it in the past.

PUTTY Output:

Putty.png (36.89 KiB) Viewed 3157 times

MTTTY Output:

Mttty.png (48.09 KiB) Viewed 3157 times

Notice that when using the Terminal program the output is as expected.

Regarding the verbosity of the output, I am in agreement with you that the micro-controller can easily be made to parse the existing messages with relative ease, and is most likely the best way to handle. Thanks for your guidance on this.

Also - do you have a guess at when you will have the recording side implemented in the UART Shell Extensions?

I have been working with the first release of the UART shell and have a few inputs/requests for the next release of this - hope you don't mind.

1. It would ne nice to have a separate (volume) command that allows the volume to be set independent of when a wav file is playing. Maybe something like "vol %", 0=minimum and 100=maximum. This would allow the volume to not be too great when the very first wav file is played.

2. I noticed that when a wav file is playing (via the playdir command), the fast forward commands do not work they just rewind to the beginning, and the rewind commands always rewind back to the very beginning.

Seems you already got the UART working. It's using 3 volt signal levels. You can use the VSIDE USB UART cable to communicate, or you can use a MAX3232 level shifter for interfacing with 12-volt RS-232.

1. It would ne nice to have a separate (volume) command that allows the volume to be set independent of when a wav file is playing.

That's true, we're working on it.

2. I noticed that when a wav file is playing (via the playdir command), the fast forward commands do not work they just rewind to the beginning, and the rewind commands always rewind back to the very beginning.

Hmm.. different codecs support different operations, I think the VSDSP Codec object exports those functions which the format supports "natively"... I'm not sure which formats support which operations exactly. What do you need?