Add self tests

[usbalbin]

What do you think about adding some sort of self tests that can be run on a nucleo board as done here?

[astapleton]

That looks really cool. I think that would be a good addition. Do you want to work on that? I've got a bit of a backlog at the moment...

[usbalbin]

Sure! I have some stuff to do first but then yes. I might try to clean up the linked one a bit first and then at some point try to move it here.

[oshaughnessya]

I know I have looked into embedded-test in the past and prefer it.

[usbalbin]

I have cleaned up the above a bit(still a lot of room for improvement), removed all tests for missing peripherals and ported it to this crate in #52. Turns out two gpio tests were the only tests I could keep. Will probably add some more gpio related.

Do you have any ideas for more things to test for? And if so then how? :)

[usbalbin]

Currently present peripherals

	What to test	How to test it
Gpio IN	is_high/lo	use pull up/down to set level
Gpio OUT push/pull	set_high/lo	set level and check IDR register
Gpio OUT Open drain	set_high/lo	with pull up, set level and check IDR register
Gpio Pull Up/Down		Same as Gpio IN
Rcc
ICache
I2C

Future peripherals

	What to test	How to test it
ADC	Vref,Temp,Pin	measure vref,temp and dac/(or jumpered digital output pin until DAC impl)
CAN		-
Timers	Frequency/duration	Compare with stm32::DWT::cycle_count()
PWM	Frequency and duty	Compare with stm32::DWT::cycle_count()
Rng	Check distribution	Generate lots of numbers, collect them into buckets and check bucket sizes
I2C		-
SPI
UART
Flash	Read and write	Store number and read it back
DMA		Test with ADC?

Feel free to edit

[astapleton]

DMA can also be tested with memory to memory transfers. I have an unpublished example that does just that

[usbalbin]

I do not know about you, but think there is quite a lot of value in having the vast majority, if not all of the test, be possible to run on a simple nucleo-503/533 with modifications that can be done in minutes with no tools just moving around the jumpers once. This would make it easier to get started for people.

[astapleton]

I do not know about you, but think there is quite a lot of value in having the vast majority, if not all of the test, be possible to run on a simple nucleo-503/533 with modifications that can be done in minutes with no tools just moving around the jumpers once. This would make it easier to get started for people.

Agreed. The H503 nucleo board is unfortunately very barebones, so there's not much to test against (for e.g. I2C), but you can route the SPI back to itself at least.

[oshaughnessya]

CAN could probably be tested by putting it into loop back mode, sending and then receiving a message.

[usbalbin]

SCK could perhaps be used for SPI to check the frequency, assuming it is set low enough to measure?

[astapleton]

SCK could perhaps be used for SPI to check the frequency, assuming it is set low enough to measure?

With the timer peripheral? Or with a logic analyzer/scope?

[usbalbin]

While a lot better than nothing, I think there are probably quite o lot of errors that might still pass by unnoticed in a loopback test for things like UART. For example stop bits, baud rate etc. Since the errors would likely cancel out if the RX-part has the same error.

Might be a bit overkill and far away but perhaps one could use timer inputs(possibly with DMA) to check the bit pattern of some of the communication peripherals? Or perhaps just the stm32::DWT::cycle_count() in software assuming slow enough baud rate and compare with an expected array of values with some tolerances

[usbalbin]

SCK could perhaps be used for SPI to check the frequency, assuming it is set low enough to measure?

With the timer peripheral? Or with a logic analyzer/scope?

The digital input machinery of a pin is active in all modes except Analog. So the GPIO_IDR register can be checked to see the level of the pin. Done here for the PWM peripheral using stm32::DWT::cycle_count() for the G4 hal.

[oshaughnessya]

While a lot better than nothing, I think there are probably quite o lot of errors that might still pass by unnoticed in a loopback test for things like UART. For example stop bits, baud rate etc. Since the errors would likely cancel out if the RX-part has the same error.

Might be a bit overkill and far away but perhaps one could use timer inputs(possibly with DMA) to check the bit pattern of some of the communication peripherals? Or perhaps just the stm32::DWT::cycle_count() in software assuming slow enough baud rate and compare with an expected array of values with some tolerances

I was thinking about this as well. I personally don't think there is a good way to actually test a lot of these things without external testing equipment. I think unit tests should probably be more simple and along the lines of "it works, probably".

If we want to be more thorough we should probably make little reports using proper test equipment that others can look at

[astapleton]

Might be a bit overkill and far away but perhaps one could use timer inputs(possibly with DMA) to check the bit pattern of some of the communication peripherals? Or perhaps just the stm32::DWT::cycle_count() in software assuming slow enough baud rate and compare with an expected array of values with some tolerances

I think it's overkill. This sounds like essentially implementing a bit-banging protocol to measure the peripheral output. It also assumes that the test is measuring the output correctly, and that the bit patterns it measures against are 100% accurate. There are a number of subtleties in the bit patterns and timing of clock edges that would make this very challenging IMO and it would be very hard to get all these edge cases.

I was thinking about this as well. I personally don't think there is a good way to actually test a lot of these things without external testing equipment. I think unit tests should probably be more simple and along the lines of "it works, probably".

Agreed. And hopefully when users of the crate inevitably discover edge cases or weird behavior with a device we've never heard of, hopefully they can submit bug reports/PRs to address the edge cases.