For CV you’ll also need DACs and ADCs with driver circuits that support DC coupling - e.g. capacitors should not be in series with the output, only in parallel (to ground, as a filter). This strongly depends on the driver topology in the chip as well. Some DACs are unstable without DC filtering on the output, some are designed for it. ADCs aren’t as important as they are effectively a small capacitor that is switched on and charged by whatever voltage is on the input and then switched off to measure - that little charge is then measured by the internal circuit during a subsequent conversion period, after which the cycle begins again, but make sure you don’t have DC filtering in the (usually op-amp based) driver amplifier in front of the ADC stage.
I was thinking 16 as the highest resolution, might step down to 12bit, thinking it might be to much data sampling 8 or 16channels of 16bit CV data simultaneous as transmitting 8 or 16 channels of 16bit data to a DAC, but I have no experience so I’m just guessing, just trying to stay cautious
Well you said MIDI to CV. MIDI over DIN has a bandwidth of just under 4kbytes/sec and CV takes three bytes to transmit, so the max CV rate is roughly 1.3kcommands/sec. If you’ve got 16 channels, you’ll be updating each channel at a maximum of ~80Hz.
USB MIDI has a bandwidth theoretically up to the USB bus limit, although in practice due to reserved bandwidth and other overhead, and the fact that most USB MIDI implementations are USB 2.0 FS (12Mbit/sec) you rarely get more than about half the theoretical bus speed, and it’s bursty, in 1ms chunks. So you’re still not going to be sending updates much faster than 1kHz with any real meaning to them, although you can send all 16 channels that way.
MIDI has a maximum resolution of 14 bits for the first 32 CCs, and 7 bits for the others, so there is no point in having an ADC with higher than 14 bit resolution, and you can easily get a fast 12-bit ADC to oversample sufficiently to get 14 bits of real resolution out of it, if you’re clever (the ADCs built into ST’s ARM microprocessors can do this trivially). You can use a similar dithering technique to turn a 12-bit DAC into a higher resolution one if you’re willing to accept some filtering on the output (highpass, so DC can still pass through). These are advanced techniques, but well within the range of a typical microprocessor, especially at the comparatively slow data rates of MIDI.
Honestly, 14 bits is almost certainly enough, especially at 4x oversampling, and you can get a usable 16 bits out of oversampling a 12-bit ADC 16x or more. Even pitchbend is just 14 bits for MIDI and (almost) nobody complains about it being insufficiently precise.
Fast is relative. There are ADCs that operate at GHz. The typical on-chip utility ADCs on ST MCUs will easily run up to a few MHz at lower resolutions, so a few tens of kHz is entirely doable for several channels simultaneously.
Of course, you’ll find limits everywhere - memory bandwidth, cpu processor speed, SPI bandwidth, etc. You’ll have to do the math yourself to figure out which constraints you’ll run into and how you might solve them (multiple ADCs on separate busses, DMA transfers, etc.)
I’m curious, O_c and Crow are based on the TI DAC8565. Is there a specific reason to use exactly it?
New to electronics, I’m searching something to use in DIY project for Eurorack ecosystem, some standalone device for sending CV modulations.
politely disagree, you might want to be able to shift / scale the sampled CV value, and such operations will burn bits. (say for example you want to map [0, 2.5V] to pitchbend [0, 16383], you lose 2 bits from the sample resolution.) i think 16 bits is a good sweet spot for price / selection.
if you can’t do any transformation of the captured signal then i agree with your statement, but seems like a bummer limitation for a programmable device.
re: oversampling, it is true that you can do this. but in general i would not recommend it as a first strategy for something implemented on a microcontroller.
things to consider when designing an oversampled system:
for each additional “effective bit” of resolution, you must oversample by a factor of 4x. that adds up quickly.
increasing effective resolution by oversampling reduces overall throughput by the oversampling factor! this is a big deal for a MIDI device.
a good averaging filter is not going to be cheap, and it will add additional latency beyond the oversampling factor.
this trick only works if the noise source is stationary and uniform. that’s often a decent assumption, but sometimes it’s not, and sampling arbitrary CV definitely exposes you to the edge cases.
so on balance i think it’s almost always better to simply get a higher-order sigma-delta ADC that effectively does this stuff in silicon with far greater efficiency.
all that said, i think @Galapagoose has the right of it: just try with what you have first, likely it is perfectly adequate for your purposes and you will never actually notice whether the pitchbend is 12b or 14b or whatever. if sampling resolution turns out to be a critical parameter, then the next engineering decision is whether it makes sense to integrate additional hardware, or attempt a software solution.
there’s no one-size answer, in part because getting a random external converter to work with your uC of choice could be a rabbit hole with dubious benefit, and like @tehn says it opens up several non-trivial engineering problems.
Back when I did this sort of thing I was working with an stm32f4 and the WM8741 as a DAC, which does 24-bit stereo out and is used widely in commercial applications. I haven’t used anything external for ADC but for control voltage you could just use the discovery board’s ADC/DAC. I know that tom erbe uses stm32 chips on his make noise modules. The other voices in this thread are certainly more knowledgeable on the subject than I am, however