Page 1 of 1

Vmusic2 not working

Posted: 02 February 2009, 21:35 PM
by meenbombs
I have a VMusic2 from Viniculum and thought it would be an easy task to use it with the ZX-328n I have. I used the guide here
http://www.scary-terry.com/vm2/vm2_bs2.htm
to get me started. I updated the VMusic firmware and changed the baud rate to 19200 using Viniculum's firmware modifier. I planned on using Com1 to communicated and have tried every variation of Debug.print to get it to work. I am fairly certain Debug.print works at 19200 and adds the carriage return that the BS code has written in. I am assuming there is some glaring misstep I have taken. Does anybody have experience with the Vmusic or can see anything I am missing? Thanks.

For what it is worth, here is my code.
Sub Main()
delay(7.1)

debug.print "VPF 1.mp3"
End Sub

I borrowed the wiring from Scary Terry's site so as far as I know it should be correct and just in case it wasn't, I did a few variations all with no dice.

Re: Vmusic2 not working

Posted: 02 February 2009, 22:29 PM
by dkinzer
meenbombs wrote:I borrowed the wiring from Scary Terry's site so as far as I know it should be correct
How do you have it connected to the ZX-328n? I suspect that you should be using one of the "software UART" serial channels, Com3 through Com6. Debug.Print outputs to Com1, by the way, which is usually connected to your PC.

In order to use Com3-Com6, you have to configure the Com channel using DefineCom(), open one or two queues using OpenQueue() and then open the serial channel using OpenCom(). Once that is done, you can output to the device by adding data to the output queue associated with the channel. The ZX will output the data in the background and your program can do other things in the mean time.

Here is some example code that performs the sequence described above.

Code: Select all

Const crlf as String = Chr(&H0d) & Chr(&H0a)
Const comPort as Byte = 3
Const rxPin as Byte = 6
Const txPin as Byte = 5
Const qsize as Byte = 40
Dim oq(1 to qsize) as Byte
Dim iq(1 to qsize) as Byte

Sub Main()
  ' prepare the serial channel
  Call OpenQueue(iq, SizeOf(iq))
  Call OpenQueue(oq, SizeOf(oq))
  Call DefineCom(comPort, rxPin, txPin, &H08)
  Call OpenCom(3, 9600, iq, oq)

  Call Delay(7.1)

  Call PutQueueStr(oq, "VPF 1.mp3" & crlf)
End Sub
The code above assumes 9600 baud, 8 bit data, no parity and non-inverted signal levels. You may need to change some of those parameters to get it to work. If you don't need data coming back from the device, you can eliminate the input queue.

Posted: 03 February 2009, 5:47 AM
by meenbombs
I am using Com1 through the ZX-28 development board. I did load the program through Com1 put since have disconnected the computer and connected the Vmusic. Is there any reason a soft com port would work better than Com1?

Posted: 03 February 2009, 6:54 AM
by dkinzer
meenbombs wrote:Is there any reason a soft com port would work better than Com1?
Two that come to mind. Firstly, using Com3-Com6 eliminates the need to connect/disconnect Com1 from the PC. Secondly, the software UARTs can be configured to use either inverted or non-inverted signals as needed.

Com1 is always non-inverted at the AVR chip and inverted at the connection to the PC. Since the Vmusic2 device requires non-inverted signals, you would need to connect it directly to the ZX-328n, i.e. pin 3 of the ZX-328n would be connected directly to pin 4 of the Vmusic2.

Posted: 03 February 2009, 7:17 AM
by meenbombs
Well, I tried the code you provided and no dice. Thanks for the info on the inverted signal. Just for kicks I put pin 4 of the Vmuisic directly on Pin3 on the ZX and did debug printed....still nothing. I am almost thinking the Vmusic may not work. It seems like a pretty simple device to use but I can't seem to figure it out. Any other wild guesses?

Posted: 03 February 2009, 7:36 AM
by dkinzer
meenbombs wrote:I am almost thinking the Vmusic may not work.
If you had previously connected the output of the RS-232 level converter to it (as opposed to the non-inverted AVR output) you may have damaged it.

The output of the RS-232 converter swings from -9 volts to +9 volts. If the Vmusic2 does not have protection against negative voltages or voltages above its supply voltage, it probably fried when such voltages were applied.

The lesson here is to always check and confirm signal levels, polarities and timing before connecting any two devices.

Posted: 03 February 2009, 7:49 AM
by meenbombs
I am using a USB to serial converter so I am thinking the ouputs are limited to 5V so I don't think it was damaged. On a positive note, I tried the com3 route again and noticed the Vmusic2 light flashes after the time delay indicating it is receiving the proper signal. After trying it about one hundred times it started to play one of the files for a few seconds and then stopped. Now it plays one of the files occasionally. I think there is a problem with the VMusic or my mp3 files. Either way, my issue seems to be beyond this forum at this point. Thanks for the help. Once I figure out exactly what was wrong I will update this post.

