|
|
View previous topic :: View next topic |
Author |
Message |
FreakShow!
Joined: 13 Feb 2012 Posts: 21
|
Data Conversion |
Posted: Wed Mar 14, 2012 8:37 pm |
|
|
Hi,
I've been working on a Pixart Wii IR camera for a project. So far I've managed to pull off data from the camera, which all works.
The data is being saved as bytes from an i2c line. However, the data is a position of the IR that's been seen.
The camera has a max resolution of 1024x768. At the moment though, the bytes are getting a maximum of 0-255 (obviously). I'm trying to do the code into decimal to get the full resolution.
Here's a snippet of code. I've had to translate it from Arduino to CCS, but this is the one issue I've been having. Any help would be great!
Code: | byte out_data[12]; //defining the bytes to read
void readPixArtCam(void) //function to read the data off the camera into the byte array
{
i2c_start();
i2c_write(0xB0); // Device address
i2c_write(0x36); // Data to device
i2c_stop();
delay_us(25);
i2c_start(); // Restart
i2c_write(0xB1); // to change data direction
for(i=0;i<10;i++)
{
out_data[i]=i2c_read();
}
out_data[11]=i2c_read(0);
i2c_stop();
}
void main()
{
initPixArtCam3(); //Initialise the Camera
while(1)
{
readPixArtCam(); //call the reading of the camera function
x1 = out_data[1]; //set the first x point to the first data byte read
s = out_data[3];
x1 += (s & 0x30) <<4; //conversion of code, copied from arduino stuff
puts("x1: ", COM_A); puts(x1); //print out data
|
Data I receive is 0-255. I've shrunk the code down by taking out the 2-4th points, but it's the same type of output. I'd much rather know where these points are across the full 1024 resolution. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Mar 14, 2012 9:26 pm |
|
|
Post links to:
1. The documentation for the i2c slave device (the camera). It should
contain information on the i2c bus protocol used to talk to the device.
2. The source code which you used as the basis for your program above. |
|
|
FreakShow!
Joined: 13 Feb 2012 Posts: 21
|
|
Posted: Wed Mar 14, 2012 10:03 pm |
|
|
Here's a link for the source code I used:
http://procrastineering.blogspot.com/2008/09/working-with-pixart-camera-directly.html
My code is pretty similar to it, apart from some changes to shorten the code (I have that code commented out so can revert back, but same read outs).
Documentation to the IR Camera came from various sources, but includes:
http://www.stephenhobley.com/arduino/PVision.zip
This is a link to a download of the PVision Library, which is the arduino version of the code. This gives out a resolution point, not just the byte data.
I can't see what I've done differently, maybe it's how I'm using the variables and processing them.
I hope that's what you want, but I can answer anything if you don't understand. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
|
FreakShow!
Joined: 13 Feb 2012 Posts: 21
|
|
Posted: Thu Mar 15, 2012 6:46 am |
|
|
I have used that also. The reading the data off the camera isn't the problem, it's how I'm taking that data that has been read in and interpreting it.
The code there stores the data in an array of 12 bytes, which is great. But I can't get the actual resolution data from it.
The 12 bytes are 4 sets of:
x position (0-255)
y position (0-255)
blob size (0-255)
What I want is to be able to get the x position across the full 1024 pixels that the camera has in its width, the y position vertically across 768 pixels.
Not sure how to do this though as whatever I do, try and convert the data into what I want I fail at that bit. The only full set of code (which I know people running it on Arduino get working) is that Arduino code, but I can't see how my code is different to the Pvision library.
EDIT: I've just spotted this little bit of information:
Quote: | The format of the data will be the Extended Mode (X,Y, Y 2-msb, X 2-msb, Size 4-bits) |
How does CCS do this? (Can it?) |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9221 Location: Greensville,Ontario
|
|
Posted: Thu Mar 15, 2012 7:27 am |
|
|
Yes, of course CCS C can do the equal of the Arduino code.....
Your 'program' is not complete and lacking the information as to how the 'raw data' is converted into actual pixel information.
Frankly I have no idea what the heck a 'blob' is though I suspect a good 'googling' will come up with the real 'data format' of the camera.
Surely someone has come up with the info you need, but I don't have the camera and it looks like a simple formula to figure out.
Since both X and Y are less than 65535, they can be represented as an unsigned INT16. |
|
|
FreakShow!
Joined: 13 Feb 2012 Posts: 21
|
|
Posted: Thu Mar 15, 2012 7:29 am |
|
|
Blob size is just the data that tells the PIC how large an IR source it has detected. So if it's a smaller blob, then it's only just about catching the point, it's a weak source, or a large blob is very bright/large (or closer).
I'll try int16 to define it, but as I say I think it's to do with the extended mode thing. |
|
|
FreakShow!
Joined: 13 Feb 2012 Posts: 21
|
|
Posted: Thu Mar 15, 2012 11:50 am |
|
|
Tried int16 and no go.
But thought more about what that snippet above means and think it means this:
For one point, 3 bytes of data are sent. This is split up into the following format:
1st byte - LSBs of X co-ord
2nd Byte - LSBs of Y co-ord
3rd byte - 2bits MSB of Y, 2bits MSB of X, 4 bits blob size.
So to get the correct X co-ordinate, I need to take the 1st byte, convert it into something at least 10bits large, shift the bits to the end and then insert the 3rd and 4th bits of the 3rd byte into the start 2 bits of the X co-ord.
Following so far?
This is what I think I am doing wrong. The code I'm applying to do that is:
Code: | x2 = out_data[3];
y2 = out_data[4];
s = out_data[5];
x2 += (s & 0x30) <<4;
y2 += (s & 0xC0) <<2; |
But that was copied from the Arduino and it may not work the same in PIC. I just can't see past this error. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Mar 15, 2012 12:26 pm |
|
|
In your code above, you are using different indexes into the array
compared to what's shown in this sample code:
http://www.stephenhobley.com/arduino/PVision.zip
In Pvision.cpp, for Blob1, they that 's' comes from array index 3:
Code: |
Blob1.X = data_buf[1];
Blob1.Y = data_buf[2];
s = data_buf[3];
Blob1.X += (s & 0x30) <<4;
Blob1.Y += (s & 0xC0) <<2;
Blob1.Size = (s & 0x0F);
|
Where are you getting the idea that 's' should be loaded from index 5 ?
Also, how are you declaring x2, y2, and s in your code ? In CCS they
need to be int16. I'm assuming everything is unsigned. I didn't check
that. |
|
|
FreakShow!
Joined: 13 Feb 2012 Posts: 21
|
|
Posted: Thu Mar 15, 2012 1:15 pm |
|
|
In the code I gave, s comes from 5, because that is the second point, should have just given the first.
The 12 bytes start from 0 and go up to 11.
Therefore:
x1 - array 0
y1 - array 1
s1 - array 2
x2 - array 3
y2 - array 4
s2 - array 5
etc etc. And S1 is split up in the way I showed above.
Does the LSB or the MSB come first when CCS reads in I2C data?
EDIT: Sorry, forgot to mention that they are declared as integers. The final number only needs to be 10-bits. So I don't think it needs int16 (unless I missed something?) |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Mar 15, 2012 1:27 pm |
|
|
Post your declarations.
In CCS, an 'int' is an unsigned 8-bit integer. |
|
|
FreakShow!
Joined: 13 Feb 2012 Posts: 21
|
|
Posted: Thu Mar 15, 2012 1:40 pm |
|
|
Code: | int out_data[12];
int i;
int x1, x2, x3, x4;
int y1, y2, y3, y4;
int s, s2, s3, s4;
int result;
|
Those are my declarations. So that explains why I need int16 then. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9221 Location: Greensville,Ontario
|
|
Posted: Thu Mar 15, 2012 2:16 pm |
|
|
I've always found graph paper to be real helpful in this kind of situation,especially where bits of several bytes 'merge' with other bytes to form the final 'real' value.
If you could have a couple 'reference ' or known test values , it's a lot easier to get the 'math' correct.
I can stare at equations all day and not 'see' what's happening, but on paper ..the lightbulb usually comes on fast. |
|
|
FreakShow!
Joined: 13 Feb 2012 Posts: 21
|
|
Posted: Thu Mar 15, 2012 2:29 pm |
|
|
Well, I've created a new project, so as to clear out all the bits of code I've tried here and there. So I'm focusing on one point only, initialising the camera and reading it.
I started off trying the same code before on interpreting the code so:
Code: |
int16 result;
int16 x1;
while(1)
{
puts("start", COM_A);
readCamera();
x1 = data_in[0];
x1 += (data_in[2] & 0x30) <<4;
printf("%Ld",x1);
delay_ms(1000);
}
|
This produces the same "255" value.
If I now do this instead:
Code: |
void bit_testing()
{
if(bit_test(data_in[0],0)) bit_set (result, 0);
if(bit_test(data_in[0],1)) bit_set (result, 1);
if(bit_test(data_in[0],2)) bit_set (result, 2);
if(bit_test(data_in[0],3)) bit_set (result, 3);
if(bit_test(data_in[0],4)) bit_set (result, 4);
if(bit_test(data_in[0],5)) bit_set (result, 5);
if(bit_test(data_in[0],6)) bit_set (result, 6);
if(bit_test(data_in[0],7)) bit_set (result, 7);
if(bit_test(data_in[2],2)) bit_set (result, 8);
if(bit_test(data_in[2],3)) bit_set (result, 9);
printf("result: %Ld",result);
}
|
Then I get the result of 1023! Which looks great, except IRs right in front of the camera don't change this number. Which I don't understand. I even tried changing the order of the bits, in case it was being read in LSB first, but still no joy :\ |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Mar 15, 2012 2:32 pm |
|
|
You need to set 'result' to 0 at the start of your bit testing routine. |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|