This morning I was preparing some sample project for FRDM-K22F
which utilizes AnalogIn and PwmOut.
As I have already annoyed with the SPI problem in mbed lib 120
I was not surprised when I saw the values from AnalogIn was screwed.
It seems that the read_us16() actually returning signed 16bit value.
and read() goes with it, and resulting very interesting values.
So I just re-winded the mbed lib to 119 and it resumed working fine.
Following is the read of AnalogIn with a pot attached to FRDM-K22F and
started from 0 to max slowly.
So the values are expected to be starting 0 (0x0000) to 1.0 (0xFFFF).
mbed lib 119
0.000000 0x0000
0.176410 0x2D29
0.316960 0x512D
0.394812 0x6508
0.628733 0xA0EE
0.745464 0xBF08
0.870832 0xDEEB
0.999664 0xFFE9
0.999649 0xFFE9
0.999756 0xFFEE
0.999771 0xFFEC
0.999695 0xFFEA
0.999710 0xFFEC
mbed lib 121
0.000000 0x0000
0.998688 0xFFA8
0.999435 0xFFDA
0.042756 0x0AFD
0.075425 0x134F
0.118608 0x1E5F
0.135149 0x229B
0.180850 0x2E44
0.222110 0x38DF
0.261646 0x4300
0.301335 0x4D17
0.342687 0x57B0
0.388235 0x6362
0.492363 0x7E0B
sigh
moto
This morning I was preparing some sample project for FRDM-K22F
which utilizes AnalogIn and PwmOut.
As I have already annoyed with the SPI problem in mbed lib 120
I was not surprised when I saw the values from AnalogIn was screwed.
It seems that the read_us16() actually returning signed 16bit value.
and read() goes with it, and resulting very interesting values.
So I just re-winded the mbed lib to 119 and it resumed working fine.
Following is the read of AnalogIn with a pot attached to FRDM-K22F and
started from 0 to max slowly.
So the values are expected to be starting 0 (0x0000) to 1.0 (0xFFFF).
sigh
moto