Posted: 03 February 2009, 9:38 AM
by meenbombs
I am not sure if the problem is the com or the Vmusic. I am using the com3 example from above. If I only send the command to play a file it doesn't work. If I send any other command right after it, it works but only for a few seconds. The second command really doesn't have to be anything. Even sending nothing "" works. However, if I do loop "" it will play the track in its entirety. But then I can't play another file until I power cycle the VMusic. I don't fully understand using Com3 or serial communications in general so I am having a hard time figuring out if the problem is the VMUSIC, the code, or just me.

Posted: 03 February 2009, 10:05 AM
by dkinzer
meenbombs wrote:If I send any other command right after it, it works.
It could be an issue with the "line endings" that the device is expecting vs. what you're sending. In my example code, I added a string to the output queue that ended with CR and LF. If the device is expecting CR only, the LF may confuse it.
meenbombs wrote:I don't fully understand using Com3 or serial communications in general[...]
Perhaps it would be helpful for you to describe what you do understand and the specific parts that you don't understand. That way, we can avoid wasted effort and promote your better understanding of the subject.

Posted: 03 February 2009, 10:32 AM
by meenbombs
Well, I don't understand LF vs CR. How do you break them apart? I had seen CR in the Stamp code and assumed Carriage return. I saw the CRLF in your code and assumed it was the ZX equivilent of CR in Stamp code. I have removed the LF and just left CR in the code but I get an error.

Additionally, I don't really understand the CTS and RTS functions. Why can I just put it to ground as illustrated in the VMusic guide?

What is the difference between using writeline and the putqueue?

Posted: 03 February 2009, 11:55 AM
by dkinzer
meenbombs wrote:Well, I don't understand LF vs CR.
The ASCII codes &H0d and/or &H0a are often used, either individually or in combination, to signify an "end of line" or "end of command", etc.. They are often referred to as CR (Carriage Return) and LF (Line Feed), respectively. Different computer system recognize one or more combinations as a valid EOL indicator. For example, traditional DOS applications recognize only CR followed by LF and they typically get confused or malfunction if only one of these codes appears in their input stream. In contrast, Unix and Linux systems have traditionally recognized LF as the EOL. Older Unix/Linux applications would typically get confused if the CR-LF combination was used but newer applications, especially Linux apps) are tolerant of the CR LF combination being used as the EOL. To add to the confusion, Mac applications (prior to OS X) traditionally recognized CR as the EOL character and would get confused by CR-LF or LF sequences.

When you're sending data to an external device such as the Vmusic2, you have to read its specifications to discover which line endings it recognizes and tolerates. I'm fairly certain that CR in Basic Stamp code is merely a predefined constant equal to 13 (i.e. &H0d). That leads me to believe that the Vmusic2 recognizes CR as an end-of-command character. It may or may not tolerate the presence of an LF following the CR.
meenbombs wrote:How do you break them apart? I had seen CR in the Stamp code and assumed Carriage return. I saw the CRLF in your code and assumed it was the ZX equivilent of CR in Stamp code.
CR and LF are individual character codes just as the codes "A" and "B" are. In the example code that I provided, I defined a string constant called "crlf" that consisted of the character codes for CR and LF. It would have been better, perhaps, to have defined a string constant called eolStr which could then be defined in one of the following ways depending on what is needed.

Code: Select all

' uncomment *one* of the three lines below to choose the appropriate EOL string
Const eolStr as String = Chr(&0d)
'Const eolStr as String = Chr(&H0a)
'Const eolStr as String = Chr(&H0d) & Char(&H0a)
meenbombs wrote:What is the difference between using writeline and the putqueue?
The PutQueue() and PutQueueStr() subroutines simply insert data into a queue. What happens to the data after that depends on how the queue is being used (more on this shortly). The Console.WriteLine() and Debug.Print methods are used to output information exclusively to Com1.

A queue is one of the fundamental data structures used in programming. It is a generalised mechanism providing a data interface between a producer of data and a consumer of that data. The producer deposits data in the queue and then goes about other business. The consumer extracts data from the queue as it needs it. One defining characteristic of a queue is that it is a "first in, first out" (FIFO) mechanism. This means that the consumer gets the data in the order that it was placed in the queue by the producer.

Queues are used for the serial I/O channels in ZBasic because it allows an application to generate output data, place it in the output queue, and then go do other things while the data is being transmitted. In this case, your application is the producer and the serial channel is the consumer of the data. The input queue operates in reverse. When new data arrives on the serial receive line, the serial channel control code places that data in the associated input queue. When your application is ready for data, it checks the input queue and retrieves what it needs.

This is in stark contrast to the Basic Stamp where you must be sitting at a SERIN command when data arrives or you'll never see it. Similarly, when you use SEROUT, your program effectively halts until the the last character to be sent is on its way.

Posted: 03 February 2009, 12:08 PM
by meenbombs
I feel like an idiot for not realizing you were referencing a constant in the CRLF. Once I removed the LF portion everything works now. Additionally, your explanation has cleared a lot of things up. Thank you very much for all the help.