efus™A7UL starter kit - Analog to Digital Converter

All pins on the connector that have a GPIO number of 0..9 in the GPIO Reference Card are candidates for ADC, because i.MX6UL can use these pins as inputs for its internal ADCs (i.MX6UL has two ADC units with 10 channels each which are connected to GPIO1_IO00 to GPIO1_IO09). So there are actually a few pins that can be used as ADC input. However most of them have a different function by default. This has two implications: 1. You can only use them if you do not need the regular function. 2. Some of these pins may have internal pull-up or pull-down resistors, making voltage measurement a little bit difficult.

We have not added the ADC driver to the device tree on efusA7UL yet, and therefore we have not tested ADC yet. But it should be possible.

Please note that using ADC on efusA7UL is not a guaranteed function. It is only possible by pure chance by the current pin mux. If we ever change the pin configuration in a redesign of the board, we can not guarantee that the ADC function remains on the same pins or remains available at all.

If you want to have regular ADC inputs, you can use the efusA9X which has 4 dedicated ADC inputs.

Your F&S Support Team

OK, let me explain this in more detail.

efus is a kind of F&S specific standard. It defines which signal is present on which pin of the goldfinger connector. However depending on the SoC (System-on-Chip) that is used on a specific efus module, not all of the functions of the standard can be supported. For example we have defined signals for two ethernet ports on the connector, but the regular efusA9 can only provide one ethernet port because the i.MX6-SoC has only one etherent unit built-in. But the efusA9X and efusA7UL can actually provide both ethernet ports, because the i.MX6SX and i.MX6UL have two builtin ethernet controllers. But on the other hand they can not support some other features of the efus standard.

In the standard, we have defined four ADC inputs (pins 44, 42, 40, 38). But efusA7UL can not support these because it has too few I/O signals in general and the I/Os of the i.MX6UL that are capable of ADC are desperately needed for other functions. So these four ADC pins of the goldfinger connector are not connected on efus7UL. Which means basically there is no ADC support for efusA7UL in the first place.

But as I said, the pins of the SoC are usually multiplexed. Which means the pins that we use for dedicated function A may also have a second dedicated function B or even a third function C or they may be used as general purpose I/Os. So it is sometimes possible by pure chance that all pins for a secondary function are available on the connector. Which means if the primary function(s) of these pins are not required, these pins can also be used for the secondary function. For example on efusA7UL, the pins 102 and 104 are UART_B_RXD and UART_B_TXD. But the pinmux of the i.MX6UL also allows to have an I2C port there. So if you do not need UART_B, you can optionally use an I2C port on these two pins. So you could modify the device tree to have an I2C port there.

Of course these alternative functions are only possible by pure chance on exactly this SoC. Another SoC will not have the same secondary function on these signals, or probably any additional function at all. Therefore we can not guarantee that any of these secondary functions will be available on any other efus module. So you can use these secondary functions, but you have to be aware of the fact that this breaks efus standard and that your application will most probably not be compatible with any other (existing or future) efus module. So one of the main benefits of a module family, i.e. the easy replacement by a more powerful module, less expensive module or simply by a succesor module, is not possible anymore when using such secondary, non-standard functions. This is why we always issue a warning to customers who want to use such secondary functions.

This is what I meant in my last post. The main ADC pins of the connector are not in use on the efusA7UL, but some of the ADC-capable signals are in fact available at other places on the connector, namely all pins which have a GPIO number < 10. So instead of using these other pins with their primary function, they can alternatively be used as ADC inputs. But of course then this is a non-standard secondary function and any newer efusA7UL version (for example a re-design because of some hardware errors) may re-order such signals if we deem necessary.

And at the moment we do not have any support for these additional functions in our efusA7UL device tree. This is still on our TODO list. Which means you have to modify the device tree on your own before you can use any of these pins as ADC input. And maybe you even have to add the ADC driver to the kernel if it is not included yet. Without these modifications, you will not find any ADC entries under /sys.

Unfortunately ADC has yet another problem. The generic ADC infrastructure is rather new in the kernel. Before that, all SoC manufacturers and ADC chip manufacturers had their own ADC drivers which were all quite different. So the example that you refer to is for our boards based on the NXP Vybrid SoC and it uses the Vybrid-specific ADC implementation. The definitions in the header file and even some ioctl()-calls do not make sense on the efusA7UL, they are only valid on Vybrid. So the example code has to be modified, too, to work on efusA7UL.

So yes, having ADC on efusA7UL is not an easy task. You need to know what you are doing.

You F&S Support Team