SERIN2 = ok, HSERIN = no!

[Archangel]

I Think HSERIN only speaks TRUE and likes a nice pull up resistor, just to keep it honest. The max232 would invert it, NO?

[Ioannis]

Some PIC have the option to select true or inverted.

Ioannis

[Archangel]

Some PIC have the option to select true or inverted.

Ioannis

Don't know what I saw, I thought he was working with a 16F628 . . . still I did not know this anyway. Thanks to you and Walter.

[flotulopex]

Yup! Adding "DEFINE HSER_CLROERR 1" has solved the "hanging" problem.

As I previously set the RCSTA.1 = 1, I wrongly thought this would handle the automatic overrun. I should have noticed the "Read-Only" flag on this bit in the datasheet.

BTW, what exactly does "DEFINE HSER_CLROERR" 1 do? Where can I find information about what other DEFINE commands do?

NB: my apologise Demon; I missed your advice for a pull-up in an early post

Final working code is HSERIN-EUART-test_18F2420.zip

[Archangel]

Yup! Adding "DEFINE HSER_CLROERR 1" has solved the "hanging" problem.

As I previously set the RCSTA.1 = 1, I wrongly thought this would handle the automatic overrun. I should have noticed the "Read-Only" flag on this bit in the datasheet.

BTW, what exactly does "DEFINE HSER_CLROERR" 1 do? Where can I find information about what other DEFINE commands do?

NB: my apologise Demon; I missed your advice for a pull-up in an early post

Final working code is Attachment 6366

From the book "As the hardware buffer only has 2 byte input buffer, it can easily overflow if charactors are not read from it often enough. When this happens, the USART stops accepting new characters and needs to be reset. This error can be reset by toggling the CREN bit in the RCSTA register. A DEFINE can be used to automatically clear this error. However you will not know that an error has occured and characters may have been lost."

[Demon]

...However you will not know that an error has occured and characters may have been lost.

Ah, and this must be where a checksum comes it to play?

Robert

[flotulopex]

...Where can I find information about what other DEFINE commands do?

Can someone please tell?

[HenrikOlsson]

Believe it or not but they are actually listed in the manual. I know - who would've thought... ;-)
In my 2.60 book they are in Appendix B and in the PBP3 book they are in section 8.7

And, DEFINE is not a command in that it does not execute at runtime. It's a compiler directive that tells the compiler how and what code to generate. This means that you can not use DEFINE to change a setting (like for example the parity for the USART) at runtime.

/Henrik.

[flotulopex]

Thanks ;-)

[flotulopex]

Based on the code in post #12, I removed the WAIT modifier to be able to see what happens on each try (= display anything data that comes into the PIC): HSERIN[STR GPS_D\6].

...and likes a nice pull up resistor...

I removed the MAX232, added a 10k pull-up on PORTC.7 (PIC's RX pin) and changed BAUDCON to % 01001000 (not inverted). It works now!!!


I re-modified the code to: HSERIN [WAIT("$GPGGA,"),STR GPS_D\6]

I now can see "HH:MM:SS" as it should.

Nevertheless, I have my PIC running for more than an hour now and it often hangs (= time is no incrementing every second anymore) and starts overs maybe 10 or 20 seconds later. Seems that the data signal is just at the limit the PIC can "read" it properly. This does not happen in my SERIN2 mode.

With the oscilloscope, I measure 4,7VDC for the highest data signal level on PORTC.7 while the PIC and the GPS module are powered by the PICKit2 and its 4,95VDC from USB.

I think I will choose to stay on the SERIN2 version since it looks more "reliable" and, as already said, needs less components.

[Darrel Taylor]

Nevertheless, I have my PIC running for more than an hour now and it often hangs (= time is no incrementing every second anymore) and starts overs maybe 10 or 20 seconds later.

That sounds more like a USART buffer overflow.
If it isn't cleared ... it will hang.

Try adding ...

DEFINE HSER_CLROERR 1 ' clear overflow automatically