first two set the rx/tx pins. this pic has two sets. the third is interrupt edge selection... shouldnt affect usart
|
Re: Serin -> Hserout -> Hserin -> LCDOUT
first two set the rx/tx pins. this pic has two sets. the third is interrupt edge selection... shouldnt affect usart
|
Re: Serin -> Hserout -> Hserin -> LCDOUT
Yes there are two eusart one on PortB5/7 and one on PortC4/5. A bit more of your codeOriginally Posted by thasatelliteguy
shows you have RX on Portc.6 and that Portc.5 which is the RX pin is the var WEST. Unless I have read the wrong datasheet.Code:stowlight var byte stowlight = 1 TRISC.6 = 1 DOWN var PORTC.1 TRISC.1 = 0 DOWN = 0 EAST var PORTC.2 TRISC.2 = 0 EAST = 0 WEST var PORTC.5 TRISC.5 = 0 WEST = 0 UP var PORTC.0 TRISC.0 = 0 UP = 0 RX var PORTC.6 TRISC.6 = 1
Steve Earl www.datageo.co.uk
|
Re: Serin -> Hserout -> Hserin -> LCDOUT
After some more thinking time #4 code uses serin not Hserin. Could we see the code using Hserin please?
Steve Earl www.datageo.co.uk
|
Re: Serin -> Hserout -> Hserin -> LCDOUT
Ive tried it hundreds of ways. It just doesn't work. Or rather, it works fine, but it will not acknowledge input from my terminal on my PC
Code:' Name : HSERX.pbp ' Compiler : PICBASIC PRO Compiler 2.6 ' Assembler : PM or MPASM ' Target PIC : 40-pin 16F877A, 18F452 or similar ' Hardware : LAB-X1 Experimenter Board ' Oscillator : 4MHz external crystal ' Keywords : HSERIN, HSEROUT, LCDOUT ' Description : PICBASIC PRO to send and receive from the hardware ' serial port. ' ' Define LOADER_USED to allow use of the boot loader. ' This will not affect normal program operation. Define LOADER_USED 1 DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1 DEFINE HSER_SPBRG 77 ' 9600 Baud @ 20MHz, 0.16% DEFINE HSER_CLROERR 1 ' Clear overflow automatically APFCON0.2 = 1 'TX Pin Select - 0 = Pin B7 1 = Pin C4 APFCON0.7 = 1 'RX Pin Select - 0 = Pin B5 1 = Pin C5 OPTION_REG.6 = 1 #CONFIG __config _CONFIG1, _FOSC_HS & _WDTE_OFF & _PWRTE_OFF & _MCLRE_ON & _CP_OFF & _CPD_OFF & _BOREN_OFF & _CLKOUTEN_OFF & _IESO_OFF __config _CONFIG2, _PLLEN_OFF & _LVP_OFF #ENDCONFIG DEFINE OSC 8 ANSELA = 0 ANSELB = 0 ANSELC = 0 DEFINE LCD_DREG PORTB DEFINE LCD_DBIT 4 DEFINE LCD_RSREG PORTA DEFINE LCD_RSBIT 0 DEFINE LCD_EREG PORTA DEFINE LCD_EBIT 1 DEFINE LCD_BITS 4 DEFINE LCD_LINES 2 DEFINE LCD_COMMANDUS 1500 DEFINE LCD_DATAUS 44 LED var PORTC.7 high LED char Var word ' Storage for serial character col Var Byte ' Keypad column row Var Byte ' Keypad row key Var Byte ' Key value lastkey Var Byte ' Last key storage bklt var PORTC.7 TRISC.7 = 0 bklt = 1 ADCON1 = 7 ' Set PORTA and PORTE to digital Pause 500 ' Wait for LCD to startup OPTION_REG.7 = 0 ' Enable PORTB pullups key = 0 ' Initialize vars lastkey = 0 Lcdout $fe, 1 ' Initialize and clear LCD display lcdout $FE, $01, "LCD IS WORKING" lcdout $FE, $C0, "LINE 2 WORKS 2" pause 5000 LCdout $FE, $01 mainloop: Lcdout $FE, $01, "..." lcdout dec char ' Send char to display Hserin [char] ' Get a char from serial port Goto mainloop ' Do it all over again End
Last edited by thasatelliteguy; - 26th June 2014 at 20:28.
|
Re: Serin -> Hserout -> Hserin -> LCDOUT
Hello Mr. thasatelliteguy,
Make the variable "char" a byte instead of a word. Seriously, give that a try...
Best Regards,
Paul
The way to avoid mistakes is to gain experience. The way to gain experience is to make mistakes.
|
Re: Serin -> Hserout -> Hserin -> LCDOUT
it started out that way. didn't work either. Also I need word-sized numbers to pass
|
Re: Serin -> Hserout -> Hserin -> LCDOUT
The hardware serial port will only deal with individual bytes. Whatever else is or is not going on, you cannot read directly into a word variable in that manner. You could use. I rarely use LCDs so I have no idea what the implications of using a word in writing to one.Code:Hserin [char.byte0]
You are correct in that the hardware serial port sounds right for your application. You have a two-byte buffer that will happily receive data in the background while the PIC is busy doing other stuff. At your leisure you can test the flag for when the buffer has data in it ("If PIR1.5 = 1 then...") and grab it when you can.
Ahh. Are you using a MAX232 type of level shifter, or have otherwise taken into account the the hardware port cannot invert the data like serin can?but I cannot get hserin to respond, except from another pic
For a test, I'd try writing "DEC char" to your LCD. See if maybe you are getting the reversed bits, although I'm not sure what effect this would have on the start/stop bits. Nothing good I'm sure! Neglecting that, "k" would show up as 107 but if it were inverted it would be 148 instead.
Just to make sure, you've confirmed that data is actually getting received by the port, it just appears garbled, right?
Although I've never used the PIC16f1829 specifically, I use the hardware port a *lot*. There is no reason it shouldn't work. A 50Hz signal will only interrupt about every 20 msec, an eternity in electronics terms. Handling a single byte shouldn't necessitate an additional PIC.
I understand your frustration, and apologize if I've mentioned items that have already been covered. However, I keep having to learn over and over again to (1) check *everything* and (2) make no assumptions.
Best Regards,
Paul
The way to avoid mistakes is to gain experience. The way to gain experience is to make mistakes.
|
Re: Serin -> Hserout -> Hserin -> LCDOUT
There are a few anomalies in this code
1 You are using a boot loader and using config.
2 There are different OSC mentioned 4, 8 and 20.
3 ' Target PIC : 40-pin 16F877A, 18F452 or similar do not have two usart ports and the code selects the second.
4 Char is a word your PC running hyperterminal or similar will send byte sized ASCII codes.
All this makes it difficult to identify the cause of your issues that have been going on for months as you say.
Steve Earl www.datageo.co.uk
|
Re: Serin -> Hserout -> Hserin -> LCDOUT
I (think) have had a EUREKA moment! Look, my problem in a nutshell is that I cannot get serin data thru to my pic while hard interrupts are firing at 50hz. This means I can't get the data thru to tell my dish to stop. And I cannot prioritize the serial data over the interrupts because it'll miss pulses and get lost. Hserin/Hserout seems much better but I cannot get hserin to respond, except from another pic. I did not, however, have this problem when it was all in one piece and I was sending button presses as commands instead of data streams. Even with fast interrupts going, it'll still realize a pin has gone high, and respond accordingly. So... since I was going to add a low-end pic like 628A to sit around and wait for serin commands and send out hserout commands to the main pic anyway, I'm just going to have it send simulated button presses instead. I'll run the TX from the BT to the 628A, and it'll sit around waiting for serial data from the handheld in a serin command, and I'll run the RX from the BT straight to the 1829, so that the handheld can receive responses and confirmations via hserout commands. Then I'll program the 1829 just as if I had physical buttons hooked up to control it, but it will in fact be the 628A "pressing the buttons". Since my handheld device only has 4 buttons on it anyway, it'll even be fairly easy to program and keep it straight in my head because the 1st pic is simply going to receive "A" "B" "C" or "D" (via serin) from the pic in the handheld (probably another 628A) and forward a "button press" to the 1829. Since the 628A will have no other task in life, it should be ultra-reliable.
Any input on this idea?
So far I think this'll be my best bet to get the "walking" and "gum chewing" without the "crashing into S***".....
Members who have read this thread : 1You do not have permission to view the list of names.
Posting Permissions
Bookmarks