PDA

View Full Version : HERSOUT2 (Weird problem)



Megahertz
- 10th April 2015, 10:50
My baud settings are as follows:

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:



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:


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.

HenrikOlsson
- 10th April 2015, 11:24
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.

Dave
- 10th April 2015, 11:55
This looks like a loop to me...
SYNC:
HSEROUT2 [$AA,$0D,$00,$00,$00,$00]
HSERIN2 1000,SYNC,[COM]

Megahertz
- 10th April 2015, 12:09
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

HenrikOlsson
- 10th April 2015, 13:02
If you know the length of the response, 12 in this case:


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


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

Megahertz
- 10th April 2015, 13:25
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.

rsocor01
- 10th April 2015, 14:52
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.


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



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.

Megahertz
- 10th April 2015, 22:40
ok. I tried to get 512 bytes using string (STR command) and the following statements


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?

rsocor01
- 11th April 2015, 00:47
The maximum number of bytes in an array is 96 according to the manual.

Megahertz
- 11th April 2015, 09:02
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.

pedja089
- 11th April 2015, 11:39
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]

Tabsoft
- 11th April 2015, 21:51
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.



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.

Megahertz
- 12th April 2015, 21:51
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.

Megahertz
- 12th April 2015, 21:53
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?

Tabsoft
- 12th April 2015, 22:31
What PIC are you using?

pedja089
- 13th April 2015, 00:30
Megahertz,
MESS1[256] point to 256 byte in array. So you can receive next 255 characters.

Megahertz
- 15th April 2015, 21:35
Megahertz,
MESS1[256] point to 256 byte in array. So you can receive next 255 characters.

So, can I write it as:

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

Demon
- 15th April 2015, 22:02
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