HERSOUT2 (Weird problem)

My baud settings are as follows:

Code:

---

DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 20h ' Enable transmit, BRGH = 0
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
DEFINE HSER_BAUD 9600
DEFINE HSER_SPBRG  51 ' 9600 Baud
BAUDCON.3 = 1        ' Enable 16 bit baudrate generator
DEFINE HSER2_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER2_TXSTA 20h ' Enable transmit, BRGH = 0
DEFINE HSER2_CLROERR 1 ' Clear overflow automatically
DEFINE HSER2_BAUD 14400

---

my code is as follows:

Code:

---

com var byte[12]

GETPIC:
                PAUSE 3000
                COM=0
                GOSUB SYNC
GOTO GETPIC
; UART2 IS CONNECTED TO THE CAMERA (www.4dsystems.com.au/downloads/micro-CAM/Docs/uCAM-DS-rev7.pdf)
; UART1 IS CONNECTED TO MY PC
SYNC:
                HSEROUT2 [$AA,$0D,$00,$00,$00,$00]
                HSERIN2        1000,SYNC,[COM]
                HSEROUT [$AA,$0D,$00,$00,$00,$00]' this statement and the ones below should not execute
                HSEROUT        [COM,13,10]
                HSEROUT2 [$AA,$0E,$0D,$00,$00,$00]
        GOTO GETPIC
RETURN

---

I should not get any response on my PC as I have removed my MAX232 and there is no way the data can go to the camera. But I get the following:

Code:

---

AA 0D 00 00 00 AA 0D 0A

---

why is com getting loaded with AA 0D 0A and then after a few loops of the same, it changes.

Hi,
I guess a schematic of your setup would help, at least for me. But I guess that when you "remove" the MAX232 (provided it's located between the PIC and the camera (you DO have the RS232 version of the camera and not the TTL version, right?) the USART input on the PIC is floating, tricking the HSERIN2 statement into believing it's actually received something so the execution falls thru to the HSEROUT statement

Another thing that sticks out is you have COM declared as an array of 12 bytes and the response from the camera response to a SYNC is, as far as I can see, 6+6 bytes but you're only grabbing the first one with your HSERIN2 statement. Then it all starts over and there may be a residual byte in the USART buffer.

/Henrik.

This looks like a loop to me...
SYNC:
HSEROUT2 [$AA,$0D,$00,$00,$00,$00]
HSERIN2 1000,SYNC,[COM]

Quote:

---

Originally Posted by HenrikOlsson

Hi,
I guess a schematic of your setup would help, at least for me. But I guess that when you "remove" the MAX232 (provided it's located between the PIC and the camera (you DO have the RS232 version of the camera and not the TTL version, right?) the USART input on the PIC is floating, tricking the HSERIN2 statement into believing it's actually received something so the execution falls thru to the HSEROUT statement

Another thing that sticks out is you have COM declared as an array of 12 bytes and the response from the camera response to a SYNC is, as far as I can see, 6+6 bytes but you're only grabbing the first one with your HSERIN2 statement. Then it all starts over and there may be a residual byte in the USART buffer.

/Henrik.

---

Ok, lets start solving the puzzle.

1) The camera is RS232 type
2) USART was floating. I tied it high and no reply back now - this problem is solved (cheers for that)

secondly can you suggest on how do I get these 12 bytes if HEX8 is the highest I can use

If you know the length of the response, 12 in this case:

Code:

---

HSERIN2 1000,SYNC,[COM\12]

---

Since the normal response packet (except image data) seems to be 6 bytes and the camera response to a SYNC is an ACK (6 bytes) and a SYNC (6 bytes) I'd probably do it in two steps

Code:

---

COM1 VAR BYTE[6]
COM2 VAR BYTE[6]
HSERIN2 1000,SYNC,[COM1\6]
HSERIN2 1000,SYNC,[COM2\6]

---

Quote:

---

Originally Posted by HenrikOlsson

If you know the length of the response, 12 in this case:

HSERIN2 1000,SYNC,[COM\12]
[

---

Not quiet sure about this. Doesn't seem to be valid.
I have instead declared 12 different variables and trying to get the response in them...i.e. - HSERIN 500,SYNC,[COM,ID,P1,P2,P3.....]

But it does not work, must be something with the baud, any idea what is the MAX baud we can do with 8MHz osc. I will appreciate if you can show as to how you can calculate it.

Quote:

---

Originally Posted by Megahertz

Not quiet sure about this. Doesn't seem to be valid.

---

The following text is taken from the manual. You will probably need to include the STR modifier.

Quote:

---

STR ArrayVar\n{\c}
Receive string of n characters optionally ended in character c

---

Quote:

---

Originally Posted by Megahertz

must be something with the baud, any idea what is the MAX baud we can do with 8MHz osc.

---

Since you are dealing with HSEROUT2 (Hardware), my guess is that the answer to your question will be in the PIC datasheet.

ok. I tried to get 512 bytes using string (STR command) and the following statements

Code:

---

MESS1 VAR BYTE[512]

HSERIN2 [STR MESS1\512]

---

The data seems to be getting corrupted as I believe some bytes arriving in HEX format don't add up in a sensible way in string format. Like $00 will be considered as null. Is there any idea as to how to get them in HEX format?

The maximum number of bytes in an array is 96 according to the manual.

Quote:

---

Originally Posted by rsocor01

The maximum number of bytes in an array is 96 according to the manual.

---

It is irrelevant now as I need to find a way to get it in hex until there is a way to convert it back.
I can create byte[90] and do it that way.

When using STR, maximum number of bytes is 255. It is only one byte counter.
Darrel already give simple workaround:
HSERIN2 [STR MESS1\255, STR MESS1[256]\255]

After reading your posts and having a look at the camera datasheet, I would look at a couple of things.

First, if you are still trying to communicate to the camera at 14400 and your PIC OSC frequency is 8MHz, then I would set the following parameters.

For the second EUSART port, set the following register bits manually:
SYNC = 0
BRGH = 1
BRG16 = 1
SPBRGH = 0
SPBRG = 137

This will setup 14400 with a resultant 0.64% error rate. This is as good as you can get at 8MHz.

Secondly, looking at the camera datasheet, the communication between the PIC and camera is NOT sending "ascii" Hex characters, it is binary data.
So that being said, you should not use Input/Output modifiers (I.e. HEX/BIN/DEC) with the HSERIN2/HSEROUT2 commands to/from the camera.

I would try the following for testing purposes.
This assumes that the PC is connected to the 1st HSER port of the PIC for debug purposes and the PC is running a terminal emulator program.

Code:

---

com var byte[12]
i var byte


GETPIC:
                PAUSE 3000
                COM=0
                GOSUB SYNC
GOTO GETPIC
; UART2 IS CONNECTED TO THE CAMERA (www.4dsystems.com.au/downloads/micro-CAM/Docs/uCAM-DS-rev7.pdf)
; UART1 IS CONNECTED TO MY PC
SYNC:
                HSEROUT2 [$AA,$0D,$00,$00,$00,$00]  'TX SYNC
                for i = 0 to 11
                    HSERIN2        1000,SYNC,[COM(i)]      'Rx ACK & SYNC pattern (2 x 6 bytes)
                next i
                HSEROUT2 [$AA,$0E,$0D,$00,$00,$00]  'TX ACK
               
                for i = 0 to 11    'Tx 12 bytes to PC for display           
                    HSEROUT [hex2 COM(i)]  'hex2 sends the data as "ascii" codes representing HEX digits
                    HSEROUT [13,10]
                next i
               
        GOTO GETPIC
RETURN

---

This should:
1. Send the 6byte SYNC pattern to the camera.
2. Receive the 6byte ACK pattern response from the camera.
3. Receive the 6byte SYNC pattern response from the camera.
4. Send the 6byte ACK pattern to the camera.

5. Transmit out "ascii" character representations of the binary data stored in the COM byte array to the PC to be displayed in a terminal emulation program.

Code:

---

                for i = 0 to 11
                    HSERIN2        1000,SYNC,[COM(i)]      'Rx ACK & SYNC pattern (2 x 6 bytes)
                next i

---

This looks like a solution as to get 512 bytes I can just do 'for i=0 to 511'.

Thanks for the info. Just wanted to confirm if the above is a good way to get continues data. I can communicate with the camera up to getting a snapshot. It all works fine up to there.

Now, I am figuring a way to get the 512 bytes of picture data. Has anyone tried the above without any loss of data (as I am thinking the loop may cause a slight delay and data might be lost in that). Just wanted to check if the above method has been tried by someone before.

Quote:

---

Originally Posted by pedja089

When using STR, maximum number of bytes is 255. It is only one byte counter.
Darrel already give simple workaround:
HSERIN2 [STR MESS1\255, STR MESS1[256]\255]

---

Thanks for the detail. What does this (bold highlighted) code do?

What PIC are you using?

Megahertz,
MESS1[256] point to 256 byte in array. So you can receive next 255 characters.

Quote:

---

Originally Posted by pedja089

Megahertz,
MESS1[256] point to 256 byte in array. So you can receive next 255 characters.

---

So, can I write it as:

Code:

---

HSERIN2 [STR MESS1[0]\255, STR MESS1[256]\255]

---

Secondly, what will happen when it receives a $00 byte? and how do I convert this received data (512 bytes) back to hex format

http://www.picbasic.co.uk/forum/showthread.php?t=272

Data is stored in binary format. How you display or transmit is up to you.

Robert