angelo mottolese

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

8 years ago.

Constructing a byte using PortIn??

Weird! Using 

PortIn(Port0,0x7878000)

, which is

 (p13,p14,p12,p11,p15,p16,p17,p18)

, I read the portIn value. I am extremely confused about the bit order of the received byte. Using this code to print every bit: 

pc.printf(..., s,s&0x80,s&0x40,s&0x20,s&0x10,s&0x8,s&0x4,s&0x2,s&0x1)

, I see that, when each pin input is HIGH, the value of the bits is:

 (8,4,2,1,256,512,1024,2048)

What is the correct order to read one byte from PortIn?

PS I' ve found a function to read a byte from PortIn, but seems not to work and is even more confusing:

 int top = s >> 19;         // Isolate the top nibble
        int middle = s >> 2;       // Isolate bits 2 & 3
        s = s & 0x00000003;   // Isolate bits 0 & 1      
        s += middle;
        s += top;

So what the hell is going on here? THANKS everybody!!

1 Answer

Erik -
8 years ago.

The order depends on the order those pins are in the port they are grouped in. In general PortIn is only used if it really needs to be fast, otherwise BusIn is alot easier to use.

Btw are your printf statement and result really what you get? Since something & 0x01 should never be 2048.

I want ot read a byte stream from a camera so yes, i have to be very fast. Yes it is what I get, that' s why i don' t understand! Do you have any clues?

posted by angelo mottolese 17 Nov 2016

Which value does the PortIn get when you just print the value of the PortIn with everything high? (and everything low).

posted by Erik - 17 Nov 2016

(tomorrow i' ll reply to your question. Don' t have the values now, but I tried already, and I get very high numbers.) It turns out that the magic formula is <<code>>(((data&0x07800000)>>19)|((data&0x078000)>>15));<</code>>where data is the pointer to PortIn.read(). I found this in the code for my same camera written by Edoardo De Marchi. I get -almost- correct image data (I decode RGB565 data, but green is wrong! Mah!) So now I wonder what' s the logic behind this?

posted by angelo mottolese 17 Nov 2016