One: I need to speed up the VMusic2. It can't keep the buffers full. I have to slow the Shift_Reg object down at the moment. I have tried different ways of increasing the baud rate, but am doing it wrong. I have been over the firmware but can't figure out what I need to do. It talks about keeping a pin high while sending the command, but so far I have not been able to do it right.
Two: Something must be slightly off in my code, because I have one byte missed every now and then. I just notice a light or two not turning on when they should every now and then. I'm sure its something simple but I'm going to rest my brain for a few and get back to it this evening.
I still can't find the answer to setting the baud rate for the VMusic2.
I'm going to test some more code this evening and see if I stumble across something that works.
Vadoo, there are two different ways of setting your baud rate. In my opinion the best way is to reconfigure the firmware of your device to change its default baud rate. The firmware configuration utility is available at this link http://www.ftdichip.com/Firmware/VNC1Ltools.htm .
Read the manual carefully as there is a possibility of rendering your device useless if you misuse the utility.
The other option is to use the VDAP instruction SBD , you have to remember that all commands after issuing that instruction will be at the new baud. The instruction is comparitively slow so time must be allowed for the change in baud to take effect (remember the "wait for prompt")
The other option is to use the VDAP instruction SBD
This is what Ive been trying to get to work. But the best I can get is a bad command response
I guess I can change the firmware, but I would rather have control over the baud through programming. Any idea what I'm doing wrong? Is there another step besides sending the SBD command?
Beyond this point you will need to use a serial object with a baud of 115200 to talk to the VMusic or restart your existing serial object with the new baud.
Show how you are trying now, maybe we could see an error.
Beyond this point you will need to use a serial object with a baud of 115200 to talk to the VMusic or restart your existing serial object with the new baud.
Show how you are trying now, maybe we could see an error.
Jeff T.
I ended up getting this to work:
VMusic2.str(string("SBD $4EC000",$0D))
Setting the baud to 38400.
I also tried to set it to 115200, but it stopped working...?
I have worked out all but one little bug. Can someone look over my code and see what is going on?
I have two 512 byte buffers. At any time one will be read while the other is filled. The data being read makes output 1 of a 32 bit shift register turn on for a moment, then output 2 and so on till it hits 32, then goes from 32 back to 1 again.
The bug i can't find, is when the buffer is finished, as the next buffer is started, the led that was instructed to come on at the beginning of the previous buffer, comes on for one cycle (the first 32 bytes read of the new buffer) then goes back out.
I have been all over my code and I just can't explain this!
Please help!!
how often do you have to make the exerience again if you do it really fast things turn out to be really slow.
The code you attached does not use shift_reg at all. I guess you archived the wrong file. You can't expect from me that I will solve problems caused by you because of shooting too quick from the hip.
I'm willing to help but only if you are careful about attaching the right code a detailed description of what you expect the code to do and a detailed description of what the code does instead
and inside the code comments on where you guess the bug might be.
speed things up through carefully analysing and describing
best regards
Stefan
P.S. We are on posting 102 after four weeks of time. I estimate the whole thing would be running after just one week and 10 postings if you would use a working-style of collecting information
reading datasheet and manuals carefully, using small testprograms changing only one thing at a time etc.
how often do you have to make the exerience again if you do it really fast things turn out to be really slow.
The code you attached does not use shift_reg at all. I guess you archived the wrong file. You can't expect from me that I will solve problems caused by you because of shooting too quick from the hip.
I'm willing to help but only if you are careful about attaching the right code a detailed description of what you expect the code to do and a detailed description of what the code does instead
and inside the code comments on where you guess the bug might be.
speed things up through carefully analysing and describing
best regards
Stefan
P.S. We are on posting 102 after four weeks of time. I estimate the whole thing would be running after just one week and 10 postings if you would use a working-style of collecting information
reading datasheet and manuals carefully, using small testprograms changing only one thing at a time etc.
StefanL38,
Please take a second look at the archive. It is correct. And It does use Shift_Reg.
I appreciate your input as well as your constructive criticism. Though please don't confuse this thread as random aimlessness. Each question has a specific purpose and usefulness, and the excellent support I have received has been extremely helpful. I have dozens of objects dedicated to each little piece of this project, testing different ways of doing each thing this program does so far. Dedicated not only to making this work, but making sure I understand HOW and WHY it works, so next time I undertake such a project, I can be much more self reliant.
I look forward to any help you may be willing to offer on the final steps of making my project functional, and helping me continue my learning an interest in the Prop chip, and its many capabilities.
I would be more then happy to answer any questions you have on my code, to bring you up to speed on where it is at at this point, as I know its been a lengthy thread.
you are right it does use shift_reg. I apologise for beeing upset. From what you have described above you really do your homework. Again I apologise.
One idea is you could add counter-variables and debug-output to check how the loops are repeated. I mean inside the shift-method.
Or to add a single-step mechanism through the parallax serial terminal which also can send bytes to the propeller and then stepping through and sending each interesting variable
to PST.EXE
you are right it does use shift_reg. I apologise for beeing upset. From what you have described above you really do your homework. Again I apologise.
One idea is you could add counter-variables and debug-output to check how the loops are repeated. I mean inside the shift-method.
Or to add a single-step mechanism through the parallax serial terminal which also can send bytes to the propeller and then stepping through and sending each interesting variable
to PST.EXE
best regards
Stefan
I played with adding debug (using pst.exe) early on, but it wasn't working. How can I properly use the debug object from a child object? It seemed it had to work differently then how I use it in the main.
This is why you see so many debug led's throughout my code. That helped a lot to find where my program was getting jammed up, but doesn't help with seeing the actual data on the child object (shift_reg) side of things...
there is another serial object called serial mirror which uses buffervariables in a DAT-section.
Variables defined in the dat-section of the code are global.
Another problem from using serial-debug in other cogs is that the data can get mixed up if two cogs access the buffers at the same time.
One way to working around this is to use a buffer for what should be sended. This means different cogs do NOT call methods of FullDuplexSerial directly
but write into a special buffer where each variable has a specified index in the buffer. Then one single cog is checking the buffer for content-changes.
Whenever a change this cog sends always the complete buffer. This will avoid mixing up serial data.
Stefan your awesome!
I have successfully integrated the SerialMirror.spin into my program. I have so much more debugging capabilities now!
I can now see a readout of the problem. And according to what its showing me, the shiftregister is responding correctly to the data it is receiving. The data is wrong!
Ok here is whats happening. When debug is active in the main object, it is reading all 512 bytes of each buffer directly after it is stored. Everything looks great there. But when the debug is active in the Shift_Reg object, and reads out each byte just before it is shifted out to the shift reg, the data is different at the first 32 bytes. Rather the the first 32 bytes looking as the should, they look exatly like the first 32 bytes of the previously read buffer (the one that is then being filled).
What does this mean!!!!???? I can't find the darn problem!
It has to be a problem in the Shift_Reg object...?
One text doc shows what debug sees in the buffers while running in main object.
The other text doc shows what debug sees in the buffers while running in the Shift_Reg object.
In the shift object you indicate to the main object that the buffer should be filled. Then you wait for it to be ready. Only then do you transfer the data to the registers (so far so good). Once the first buffer is output you ask the main object for more data but immediately process the buffer without waiting for it to be ready.
As this is a double buffer approach you should make sure you have one buffer ready. Then ask for the second buffer before processing the first one. When you're finished with the current buffer idle until the next buffer is ready (the one being filled while you were outputting yours). Ask for the next buffer and continue with processing the current buffer.
I forgot to prefill the second buffer!
*sigh*
I thought I did....
Thank you, it works perfect now!
Though I do need to fix how it handles the end of a file now.
But then it's done!
cool ! Makes me happy that I could help.
IMHO it is an example for:
if you don't understand a problem reading the code start analysing the whole process.
Therefore it's nescessary to get all interesting values and "redo" in your head what the code is doing to comprehend what is going on.
In my experience I had success in most cases if I work this way.
Looking at the values through the debug-output guided you in the right direction - and helped kuroneko too - to find the bug
yeah I like this forum so much
keep the questions coming
best regards
Comments
As usual, Kuroneko is right.
Since "Buffer" is 1024 bytes long the address of "ready" is going to be greater than 1024. A byte only goes up to 255.
Addresses are general if not always stored in a variable at least a word in size.
Remember, the value stored in the variable may well be less than 255 but the location is very likely to be greater than 255.
Duane
It works but has two problems.
One: I need to speed up the VMusic2. It can't keep the buffers full. I have to slow the Shift_Reg object down at the moment. I have tried different ways of increasing the baud rate, but am doing it wrong. I have been over the firmware but can't figure out what I need to do. It talks about keeping a pin high while sending the command, but so far I have not been able to do it right.
Two: Something must be slightly off in my code, because I have one byte missed every now and then. I just notice a light or two not turning on when they should every now and then. I'm sure its something simple but I'm going to rest my brain for a few and get back to it this evening.
I'm going to test some more code this evening and see if I stumble across something that works.
Read the manual carefully as there is a possibility of rendering your device useless if you misuse the utility.
The other option is to use the VDAP instruction SBD , you have to remember that all commands after issuing that instruction will be at the new baud. The instruction is comparitively slow so time must be allowed for the change in baud to take effect (remember the "wait for prompt")
Jeff T.
I guess I can change the firmware, but I would rather have control over the baud through programming. Any idea what I'm doing wrong? Is there another step besides sending the SBD command?
Vmusic2.tx("S")
Vmusic2.tx("B")
Vmusic2.tx("D")
Vmusic2.tx("$20")
Vmusic2.tx("$1A")
Vmusic2.tx("$0")
Vmusic2.tx("$0")
Vmusic2.tx("$0D")
Beyond this point you will need to use a serial object with a baud of 115200 to talk to the VMusic or restart your existing serial object with the new baud.
Show how you are trying now, maybe we could see an error.
Jeff T.
I ended up getting this to work:
VMusic2.str(string("SBD $4EC000",$0D))
Setting the baud to 38400.
I also tried to set it to 115200, but it stopped working...?
I have two 512 byte buffers. At any time one will be read while the other is filled. The data being read makes output 1 of a 32 bit shift register turn on for a moment, then output 2 and so on till it hits 32, then goes from 32 back to 1 again.
The bug i can't find, is when the buffer is finished, as the next buffer is started, the led that was instructed to come on at the beginning of the previous buffer, comes on for one cycle (the first 32 bytes read of the new buffer) then goes back out.
I have been all over my code and I just can't explain this!
Please help!!
how often do you have to make the exerience again if you do it really fast things turn out to be really slow.
The code you attached does not use shift_reg at all. I guess you archived the wrong file. You can't expect from me that I will solve problems caused by you because of shooting too quick from the hip.
I'm willing to help but only if you are careful about attaching the right code a detailed description of what you expect the code to do and a detailed description of what the code does instead
and inside the code comments on where you guess the bug might be.
speed things up through carefully analysing and describing
best regards
Stefan
P.S. We are on posting 102 after four weeks of time. I estimate the whole thing would be running after just one week and 10 postings if you would use a working-style of collecting information
reading datasheet and manuals carefully, using small testprograms changing only one thing at a time etc.
StefanL38,
Please take a second look at the archive. It is correct. And It does use Shift_Reg.
I appreciate your input as well as your constructive criticism. Though please don't confuse this thread as random aimlessness. Each question has a specific purpose and usefulness, and the excellent support I have received has been extremely helpful. I have dozens of objects dedicated to each little piece of this project, testing different ways of doing each thing this program does so far. Dedicated not only to making this work, but making sure I understand HOW and WHY it works, so next time I undertake such a project, I can be much more self reliant.
I look forward to any help you may be willing to offer on the final steps of making my project functional, and helping me continue my learning an interest in the Prop chip, and its many capabilities.
I would be more then happy to answer any questions you have on my code, to bring you up to speed on where it is at at this point, as I know its been a lengthy thread.
Thanks for the support!
you are right it does use shift_reg. I apologise for beeing upset. From what you have described above you really do your homework. Again I apologise.
One idea is you could add counter-variables and debug-output to check how the loops are repeated. I mean inside the shift-method.
Or to add a single-step mechanism through the parallax serial terminal which also can send bytes to the propeller and then stepping through and sending each interesting variable
to PST.EXE
best regards
Stefan
I played with adding debug (using pst.exe) early on, but it wasn't working. How can I properly use the debug object from a child object? It seemed it had to work differently then how I use it in the main.
This is why you see so many debug led's throughout my code. That helped a lot to find where my program was getting jammed up, but doesn't help with seeing the actual data on the child object (shift_reg) side of things...
there is another serial object called serial mirror which uses buffervariables in a DAT-section.
Variables defined in the dat-section of the code are global.
Another problem from using serial-debug in other cogs is that the data can get mixed up if two cogs access the buffers at the same time.
One way to working around this is to use a buffer for what should be sended. This means different cogs do NOT call methods of FullDuplexSerial directly
but write into a special buffer where each variable has a specified index in the buffer. Then one single cog is checking the buffer for content-changes.
Whenever a change this cog sends always the complete buffer. This will avoid mixing up serial data.
keep the questions coming
best regards
Stefan
I have successfully integrated the SerialMirror.spin into my program. I have so much more debugging capabilities now!
I can now see a readout of the problem. And according to what its showing me, the shiftregister is responding correctly to the data it is receiving. The data is wrong!
Ok here is whats happening. When debug is active in the main object, it is reading all 512 bytes of each buffer directly after it is stored. Everything looks great there. But when the debug is active in the Shift_Reg object, and reads out each byte just before it is shifted out to the shift reg, the data is different at the first 32 bytes. Rather the the first 32 bytes looking as the should, they look exatly like the first 32 bytes of the previously read buffer (the one that is then being filled).
What does this mean!!!!???? I can't find the darn problem!
It has to be a problem in the Shift_Reg object...?
One text doc shows what debug sees in the buffers while running in main object.
The other text doc shows what debug sees in the buffers while running in the Shift_Reg object.
They should match. I just don't get it.....
As this is a double buffer approach you should make sure you have one buffer ready. Then ask for the second buffer before processing the first one. When you're finished with the current buffer idle until the next buffer is ready (the one being filled while you were outputting yours). Ask for the next buffer and continue with processing the current buffer.
*sigh*
I thought I did....
Thank you, it works perfect now!
Though I do need to fix how it handles the end of a file now.
But then it's done!
cool ! Makes me happy that I could help.
IMHO it is an example for:
if you don't understand a problem reading the code start analysing the whole process.
Therefore it's nescessary to get all interesting values and "redo" in your head what the code is doing to comprehend what is going on.
In my experience I had success in most cases if I work this way.
Looking at the values through the debug-output guided you in the right direction - and helped kuroneko too - to find the bug
yeah I like this forum so much
keep the questions coming
best regards
Stefan