 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Arizona Chris
Joined: 20 Dec 2014
Posts: 69
Location: Arizona
|
| Perplexing Serial comm issue with Pixy Cam |
 Posted: Thu Apr 27, 2017 9:30 pm |
 |
|
Hi all,
I rarely visit this discussion forum because I have not had too many issues with CCS C. (I do post lots of stuff on the Library).
This one has me beating my head against the wall for days now, and I REALLY could use some help on here. I am interfacing a PIXY camera using the UART serial at 19200 baud to my PIC16F887, and am using the getc() or more typically fgetc() to bring in the bytes from the camera to read out the data. Normally no big problem, I've done it hundreds of times in PIC to PIC communication in our robots and with other serial equipment. But here's what happens with the pixy, I can turn on the pixy and processor together, and after warm up period of a few seconds can read the pixy data stream serially just fine - as long as I don't stop reading it, go do something else longer than say 1 - 5 ms. When I go back to read more data, the processor locks up every time on the first fgetc() and never recovers. It's like it can't reacquire the data stream! Yet I can look with a scope and see it still running into the chip.
This one is big mystery to me, reading continuously works fine, until I go do something like send a message to the LCD or put a delay of say 250ms in the program. Then when I try to get back to data - that's all she wrote.
I went ahead and wrote a VERY simple program to test this and get the same problem when ready pixy data. I have tried a faster crystal (20mhz), changing the baud rate to slower, (9600) changing the baud on the USE232 command a few percent each way, and its always the same. What could cause this? Is there any way to see why it is getting stuck in getc when I return to it after while?
This is the test program. pretty simple, but I could not put any longer than a few ms in the delay without locking it up on getc. any ideas?
| Code: | //****************************************************************************
//Chris Schur
//(LED FLASH 1 16F887)
//Date: 10/30/15
//****************************************************************************
/*Description of this Program:
This version 1 - First test of 887 chip, test receive of serial data from
pixy. */
//I/O Designations ---------------------------------------------------
// RA0: (AN0)
// RA1: (AN1)
// RA2: (AN2)
// RA3: (AN3)
// RA4: (Open Collector output)
// RA5: (AN4)
// RA6: OSC OUT
// RA7: OSC IN
// RB0: (AN12,EXT INT) Status LED output
// RB1: (AN10) New Haven LCD output
// RB2: Serial Audio Output
// RB3: GREEN LED
// RB4: SERVO1 OUTPUT
// RB5: SERVO2 OUTPUT
// RB6:
// RB7:
// RC0:
// RC1:
// RC2:
// RC3:
// RC4:
// RC5:
// RC6: TX serial to PIXY
// RC7: RX serial from PIXY
// RD0:
// RD1:
// RD2:
// RD3:
// RD4:
// RD5:
// RD6:
// RD7:
// RE0: (AN5)
// RE1: (AN6)
// RE2: (AN7)
// RE3: (MCLR INPUT - Pull High)
//--------------------------------------------------------------------
//Include Files:
#include <16F887.h> //Normally chip, math, etc. used is here.
//Directives and Defines:
//#device ADC=10 //Set ADC when used to 10 bit = 0 - 1023
#fuses NOPROTECT,HS,NOWDT //xtal is used
#use delay(crystal=20MHz) //xtal speed
#use fast_io(ALL) //must define tris below in main when using this
#define LED (Pin_B0) //Status LED
//for PIXY TX, RX:
#use rs232(baud=19200, UART1, bits=8, parity=N)
//NO_ANALOGS is default in device file...(All I/Os are digital)
//Interrupts:
//***Global Variables:********************************************************
//test stuff
int16 w;
int8 c;
//***Functions/Subroutines, Prototypes:***************************************
//****************************************************************************
//***-- Main Program*********************************************************
void main(void) {
// Set TRIS I/O directions, define analog inputs, comparators:
set_tris_A(0b10111111);
set_tris_B(0b11000000);
set_tris_C(0b10111111);
set_tris_D(0b11111111);
set_tris_E(0b1111);
//Initialize variables and Outputs: --------------------------------------
//Setup for timers, PWM, and other peripherals:
//----------------------------------------------------------------
//Main Program
while (true) {
c=getc();
w=getc();
output_toggle LED;
delay_ms(5);
} //while
} //main
//********* Functions which have prototypes at top of program ****************
|
|
|
 |
