I did extensive investigation tonight into this program and its assumptions that the SCIF/SIOF matches the SH7730. I was particularly confused that though you equate the SCIF2 symbol to the address for SIOF on the 7730 (0xA4410000), you then access its registers as if it was indeed a scif0, and that success of your application knows that you are indeed accessing a SCIF rather than a SIOF. We could attach a serial CODEC and get great stereo sound out and in, as the SIOF information demonstrates, but sadly, I'm now 99% sure that a combination of the hardware (I see circuitry on the RX/TX lines that would force unidirectionality from examining the PCBs) and the CPU (the RxD and TxD lines on the 7730's SCIF are fixed undirectional, whereas the 7720ish ones have bidirectional lines) that we can only do mono, single-ear sound output.
Well sorry for the massive bump but I did a little quick work on this and was able to improve the quality simply by using a new algorithm. It is louder and of higher quality with a small side effect of a quite high pitch noise which can be easily solved with an RC low pass filter and/or faster baud rate. I have some recordings as I have a 2.5mm to 3.5mm cable if anyone wants to hear a comparison. Binary:
https://github.com/ComputerNerd/CGplayer/blob/master/CGplayer.g3a
Source: https://github.com/ComputerNerd/CGplayer/blob/master/src/main.c
And for those who don't want to bother clicking on the link here is the new algorithm it is more simple that what was originally used.
Code:
Also it uses this table
Code:
https://github.com/ComputerNerd/CGplayer/blob/master/CGplayer.g3a
Source: https://github.com/ComputerNerd/CGplayer/blob/master/src/main.c
And for those who don't want to bother clicking on the link here is the new algorithm it is more simple that what was originally used.
Code:
unsigned samp=gpBuffer[giBufIndex++]>>3;
if(giBufIndex>=giLength)
return;
unsigned x;
for(x=0;x<4;++x){
if(samp>7){
SCIF2.SCFTDR=255;
samp-=8;
}else{
SCIF2.SCFTDR=ptab[samp];
samp=0;
}
while((SCIF2.SCFDR.WORD >> 8)>=15);
}
Also it uses this table
Code:
static const unsigned char ptab[]={0,1,3,7,15,31,63,127};
Yes and it is going to get better too
I already figured out that doing
Code:
Which switches to synchronous transfer and thus increases the baud rate by around 8 times so I could get full 8 bit resolution with 13000 Hz sample rate. I am also playing around with a new algorithm from http://trolsoft.ru/articles/bresenham-algo/?lang=en right now it makes lots of white noise so I am seeing if I am doing something wrong.
Edit: I tried the algorithm and it appears to sound worse it may be due to the prizm's cpu not being able to keep up with this not sure. Anyways I pushed a new version with binary (link is the same) that features the faster baud rate and hence higher quality but not using the pwm algorithm that the link features. I think it would be higher quality if it could be optimized more I will try and figure out something.
I already figured out that doing
Code:
SCIF2.SCSMR.BIT.CA=1;
Which switches to synchronous transfer and thus increases the baud rate by around 8 times so I could get full 8 bit resolution with 13000 Hz sample rate. I am also playing around with a new algorithm from http://trolsoft.ru/articles/bresenham-algo/?lang=en right now it makes lots of white noise so I am seeing if I am doing something wrong.
Edit: I tried the algorithm and it appears to sound worse it may be due to the prizm's cpu not being able to keep up with this not sure. Anyways I pushed a new version with binary (link is the same) that features the faster baud rate and hence higher quality but not using the pwm algorithm that the link features. I think it would be higher quality if it could be optimized more I will try and figure out something.
ProgrammerNerd wrote:
Well sorry for the massive bump but I did a little quick work on this and was able to improve the quality simply by using a new algorithm. It is louder and of higher quality with a small side effect of a quite high pitch noise ...
Hello, thank you for updating cgplayer
The serial port is not very good as 1 bit D/A converter. It seems the volume decreases with higher speed of data and there is a some non-linearity.
I see how you simplified the algorithm, but the change groups equals bits together.
Assume you want to send 24 "one" bits (samp ==24)
Your algorithm sends 3x byte "255" and one "0" byte. My algorithm tries to spread zero bits equally to all the bytes (so the error frequency is as high as possible).
This explains higher volume. The quality is subjective.
Just explaining why my algorithm was so complex.
Yes I do see your point and was aware of this issue and already tried addressing it in another way but got worse results as it caused a decrease in audio speed meaning that was sending data faster than generated thus causing slower audio playback speed and static. Also did you read my more recent post? I figured out how to increase baud rate which did increase quality.
ProgrammerNerd wrote:
Also did you read my more recent post? I figured out how to increase baud rate which did increase quality.
Of course I did ! I will probably try it myself because it sounds promising.
Did you try asynchronous output ?
- 24 Sep 2014 12:58:40 pm
- Last edited by ProgrammerNerd on 25 Sep 2014 04:09:26 pm; edited 1 time in total
No the action of switching from the default which is asynchronous to synchronous also has the effect of increasing the baud rate.
It is this line of code that simultaneously switches to synchronous mode and makes the baud rate faster.
Code:
The sh7724 datasheet gives different formulas for synchronous and asynchronous
The SCBRR setting is calculated as follows:
• Asynchronous mode:
N = {Pφ / (64 × 2 2n-1 × B)} × 10^6 - 1
• Clock synchronous mode:
N = {Pφ / (8 × 2^(2n-1) × B)} × 10^6 – 1
It is this line of code that simultaneously switches to synchronous mode and makes the baud rate faster.
Code:
SCIF2.SCSMR.BIT.CA=1;
The sh7724 datasheet gives different formulas for synchronous and asynchronous
Quote:
The SCBRR setting is calculated as follows:
• Asynchronous mode:
N = {Pφ / (64 × 2 2n-1 × B)} × 10^6 - 1
• Clock synchronous mode:
N = {Pφ / (8 × 2^(2n-1) × B)} × 10^6 – 1
ProgrammerNerd wrote:
No the action of switching for the default which is asynchronous to synchronous also has the effect of increasing the baud rate...
That was a little misunderstanding. You are talking about the HW, that you put into the synchronous mode so the speed is much higher, This is awesome and I will try it myself when I get some time.
I was talking about the software. Currently there is a simple loop polling the port and outputting data when fifo is not full. What I meant by "asynchronous" was something like set some function to be called when fifo is empty and feed the fifo asynchronously by interrupt. That way the CPU will be free for other task, e.g. decompressing next video frame.
Well actually I do have an (untested) idea. Use DMA and have two buffers. Que the transfer for both after initializing both buffers. When the first transfer is done the second one will start this utilizes the DMAC priority system. When the program detects that the second buffer is transferring the first can be filled with new data and so on. Also even if you do get an interrupt going you still need it to call the desired function instead of whatever Casio provided unless that function provides a callback mechanism which I do hope it does at that would reduce complexity of the program. I started reading the datasheet for the sh7724 to see if I can change the vector table address and it appears that I can but I still need to research the details. The datasheet does say
The reset vector address is fixed at H'A0000000. Exception and interrupt vector addresses are
determined by adding the offset for the specific event to the vector base address, which is set by
software in the vector base register (VBR). In the case of the TLB miss exception, for example,
the offset is H'00000400, so if H'9C080000 is set in VBR, the exception handling vector address
will be H'9C080400. If a further exception occurs at the exception handling vector address, a
duplicate exception will result, and recovery will be difficult; therefore, addresses that are not to
be converted (in P1 and P2 areas) should be specified for vector addresses.
Which seems to suggest that doing this will work and it will be say as it is reset upon a reset so in case the user presses the reset button or takes out the batteries while an audio program is running it should be fine.
If we don't use DMA interrupts there will still be some minimal polling needed but it is a lot less than the current solution. I do agree that interrupts would be a better solution.
Quote:
The reset vector address is fixed at H'A0000000. Exception and interrupt vector addresses are
determined by adding the offset for the specific event to the vector base address, which is set by
software in the vector base register (VBR). In the case of the TLB miss exception, for example,
the offset is H'00000400, so if H'9C080000 is set in VBR, the exception handling vector address
will be H'9C080400. If a further exception occurs at the exception handling vector address, a
duplicate exception will result, and recovery will be difficult; therefore, addresses that are not to
be converted (in P1 and P2 areas) should be specified for vector addresses.
Which seems to suggest that doing this will work and it will be say as it is reset upon a reset so in case the user presses the reset button or takes out the batteries while an audio program is running it should be fine.
If we don't use DMA interrupts there will still be some minimal polling needed but it is a lot less than the current solution. I do agree that interrupts would be a better solution.
Register to Join the Conversation
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement