Hi, I'm using a MCB2100 dev board with LPC2129 chip. I am used to using a 8051 based chip and have used the sbit declaration for pin assignment previously. However it doesn't really like it with my new board. How do I go about reading from an individual pin? thanks Andy
The ARM does not have BITs per se. Take a look at the following example to see how to read and write BITs in an I/O port. http://www.keil.com/download/docs/lpc2100_blinky.zip.asp Jon
Thanks, but how do I read from a specific pin? For example if I was to connect a switch to P0,6 then how would I read from that pin without considering what all the other pin values are on that port? IOPIN0 would equal 0x00000040 when just that pin was high, but what if the other pins were high as well? thanks, andy
sbit is a proprietary extension introduced by Keil specifically to take advantage of a specific architectural feature of the 8051 - it should come as no surprise at all to find that it doesn't work on an ARM!! When it comes to language extensions implemented by a specific compiler, you must always refer to the Manual for that specific compiler. Similarly, you must not assume that any of the C51 implementation-defined details will be the same for the ARM compiler; ie, byte ordering, data type sizes, calling conventions, stack usage, etc, etc, etc,... Now that you're on a 32-bit processor, you must also watch out for data alignment... You can't even assume that this stuff will be the same for the Keil & GNU ARM compilers...
"how do I read from a specific pin?" Strange as it may seem, the 'C' programming language has nothing for manipulating individual bits! The 8051 has some special bit-addressable hardware, so Keil added extensions in C51 to use it; in the absence of such extensions, you will just have to use the standard 'C' techniques of masking with the bitwise operators.
if (IOPIN0 & 0x0000040) tests PIN0.6 for high. It reads also other pins, but the AND mask effectively ignors them.
Thank you all for your replies, think I may need to do I bit more homework than I thought. Cheers, Andy