diode_blade
Joined: 18 Aug 2014
Posts: 55
Location: Sheffield, South Yorkshire
|
|
| Posted: Thu Apr 27, 2017 10:12 pm |
|
|
Hi Chris,
don't know if this could help but what about using a on board timer for the delay routine instead of delay_ms just to see if the same thing happens, if you have not already done that.
regards
Dave
edit
or perhaps using gets()
Last edited by diode_blade on Thu Apr 27, 2017 10:16 pm; edited 1 time in total |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Apr 27, 2017 10:14 pm |
|
|
Add ERRORS to your #use rs232() statement. Add a serial receive
buffer, as shown in the CCS example file Ex_Sisr.c. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9243
Location: Greensville,Ontario
|
|
| Posted: Fri Apr 28, 2017 4:42 am |
|
|
I have to '2nd' PCM P. You NEED to add 'ERRORS' and use an ISR driven buffer. Withou 'ERRORS' the PIC HW UART will 'lockup' after 2-3 characters. Using an ISR driven buffer ,allows the PIC to do 'other things' not just wait for serial data...
I know the CCS supplied example ex_sisr.c does work, and there is a tweak posted here. I' use a variation of it with the 46k22, 2 HW UARS running at 115k200 with zero problems.
Jay |
|
|
Arizona Chris
Joined: 20 Dec 2014
Posts: 69
Location: Arizona
|
| Perplexing Serial comm issue with Pixy Cam |
| Posted: Fri Apr 28, 2017 9:25 am |
|
|
Jay and PCM, by adding "ERRORS" to the USE232 directive, it doesn't lock up for short bursts of data now, but long continuous runs of data it lasts a few seconds then returns only zeros.
Do you think if I don't use the UART, and just two other pins and "big bang" It would not do this?
Chris |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Fri Apr 28, 2017 10:10 am |
|
|
SUMMARY:
1- never use bitbang RS-232 if you can possibly use hardware UART
2- i have never had character loss using hardware uart PLUS cirular INT handler for the port
3- YOU MUST USE ERRORS option in RS232 setup or you will always have the kind of problem you describe.
if you have done all that and still can't make it fly-- something must be wrong in hardware |
|
|
Arizona Chris
Joined: 20 Dec 2014
Posts: 69
Location: Arizona
|
| Perplexing Serial comm issue with Pixy Cam |
| Posted: Fri Apr 28, 2017 11:48 am |
|
|
Thanks for your input asmboy, although I have done a lot of serial work over the years with camera systems at work, they only require short bursts of 232 data intermittently to do their thing. Most of the (admittedly ancient) PICs we use don't have any UARTs. This home robotics project will be good for me to get a good handle on using the UARTS to their full advantage. So far - definitely a learning experience!
I'll go try the ISR method as well, it may work better for this application. The data stream of the PIXY camera (robotics vision) is very peculiar in that it puts out zeros for no objects in the field, or a few bytes of zero followed by sync bits followed by data if there is a colored object present. So you have to search for the sync words, then get the data. (but ignore the leading zeros).
Thanks again for your advice, I'm sure this project will enhance my smartness when its all done....
Chris |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19540
|
|
| Posted: Sun Apr 30, 2017 1:32 pm |
|
|
The PIC UART has the property that it will go into an error state (and effectively disable itself...), if data arrives and is not read. Since the camera sends continuous data, and you stop reading, this will happen.
ERRORS adds code to the UART handler to recover from this error. However you will receive two characters of the zeros (since these will be in the hardware buffer).
What tells you to start reading from the camera again?.
If there is a signal, then consider disabling the UART when it is not being used:
| Code: |
#use rs232(baud=0, UART1, bits=8, parity=N, NOINIT, ERRORS)
//This sets the UART up, but does not initialise it.
/?then when you want to use the UART
setup_uart(19200); //enable the UART at 19200bps
//Then to disable the UART
setup_uart(FALSE); //turns the UART off
|
Using these commands you can enable and disable the UART when you are going to use it, or want it to ignore data.
Generally, you _must _ always use 'ERRORS' on a hardware UART, unless you are adding your own code to handle the possible error conditions. |
|
|
Arizona Chris
Joined: 20 Dec 2014
Posts: 69
Location: Arizona
|
| Perplexing Serial comm issue with Pixy Cam |
| Posted: Sun Apr 30, 2017 4:56 pm |
|
|
Thanks again for more very helpful advice. This is an idea I will try as well. The camera sends 50 frames per second, and in each frame - if there is any thing in the field that has the color (red in this case) then it will insert a block of data. The data block is preceded by a sync code of 0xaa55 twice in a row which says data is coming. So what you have to do is when you want to grab a chunk of data to read out what is being seen by the camera (asynchronously of course!) you start getting data, and look for the double sync word. THEN you grab like hell the next 6 words of data. Then jump out and your processor then would react to the data. The problem is when you jump in and grab data from the stream, you never quite know where you are in the data stream!
I've got the data reading out fine now, and as long as I don't try to read it too fast, it behaves itself.
chris |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19540
|
|
| Posted: Mon May 01, 2017 4:33 am |
|
|
A potential problem I can see, is if you leave the serial enabled, and stop listening to the data, then a couple of characters later the UART will overflow and 'error'. Now when you next go and start reading again, this error will be cleared, and reception will carry on, but the two characters you get from the hardware buffer, will be those when it went into the error state. These might be the start of frame markers you are looking for, so you could get the situation that you think you are at the start of the frame, when you are not...
Solutions:
1) Disable the UART as shown.
or
2) When you start listening again, ignore the first couple of characters. |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
