Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ADC on every IO pin #115

Closed
electroniceel opened this issue Mar 12, 2019 · 8 comments
Closed

ADC on every IO pin #115

electroniceel opened this issue Mar 12, 2019 · 8 comments
Labels
hardware Component: hardware rev? Hardware revision: future

Comments

@electroniceel
Copy link
Member

Enhancement idea for a future hardware revision:

Use muxes to be able to automatically connect the ADC to any regular IO pin, not just dedicated analog sense pins. This would allow to improve the automatic detection capabilities. An applet could just scan the voltages on all pins and select the correct io voltage level or complain if one or more pins are not within a common level.

Another idea would be to wiggle the pullups/pulldowns while the adc is sampling in sync. This would allow to guess the impedance of the possibly unknown stuff connected to this pin. This would help the user to make a guess at finding out what a pin does. It also helps deciding if it is safe to use push-pull logic on a pin or not.

Both features would also increase the value of Glasgow for small scale automated post-production tests.

Ideas to implement it:
a) an 8 channel analog mux, like 74HC4051, between the pins and voltage divider, then the ADC.
Drive it with 5V Vcc, you need 4 control lines on 5V-level from somewhere. But you can then switch off the voltage divider for the ADC.

b) Replace the ADC with a 5V-compatible microcontroller that has an ADC and 8 or more analog input pins. For example some Atmel part like the Attiny416 https://www.microchip.com/wwwproducts/en/ATTINY416 would probably work. It also seems to be even cheaper than the ADC081C021.

You could communicate with it via I2C (I2C level shifting to 5V needed). For programming it uses UPDI, which would probably need a connection to the FPGA with another '1T45 for level shifting.

@whitequark whitequark added the rev? Hardware revision: future label Mar 12, 2019
@whitequark
Copy link
Member

This would allow to guess the impedance of the possibly unknown stuff connected to this pin.

That's doable purely in the digital domain. In fact the jtag-pinout applet already does something like it.

@whitequark
Copy link
Member

Is there a reason this should be on the main PCB? This significantly increases area, cost and complexity.

I think you can implement this with a board that plugs into (let's say we have revC) port A and port B. Port A is the normal digital port, powered however you like, port B has the mux and ADC connected to it, and is powered from 5 V. This a) doesn't require everyone to pay for this non-essential feature, b) allows to iterate this fairly complicated analog circuit separately from Glasgow.

@electroniceel
Copy link
Member Author

electroniceel commented Mar 12, 2019

Wow, that was a fast reply :-O

That's doable purely in the digital domain. In fact the jtag-pinout applet already does something like it.

Don't you get just stuff like "high-Z" or "push/pull" in the digital domain? I'd prefer to get some estimate of the pullup/pulldown strength, like is it more like 4K (-> could be I2C) or more like 50K.

Is there a reason this should be on the main PCB?

It could be an addon pcb.

This significantly increases area, cost and complexity.

Really? For my suggestion with the Attiny you'd replace the ADC081C021 with the Attiny (3x3 QFN). You'd need one more '1T45 and one more TCA9517. I wouldn't call this significantly. But you are to decide.

The Attiny also includes a DAC, so you could replace that too.

@whitequark
Copy link
Member

whitequark commented Mar 12, 2019

Don't you get just stuff like "high-Z" or "push/pull" in the digital domain? I'd prefer to get some estimate of the pullup/pulldown strength, like is it more like 4K (-> could be I2C) or more like 50K.

You can estimate pull strength by measuring its time constant with just the digital driver, then with a configurable (known value) Glasgow pullup, then solving for unknown R. You don't know the exact input threshold voltage for this PVT point, but you can calibrate it against a known resistance (integrated 1% pull resistor) and known capacitance (connect a capacitor to a pin).

Really? For my suggestion with the Attiny you'd replace the ADC081C021 with the Attiny (3x3 QFN). You'd need one more '1T45 and one more TCA9517. I wouldn't call this significantly. But you are to decide.

This can't possibly physically fit on revC. Also, unless we replace the old DACs we don't have enough pins on the FX2 for UPDI, so there's no way to program this microcontroller.

But the most significant part is: the need to add a completely new kind of programmable logic to the device, add even more level shifters (which are extremely finicky and in fact we are getting rid of TCA9517s because they're too unreliable to use), add a new toolchain (which needs to be added on CI, has its own unique quirks, etc), add a new firmware (which needs to be stored somewhere, appropriately reflashed when it's stale, etc), add a new programming interface (which needs to be implemented to fit in the already quite scarce 8051 RAM), qualify new analog circuitry... probably a few things I've missed. All this without ever dropping support for the old DAC and/or ADC (because we support existing boards forever), of course.

The "simplicity" of adding a microcontroller is misleading; in fact there is no simplicity at all. That would still be true even on a completely new design, microcontrollers are inferior to programmable logic as well as hard logic when it comes to reliability. Programmable logic allows you to trivially prove strong isolation for different components, and hard logic allows you to use physically independent components. A microcontroller requires some kind of scheduling, which is very easy to get wrong in edge cases. A microcontroller usually has bugs in its I²C implementation, or at least more bugs than a typical discrete DAC/ADC. I would never implement this feature with a microcontroller even if I chose to put it on the base design.

@marcan
Copy link
Member

marcan commented Mar 12, 2019

I concur; using a microcontroller adds all kinds of horrible complexity that we don't want here, and there is no way this is ever going to fit on revC.

@electroniceel
Copy link
Member Author

I understand your reservations against adding a microcontroller.

So if this is added to the Glasgow PCB, it would have to be done with an analog mux or an I2C ADC (MAX11602, NCD9830,...). Both would need more board space.

@whitequark
Copy link
Member

No Maxim parts in any production designs.

@whitequark
Copy link
Member

Unrealistic for revC/D. I'd be interested in such an add-on card but I don't consider myself a competent analog designer, so this goes in the "An Interesting Project" category. Therefore, closing as not immediatealy actionable.

@whitequark whitequark added the hardware Component: hardware label Apr 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hardware Component: hardware rev? Hardware revision: future
Projects
None yet
Development

No branches or pull requests

3 participants