Actually, I think that’s on par with the STM32, at least the one I’m using. 1MHz and 1usec are just inverses of each other right? I just did a quick timing test of analogRead() on my Due and it takes a little under 5 usecs… still a lot better than the AVR’s 110 usecs. You’d need to poke around in analogRead() with the SAM datasheet in hand to see why it’s not 1 usec… could be they’ve slowed it down for source impedance issues like I described above for the STM32. I’d look but I don’t think I’ve got room in my head for a third ADC architecture, and don’t want to lose the two I’m still using (AVR and STM32 ;-).
From a compatibility point of view, I think the Due would be a great way to go. The only downside is it seems to be a discontinued product. No idea why.
It’s probably worth distinguishing between the number of ADCs the device has (typically 1 or 2) and how wide the MUX is that’s in front of them (often 12 or higher), which I think is what you’re referring to there. Now those that do have 2 ADCs almost all have a way of triggering synchronised conversions. Rather than starting one and then starting the other, which would introduce at least a few CPU cycles of lag, you can arm each of them, and then with a single write say “START”.
Utilising that in an OEM product would eliminate one source of phase shift as you could dedicate one ADC to the V (or Vs in the case of 3-phase) and the other to the CTs (always choosing the correct V for a particular I). Of course you won’t be able to do that if you’re sitting on top of the classic analogRead() HAL but it’s a potential performance tweak that extreme power-geeks could add later.