Following the Polyphonic Musicbox project https://github.com/GreatCowBASIC/Demonstration_Sources/blob/main/Music
I am thinking of another audio related project, a musical instrument, with higher resolution sound, either using a PIC with 10-bit DAC (one chip, simple and cheap) and a version adding an external DAC for better dynamic range.
===I2S DAC:===
Looking at external DAC it is tempting trying to get i working with a Proper i2S DAC (built in 1/2Fs filter and low noise). I haven't seen anyone doing this with 8-bit PIC, which makes it extra tempting.
I have an idea of using an extra little PIC inbetween the sound generating PIC and the DAC, converting the audiostream into I2S (using GCbasic). This is probably the easiest solution to get up and running.
Another idea is using only one channel of the DAC and dedicating half the time for updating the I2S data and the rest for the sample player. Or partly multiplexing. The question here is if an interrupt is time stable, i.e. when it triggered from a timer, will it alway take the same number of clock cycles every time to jump to the ISR?
(The jitter can't be very great for the I2S to fail, so is it worth testing or is it bound to fail is the question. I'm guessing that 1-3 instruction cyckles difference in time from interrupt to interrupt could be acceptable.)
Looking at SPI the protocol looks similar to I2S. The question is if SPI is capable of delivering a stready, never stopping clock stream. Both clock and L/R by using SS (should invert every 16 clock cycles) , must run without pauses or interuption.
To get something done, I like to avoid starting off wasting time and ending up running in to a brick wall on something that is known to or will likely fail completely.
Any suggestion or opinion is welcome, helping me making a decision on which path forward to choose first.
Last edit: Roger Jönsson 2026-03-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ofcourse. I have already tried the PIC 18F56q71 and its 10-bit DAC. It does the job, but is a little short of program memory (64kB).
However I was thinking of even higher resolution and using a DAC with proper Fs/2 filters, so that apart from the obvious larger dynamic range, many units can be mixed together without getting aliasing noise and distortion (from the unfiltered of badly filtered DAC outputs when mixed together).
The AVR128DA28 is interesting anyway, in that it has both a good portion of Program memory and RAM. A bit of unknown for me, but if needed I'm sure it is possible to port to it.
This shifts the subject, but still:
The max clock frequency is 24MHz. How would that compare to the 18F57Q84 at 64MHz. You had a peak at the Musicbox program, would you guess the AVR would perform faster or slightly slower?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After some testing, mistakes, testing again I'm getting a hang of bit banging.
I managed to get i2S to an audio DAC from 16-bit parallell data. On a PIC18F57Q84 @ 64MHz it can handle up to 48kHz sample frequency.
My testprogram is now running at 32kHz, but it is easy to get it to 48kHz by removing triplets of nops and fine tuning downwards slighty with OSCTUNE.
I have an idea of a sampler using two PIC18F27Q84 and an i2S Audio DAC.
Placing the two PICs side by side like this makes easy to connect the two PICs together.
I have a working solution with just one extra PIC18F57Q84 (GCB file attached above). It takes the parallel data and outputs i2s (incl flipping the MSB as per i2S standard). There is a requirement when the sender is allowed to update the parallel port to avoide glitches, otherwise I see no issues so far. Up to around 50kHz sample freqeuncy is possible, but it may require some code adustement removing or adding nops. I have a plan for making this externally selectable through setting pins, unless I go for completely different solution.
For audio this parallel to i2S converter is the sample clock master, sending an interrupt signal to the parallel audio sender. The DAC needs to be one with internal PLL if it needs a higher frequency DAC master clock. I have been using PCM5102 during the tests. There is also a PCM5100 with a slightly higher S/N. It is cheap but should be able to deliver very good sound quality still.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes! We're down from a two chip to a one chip solution for outputting High resolution audio! I got i2S working using two timers+PWM making the logic pattern and an interrupt starting/syncing the audio bitstream blocks off. Inside the ISR, after the bitbanging, the sample data handling is done (for next bunch of 16bits).
Using the faster clock i2s 64bit format (2.048MHz for 32kHz sampling freq), sending one channel of 16bit data, there is about 70% of processing time left for handling samples or whatever.
Based on earlier experiments I assumed a normal interrupt would be way too slow, then I tested it with the Q84 chip and found it to be more efficient and by setting the first bit last in the ISR before the interrupt triggers, then valuable time has been shifted in time making the serial bit banging pretty easy!
It should be possible to tune the code and clock/Timers to handle 48kHz, but I'll settle here.
...For now.
Following the Polyphonic Musicbox project https://github.com/GreatCowBASIC/Demonstration_Sources/blob/main/Music
I am thinking of another audio related project, a musical instrument, with higher resolution sound, either using a PIC with 10-bit DAC (one chip, simple and cheap) and a version adding an external DAC for better dynamic range.
===I2S DAC:===
Looking at external DAC it is tempting trying to get i working with a Proper i2S DAC (built in 1/2Fs filter and low noise). I haven't seen anyone doing this with 8-bit PIC, which makes it extra tempting.
I have an idea of using an extra little PIC inbetween the sound generating PIC and the DAC, converting the audiostream into I2S (using GCbasic). This is probably the easiest solution to get up and running.
Another idea is using only one channel of the DAC and dedicating half the time for updating the I2S data and the rest for the sample player. Or partly multiplexing. The question here is if an interrupt is time stable, i.e. when it triggered from a timer, will it alway take the same number of clock cycles every time to jump to the ISR?
(The jitter can't be very great for the I2S to fail, so is it worth testing or is it bound to fail is the question. I'm guessing that 1-3 instruction cyckles difference in time from interrupt to interrupt could be acceptable.)
Looking at SPI the protocol looks similar to I2S. The question is if SPI is capable of delivering a stready, never stopping clock stream. Both clock and L/R by using SS (should invert every 16 clock cycles) , must run without pauses or interuption.
To get something done, I like to avoid starting off wasting time and ending up running in to a brick wall on something that is known to or will likely fail completely.
Any suggestion or opinion is welcome, helping me making a decision on which path forward to choose first.
Last edit: Roger Jönsson 2026-03-07
https://en.wikipedia.org/wiki/I2S
The AVR128DA28 has a 10-bit DAC, 128 KB and supported by GCBASIC.
This would a lot easier to integrate.
Last edit: Anobium 2026-03-07
Ofcourse. I have already tried the PIC 18F56q71 and its 10-bit DAC. It does the job, but is a little short of program memory (64kB).
However I was thinking of even higher resolution and using a DAC with proper Fs/2 filters, so that apart from the obvious larger dynamic range, many units can be mixed together without getting aliasing noise and distortion (from the unfiltered of badly filtered DAC outputs when mixed together).
The AVR128DA28 is interesting anyway, in that it has both a good portion of Program memory and RAM. A bit of unknown for me, but if needed I'm sure it is possible to port to it.
This shifts the subject, but still:
The max clock frequency is 24MHz. How would that compare to the 18F57Q84 at 64MHz. You had a peak at the Musicbox program, would you guess the AVR would perform faster or slightly slower?
AVR clock architecture is very different from a PIC. And, are comparable.
After some testing, mistakes, testing again I'm getting a hang of bit banging.
I managed to get i2S to an audio DAC from 16-bit parallell data. On a PIC18F57Q84 @ 64MHz it can handle up to 48kHz sample frequency.
My testprogram is now running at 32kHz, but it is easy to get it to 48kHz by removing triplets of nops and fine tuning downwards slighty with OSCTUNE.
I have an idea of a sampler using two PIC18F27Q84 and an i2S Audio DAC.
Placing the two PICs side by side like this makes easy to connect the two PICs together.
Great, thumb up for your project!
I've never tried that, but maybe two shift registers could help, e.g. of type 74HC166.
I have a working solution with just one extra PIC18F57Q84 (GCB file attached above). It takes the parallel data and outputs i2s (incl flipping the MSB as per i2S standard). There is a requirement when the sender is allowed to update the parallel port to avoide glitches, otherwise I see no issues so far. Up to around 50kHz sample freqeuncy is possible, but it may require some code adustement removing or adding nops. I have a plan for making this externally selectable through setting pins, unless I go for completely different solution.
For audio this parallel to i2S converter is the sample clock master, sending an interrupt signal to the parallel audio sender. The DAC needs to be one with internal PLL if it needs a higher frequency DAC master clock. I have been using PCM5102 during the tests. There is also a PCM5100 with a slightly higher S/N. It is cheap but should be able to deliver very good sound quality still.
Yes! We're down from a two chip to a one chip solution for outputting High resolution audio!
I got i2S working using two timers+PWM making the logic pattern and an interrupt starting/syncing the audio bitstream blocks off. Inside the ISR, after the bitbanging, the sample data handling is done (for next bunch of 16bits).
Using the faster clock i2s 64bit format (2.048MHz for 32kHz sampling freq), sending one channel of 16bit data, there is about 70% of processing time left for handling samples or whatever.
Based on earlier experiments I assumed a normal interrupt would be way too slow, then I tested it with the Q84 chip and found it to be more efficient and by setting the first bit last in the ISR before the interrupt triggers, then valuable time has been shifted in time making the serial bit banging pretty easy!
It should be possible to tune the code and clock/Timers to handle 48kHz, but I'll settle here.
...For now.
The GCB code.
Last edit: Roger Jönsson 1 day ago