Hi, I have a simple question. giving that only 0 can be written in bit number 6 and 12to 31, and reading value is undefined. So to set the function value to 0001 I cannot write
IOCON->PIO[0][0]= (IOCON->PIO[0][0] & (~(0b1111))) |0001 .
the reason for that when I read bit number 6 or 12 to 31 there is a chance that on of these bits will return .1 so in this case I write 1 to the bit that returned 1 instead of 0 which is not right. instead I need to have a mask that will always clear bit number 6 and 12 to 31.
ex
IOCON->PIO[0][0]= (IOCON->PIO[0][0] & 0b101110110000)| 0001
in case of type I the mask that will always clear bit 12 to 31. in case of type A the mask will always clear bit 6, 10, 12 to 31.
and giving that each type are different, the mask that will be used to set the Function for the pin will be different based on the pin type D,I, or A.
AM I right?? or should I not put that much concern, that reading bits such as bit 6 in type D can return undefined value(so it could be 1)? thanks very much in advance
Solved! Go to Solution.
> my question what if any of the value we read for pin 6, 12 to 31 was 1(because the reading value is undefined). in this case we wrote 1 in bit 6, or 12 to31. and we should only write zero to theses bits according to data sheet.
> is this a mistake in SDK, or in datasheet? or did I miss something?
Vendor-supplied examples often assume a "sunny-day scenario", i.e. bravely skip most error checking, or ignore such undefined values. Level of testing is often minimal.
Thus, probably more or less "lazy coding".
Hi, I would like to take your opinion @frank_m . Thanks!
I wouldn't speculate. If bits are documented as "reserved", I would avoid writing any other value as specified to them.
Those "registers" are just the interface according to the documented programming model, you don't know what is actually behind it (i.e. on the silicon). Might be just register bits, or but might be peripheral gates that affect the unit immediately.
And, later MCUs might make use of reserved bits, giving you portability issues.
Hi, Thanks for your response and I agree with you. However, in the SDK I saw the following
so pin 1 in GPIO 1 is D typed
so IOCON type D says that reading bit number 6 and 12 to 31 is undefined (could be 0 or 1?).
so the following part of the code will be clearing the bits that is related to func_MASK and DIGIMODE_mask(first four bits and bit number
((IOCON->PIO[1][1] &
/* Mask bits to zero which are setting */
(~(IOCON_PIO_FUNC_MASK | IOCON_PIO_DIGIMODE_MASK)))
after making or with the desired value for FUNC and DIGIMODE this new value will be writing to the
IOCON->PIO[1][1]
which include the read value for pin6, 12 to 31
my question what if any of the value we read for pin 6, 12 to 31 was 1(because the reading value is undefined). in this case we wrote 1 in bit 6, or 12 to31. and we should only write zero to theses bits according to data sheet.
is this a mistake in SDK, or in datasheet? or did I miss something?
Thank you !
> my question what if any of the value we read for pin 6, 12 to 31 was 1(because the reading value is undefined). in this case we wrote 1 in bit 6, or 12 to31. and we should only write zero to theses bits according to data sheet.
> is this a mistake in SDK, or in datasheet? or did I miss something?
Vendor-supplied examples often assume a "sunny-day scenario", i.e. bravely skip most error checking, or ignore such undefined values. Level of testing is often minimal.
Thus, probably more or less "lazy coding".
I see, thank you!