Banned
Joined 2002
Flowchart
Hi DJ,
Nice flowchart. So you feel we should start off with a buffered version and not make that a phase 2 thing?
If so, do we know how to convert parallel data to serial audio data for use in the S/PDIF or other serial output method?
Crystal doesn't seem to have a parallel S/PDIF transmitter? Do we know of another chip/manufacturer?
Can we do the buffering, playing, and conversion to serial output within the instructions per second of the MCUs we have discussed? In any case, we will be strapped for cycles so shouldn't we probably use interrupts for button presses.
Thanks,
Gregory
Hi DJ,
Nice flowchart. So you feel we should start off with a buffered version and not make that a phase 2 thing?
If so, do we know how to convert parallel data to serial audio data for use in the S/PDIF or other serial output method?
Crystal doesn't seem to have a parallel S/PDIF transmitter? Do we know of another chip/manufacturer?
Can we do the buffering, playing, and conversion to serial output within the instructions per second of the MCUs we have discussed? In any case, we will be strapped for cycles so shouldn't we probably use interrupts for button presses.
Thanks,
Gregory
Hey Gregory
Since we are trying to build something that will fit the term "hifi", I don't see how we can leave out a buffer, not even at the start. It will probably be the hardest part of the project, but since I don't believe the rest will be too hard, it should be OK.
I still have to read up on the full spec of SPDIF outputs, but as far as I know, it's merely a serial bitstream of the audio data. This means we can read the data in from the CD in parallel, and simply shift it out serially. No magic tricks needed. If my assumption is correct, that would also explain why we haven't seen SPDIF transmitter ICs yet.
I'm not sure about the other MCU's, but the code suggested by my flowchart should work perfectly fine with the DS89C420 (50MHz kinda does the trick). Of course using interrupts for the buttons would save cycles, so we might have to do that.
If there's enough votes for button interrupts (which I suspect there will be) I'll change the flowchart.
Suggestions and comments welcome.
DJ
Since we are trying to build something that will fit the term "hifi", I don't see how we can leave out a buffer, not even at the start. It will probably be the hardest part of the project, but since I don't believe the rest will be too hard, it should be OK.
I still have to read up on the full spec of SPDIF outputs, but as far as I know, it's merely a serial bitstream of the audio data. This means we can read the data in from the CD in parallel, and simply shift it out serially. No magic tricks needed. If my assumption is correct, that would also explain why we haven't seen SPDIF transmitter ICs yet.
I'm not sure about the other MCU's, but the code suggested by my flowchart should work perfectly fine with the DS89C420 (50MHz kinda does the trick). Of course using interrupts for the buttons would save cycles, so we might have to do that.
If there's enough votes for button interrupts (which I suspect there will be) I'll change the flowchart.
Suggestions and comments welcome.
DJ
I think that integrating a buffer is not that difficult. 1Mbyte of static RAM is more than enough, because you don't have to save more than 1/4 sec music.
I have found this about CRC checks:
http://www.upscale.utoronto.ca/GeneralInterest/Drummond/Micro/ln_comm1.pdf
I think that it is VERY important to integrate VERY good error correction.
I have found this about CRC checks:
http://www.upscale.utoronto.ca/GeneralInterest/Drummond/Micro/ln_comm1.pdf
I think that it is VERY important to integrate VERY good error correction.
1 clock cycle per instruction
The Magic of your Maxim MCU is the 1 clock per instruction. The PICs are Fosc/4 at ~40max and so the PIC looks impossible to achieve the 5.6Mhz transmit rate. The DS89C420 datasheet says 33mhz is there a faster 50mhz version?
Still it looks tight, for a high level language but we can cross that bridge when we come to it. Also, in the link that I provided above, it says that the IDE can be commanded to send data directly to the RAM not requireing intervention and this should help with the cycles.
Using a shift register(s) as you suggest should work nicely.
Here is a sample transmitter chip datasheet.
CS8402A
which is available in DIP and does AES/EBU and S/PDIF.
Does anyone know the PCB connector required to accept the standard IDE cable?
Gregory
The Magic of your Maxim MCU is the 1 clock per instruction. The PICs are Fosc/4 at ~40max and so the PIC looks impossible to achieve the 5.6Mhz transmit rate. The DS89C420 datasheet says 33mhz is there a faster 50mhz version?
Still it looks tight, for a high level language but we can cross that bridge when we come to it. Also, in the link that I provided above, it says that the IDE can be commanded to send data directly to the RAM not requireing intervention and this should help with the cycles.
Using a shift register(s) as you suggest should work nicely.
Here is a sample transmitter chip datasheet.
CS8402A
which is available in DIP and does AES/EBU and S/PDIF.
Does anyone know the PCB connector required to accept the standard IDE cable?
Gregory
Firstly, as for Douchekop's posting about CRC checks, like I said, I already have code for this.
To Ray, according to TI the DIT4096/192 does not support SPDIF. I know both are serial, but why would they then not state SPDIF as a feature? I'd rather just program the MCU to shift out a SPDIF compatible stream. Shouldn't be much slower (if any) than sending data serially to a transmitter IC. I'll check out those other ICs you've mentioned though.
To Gregory, yes I also see the DS89C420's webpage now states 33MHz, but the datasheet I have says 50MHz. Either way it should be enough. The PCB connector for IDE is available on sample from Samtec, I'll have to check the part number though. Will get back to you.
Still haven't had time to lay out my prototype PCB yet, but I hope to do so soon.
Keep me updated on your progress guys.
DJ
To Ray, according to TI the DIT4096/192 does not support SPDIF. I know both are serial, but why would they then not state SPDIF as a feature? I'd rather just program the MCU to shift out a SPDIF compatible stream. Shouldn't be much slower (if any) than sending data serially to a transmitter IC. I'll check out those other ICs you've mentioned though.
To Gregory, yes I also see the DS89C420's webpage now states 33MHz, but the datasheet I have says 50MHz. Either way it should be enough. The PCB connector for IDE is available on sample from Samtec, I'll have to check the part number though. Will get back to you.
Still haven't had time to lay out my prototype PCB yet, but I hope to do so soon.
Keep me updated on your progress guys.
DJ
Remote control
Hi DJ,
First, great flowchart. I have some questions regarding the flowchart. Introducing a remote control the code for checking if IR data is coming in should be added to the button pressed part? So decoding the IR-data is in the "which button" part?
Also, we haven't decided on a protocol to use. My suggestion is to use the RC5 code. It's easy to get remote controls for this protocol.
Regarding the buffer part. To get the best quality from the CD. The drive should be stimulated to reread the parts with read errors uptil the buffer runs out. I think that might be a tricky one to code. Also makes the flowchart a bit more complex.
1-Read data from CD
2-Data error free?
yes:goto 4
no:goto 3
3-buffer nearly empty (95%)
yes: goto 4
no:goto 1
4-put data in buffer
Great project though,
Still waiting for my parts to come in.
MGB
Hi DJ,
First, great flowchart. I have some questions regarding the flowchart. Introducing a remote control the code for checking if IR data is coming in should be added to the button pressed part? So decoding the IR-data is in the "which button" part?
Also, we haven't decided on a protocol to use. My suggestion is to use the RC5 code. It's easy to get remote controls for this protocol.
Regarding the buffer part. To get the best quality from the CD. The drive should be stimulated to reread the parts with read errors uptil the buffer runs out. I think that might be a tricky one to code. Also makes the flowchart a bit more complex.
1-Read data from CD
2-Data error free?
yes:goto 4
no:goto 3
3-buffer nearly empty (95%)
yes: goto 4
no:goto 1
4-put data in buffer
Great project though,
Still waiting for my parts to come in.
MGB
Nice thinking MGB, I'll update the flowchart tomorrow morning with your suggestions.
I also agree on using RC5 protocol for the remote (I have code already) and for the simplification of the flowchart this has indeed been included as "buttons". I would however like to use interrupts for the buttons and remote later on.
So far only Gregory has made his voice heard for this. If there's enough interest, I'll change that on the flowchart as well, otherwise I'll code it as a second phase to my project.
Also, I've checked out the CS8401A that someone suggested earlier for outputting the SPDIF signal and indeed it does support SPDIF. BUT it's out of production. The new version is CS8405A (96kHz) and CS8406 (192kHz) and samples are available.
Here's the links:
http://www.cirrus.com/en/products/pro/detail/P57.html
http://www.cirrus.com/en/products/pro/detail/P1009.html
Like I said, you can look for my updated flowchart tomorrow, and I wait to hear more from you guys then.
Cheers
DJ
I also agree on using RC5 protocol for the remote (I have code already) and for the simplification of the flowchart this has indeed been included as "buttons". I would however like to use interrupts for the buttons and remote later on.
So far only Gregory has made his voice heard for this. If there's enough interest, I'll change that on the flowchart as well, otherwise I'll code it as a second phase to my project.
Also, I've checked out the CS8401A that someone suggested earlier for outputting the SPDIF signal and indeed it does support SPDIF. BUT it's out of production. The new version is CS8405A (96kHz) and CS8406 (192kHz) and samples are available.
Here's the links:
http://www.cirrus.com/en/products/pro/detail/P57.html
http://www.cirrus.com/en/products/pro/detail/P1009.html
Like I said, you can look for my updated flowchart tomorrow, and I wait to hear more from you guys then.
Cheers
DJ
I have just finished reading the thread so far, and I would like to state my preferences.
I am hoping to make my own version of this project, but for the first module, I would only like to be able to control the CDROM. No LCD, no sound buffering etc. also, on the back of my CDROM, there are connections for sound output, which would normally be connected to the soundcard of the computer. I have not tested this yet, so does anyone know if the sound from the CD can be read from here, without using the IDE connector?
My preference for microcontroller would be microchip's PIC range, as I have experience with these. If a programming language that cannot be converted for all the microcontrollers is decided on, someone who knows both languages could translate the program.
As for a power supply, I have a PC PS, and I am probably going to use this.
Could someone post a list of slot-load CDROMS, as I cannot find any?
I am hoping to make my own version of this project, but for the first module, I would only like to be able to control the CDROM. No LCD, no sound buffering etc. also, on the back of my CDROM, there are connections for sound output, which would normally be connected to the soundcard of the computer. I have not tested this yet, so does anyone know if the sound from the CD can be read from here, without using the IDE connector?
My preference for microcontroller would be microchip's PIC range, as I have experience with these. If a programming language that cannot be converted for all the microcontrollers is decided on, someone who knows both languages could translate the program.
As for a power supply, I have a PC PS, and I am probably going to use this.
Could someone post a list of slot-load CDROMS, as I cannot find any?