Receive serial data

Hi all,

I have built a logger to store temperatures into an eeprom and later at home i dump all values to my PC where i can build graphs and so on.

My objective is to build an interface with a pic/eeprom/LCD where i can connect to the output of my logger and receive the data and get the math for Max, Min, Avg and check these values on site with the LCD.

I have almost everything figured up but i'm puzzled in how to receive the data.

The logger is sending the data with a loop like: reading eeprom at address x, sending that data using the debug line ( with 13,10 at the end to separate the values ) and with a speed of 9600, increment x and loop for next address.

The result is something like this:

23
28
50
75
110
115
etc

My doubt is in how will be the codeline to receive and place each temperature reading in a variable for storage. How to recognize each reading and not mixing or skip any other?

Thanks
Rui

What is the range of temperatures that you are going to record?

Greetings Skimask ;)

Long time no talk :)

The recorded temperatures from the logger are between 0 and 160ºC.

Thanks
Rui

Quote:

---

Originally Posted by ruijc

The recorded temperatures from the logger are between 0 and 160ºC.

---

1 degree granularity (i.e. 10C 11C) or less than that (i.e. 10.2C 11.547381223430947C)?

Just 1 degree granularity 10, 11, etc

.

Quote:

---

Originally Posted by ruijc

Just 1 degree granularity 10, 11, etc

---

Well, if it was me, and I wanted close to 100% assurance that my data was good, I guess I'd go a little bit crazy and do something like have a 'packet' of X number of bytes, each packet for one temperature reading for each 'location'...

packet start ID (example of $FF)
address X.lowbyte
address X.highbyte
data byte
same data byte (inverted)
address X.highbyte (inverted)
address X.lowbyte (inverted)
packet end ID ($00, which is the packet start ID inverted)

So, I'd end up with an 8 byte packet, everything is sent, then it's all sent again but inverted at the bit level. The packet start ID might be an $FF (because the temp's will never be that high), the addresses might be that high, but if you got that then the packet end ID wouldn't match up.
It's a bit overkill, but I don't see why it would work. And really, I think I'd trust my wiring enough to just send a couple of $FF's as a start marker, then the whole recorded memory from start to finish, maybe with a couple of $FF's as an end marker.
It's all up to you. You get to make RSP... ruijc's serial protocol.

Thanks Skimask,

Quote:

---

Well, if it was me, and I wanted close to 100% assurance that my data was good

---

I agree. Me also.

It makes perfect sense.

The reason i'm with this system it's because it was simple to build and simple to transfer the data to the PC using a freeware RS232 logger software. I just dump the values to it with the format i have showned ( one temp value per line ) saving them in a txt file and then just import to excel and generate the graphs.

The reason i'm asking how to do this with this system is that this way i can maintain my logger as is and just need to build the module with LCD to view the data "on site".

I cannot re-program the logger because it's encapsulated with resin to reduce size and weight.

If it could be done i was more than half way there to complete the module ;)

Thanks

sorry, didn't read last post

Any idea how to collect the data ? anyone ?

.

I have not tried it, but could you use 10 or 13 for the wait character and then store the data.

Greetings mackrackit,

The 13,10 it's just for carriage return like so:

Code:

---

DEBUG DEC VALUE,13,10

---

How can i detect it ?

.

Quote:

---

Originally Posted by ruijc

Greetings mackrackit,
The 13,10 it's just for carriage return like so:

Code:

---

DEBUG DEC VALUE,13,10

---

How can i detect it ?
.

---

Look in your manual under DETECTing...
Seriously, the answer was in mackrackit's last post...something about WAITing for something...

The only thing i could find in the manual was the Serin and Serin2 commands.

The manual says that:
SERIN2 DataPin {\FlowPin}, Mode, {ParityLabel,}, {Timeout,Label,} [Item...]

with the example:

Code:

---

SERIN2 1,16780,[wait (“A”),B0]

---

( where A is the caracter to wait for. )

