Add ADC Channel parameter to the ADC API

[nikkoxp]

Pull Request Overview

This pull request adds:

• a function that returns the number of ADC channels.
• updates the API functions to allow specifying the ADC channel by parameterising the existing functions
• improve the example by adding a while loop was added in the adc.rs file to test all available channels at once

Testing Strategy

This pull request was tested on a microbit.

TODO or Help Wanted

Feedback

[bradjc]

Do we need this for an older version of the kernel? Or is OK if this only works on latest master of the kernel?

If the latter, it would be better to add a new get_counts command to the adc capsule and then use that command number. We made a mistake using command 0 for the count here, and if we fix it now that reduces the overhead for whenever tock 3.0 happens.

[alexandruradovici]

Do we need this for an older version of the kernel? Or is OK if this only works on latest master of the kernel?

If the latter, it would be better to add a new get_counts command to the adc capsule and then use that command number. We made a mistake using command 0 for the count here, and if we fix it now that reduces the overhead for whenever tock 3.0 happens.

This should work with the current version of the kernel. The kernel driver does not have a special command for returning the number of channels, command 0 still does this.

[alexandruradovici]

@nikkoxp please modify the tests.

[alexandruradovici]

Suggested change

	(channel as usize).try_into().unwrap(),
	channel as u32,

I would avoid the panic as most probably usize will be 32 bits.

@jrvanwhy I would like your input on this.

[jrvanwhy]

Without looking at the entire CL: it looks like read_single_sample should take channel as a u32.

One question to ask that helps decide usize versus u32 is "in the unit test environment, which runs on 64-bit platforms, should this number get larger?" I don't think a unit test environment should support more channels than the real hardware, so this should be a u32. usize makes sense for memory addresses and offsets, but not necessarily for other hardware addresses.