and
[code]SERIN2 PORTA.1,84,[skip 2,dec4 B0][code]
( where it will skip the first 2 digits and grab the next 4 digits)

I didnt test it yet, but can i use something like this?

Code:

---

SERIN2 PORTA.1,84,[wait (13,10),dec3 B0]

---

Its not making sense to me because i have values with one, two or three digits ( temps from 0 to 160). The idea is to grab each value - and this line knows when to start for the first value but doesnt know when to finish before grabbing a new one.

Quote:

---

Originally Posted by ruijc

The only thing i could find in the manual was the Serin and Serin2 commands.

---

And you'll see the same 'type' of thing for HSERIN and DEBUGIN

Quote:

---

I didnt test it yet, but can i use something like this?

Code:

---

SERIN2 PORTA.1,84,[wait (13,10),dec3 B0]

---

Its not making sense to me because i have values with one, two or three digits ( temps from 0 to 160). The idea is to grab each value - and this line knows when to start for the first value but doesnt know when to finish before grabbing a new one.

---

Now you're thinkin'! Except that it does know when to finish, because you specified when to finish in that line of code above with dec3 B0. As soon as it grabs a 3 digit decimal, the statement is done...
So in your case, you don't wait for a 13,10 then grab a decimal, flip it around.
Grab a decimal, then wait for the 13,10.

Code:

---

SERIN2 PORTA.1,84,[dec B0, wait (13,10)]

---

Just use the string input option with the terminator set to 13.

Code:

---

MyVar VAR BYTE(3)

Main:
    HSERIN [STR MyVar\3\13] ' receive up to 3 characters, terminate input on receipt of 13
    HSEROUT [STR MyVar\3,13,10] ' show it
    PAUSE 100
    goto Main

---

This will receive up to 3 bytes, 0-160, and terminate reception on receipt of 13.

Bruce, skimask,

Thank you very much for your help.

Will try when i get home, but it makes perfect sense !

.

Another thing to try is just a plain DEC.

DEBUGIN [DEC MyVar]

DEC waits for a numeric character and discards anything else until it gets one. Once it receives a character that is a number, it continues receiving more digits until it gets a non-numeric char which would be the 13.

This way the value can be any length, and you don't have to convert it to a byte.
<br>

Thanks Darrel Taylor,

will try your code too.


[edit]never mind ;)

Hi all,

just to let you know that it worked. I came across some issues but i managed to fix them.

One of the issues was that i had to use a 10K pull down resistor between my logger and the new receiver.

I kept a simple code and it works and no loss of data was found.

here's the tryout code:

Code:

---

'****************************************************************
'PINS

n5        var GPIO.5
n4        var GPIO.4
BUT        var GPIO.3
led    var GPIO.2
n1        var GPIO.1
IN          var GPIO.0

'*****************************************************************************

DEFINE OSCCAL_1K 1
define OSC 4

'*****************************************************************************

@ DEVICE pic12F675, INTRC_OSC_NOCLKOUT
@ DEVICE pic12F675, WDT_OFF
@ DEVICE pic12F675, PWRT_OFF
@ DEVICE pic12F675, MCLR_OFF
@ DEVICE pic12F675, BOD_ON

'*****************************************************************************
Include "modedefs.bas" ' Include serial modes

DEFINE debug_reg gpio
DEFINE debug_bit 1
DEFINE debug_baud 9600
DEFINE debug_mode 1

DEFINE DEBUGIN_REG GPIO
DEFINE DEBUGIN_BIT 0
DEFINE DEBUGIN_MODE 1

'*****************************************************************************
ADCON0=0
ANSEL=0
CMCON=7 
trisio=%00111001   
GPIO=0

'*****************************************************************************
START:
led=0
if but=1 then
goto rc
else
goto start
endif


rc:
led=1
DEBUGIN [DEC VALUE]
DEBUG dec VALUE,13,10
goto rc

end

---

Thanks for the help ;)