SERIN in acii, hex, decimal?

Printable View

- 28th February 2009, 20:39
sccoupe

SERIN in acii, hex, decimal?

I brought some code that I used in a picaxe08m over to PBP to try and complete a project that the picaxe couldnt handle. Ive been messing with this for over 5 hours today and my head hurts. :confused: The code below works fine with a 12f675 to display 3 digits on three, 7-segment displays using a dedicated driver and shiftout commands.

Code:

DEFINE OSC 4 ANSEL=%00000000 CMCON=7 digit1 var byte digit2 var byte digit3 var byte high 2 digit1 = 0 digit2 = 0 digit3 = 0 gosub configMC main: digit1 = 1 digit2 = 2 digit3 = 3 gosub updateMC pause 500 goto main end configMC: LOW 2 SHIFTOUT 1, 0, 1, [%1] HIGH 2 return updateMC: LOW 2 SHIFTOUT 1, 0, 1, [240 + digit1,digit2,digit3] HIGH 2 return

My issues are with getting the serin command to work correctly with a variable. I setup a BS2 to send out serial characters with the following code. This is set at 2400,8,N,1.

Code:

Main: DO SEROUT 0, 16780, ["4"] PAUSE 500 LOOP END

On the 12f675 side I added to the above code, the following...

Code:

serin 5,4,digit3

If I run the BS2 into hyperterminal it displays a 4 as it should every half second. The 12f675 displays a C instead of a 4. It seems to display 1 through 3 fine when sent from the BS2(probably just lucky) but any other integer doesnt work correctly.

My final project is to use 9600,8,N,1 serial that has no flow control option and the data sent as follows...

12.3
12.3
12.1
11.3

Just 2 digits, a dot, and one more digit with a carriage return over and over is sent serially and I need to display this on 7-segment displays.

So, am I making another noob mistake here? Will the 12f675 do serin at 9600 baud? Should I just be using a larger pic with enough I/O to handle three 7-segment displays or is the dedicated driver the way to go?

Thanks all,

Jason
- 28th February 2009, 20:55
Archangel

Quote:

Originally Posted by sccoupe

So, am I making another noob mistake here? Will the 12f675 do serin at 9600 baud?

Yes it will, not using 4mhz osc.

Quote:

Should I just be using a larger pic with enough I/O to handle three 7-segment displays or is the dedicated driver the way to go?

Thanks all,

Jason

Depends how much flicker you can tolerate, I have found using PIC that way either I got too much flicker or the displays were too dim. There are numerous examples on this forum, try some of them and draw your own conclusion, your opinion is really the only one that matters in your project anyway.
- 2nd March 2009, 22:44
sccoupe

Doing some more testing and decided to try out sending serial from the 12f675 to hyperterm and get wierd results as well. Its like its not sending the right ascii codes. For instance if I send a 1 then a white smiley face shows in hyperterm. If I send a 2 its a black smiley face. I ran the code below and all I get is an extended character list it seems.

Code:

INCLUDE "modedefs.bas" DEFINE OSC 4 ANSEL=%00000000 CMCON=7 dataout var byte dataout = 0 main: SerOut 0,N2400,[DataOut] pause 100 dataout=dataout+1 goto main

I think if I get this send figured out, then I might get the receive to work right. Hyperterm is set to 2400,8,N,1, no flow control.
- 2nd March 2009, 23:20
Bruce

Try SerOut 0,N2400,[#DataOut].

Note: You should try the serial terminal in the free version of MicroCode Studio.
It's a LOT easier to use than Hyperterm.

Also look at DEBUG. It produces a lot smaller code & works at higher data rates
at slower osc speeds.

Here's an example with DEBUG at 9600 baud;

Code:

@ device pic12F675, xt_osc, wdt_off, mclr_off, protect_off DEFINE OSC 4 DEFINE DEBUG_REG GPIO DEFINE DEBUG_BIT 0 ' GPIO.0 = serial output pin DEFINE DEBUG_BAUD 9600 DEFINE DEBUG_MODE 1 ' For DEBUG_MODE: 1 = inverted (direct connection), 0 = true (through MAX232) Loops VAR BYTE ANSEL = 0 CMCON = 7 Main: FOR Loops = "A" TO "Z" DEBUG Loops,13,10 NEXT Loops PAUSE 5000 GOTO Main END
- 3rd March 2009, 00:07
sccoupe

I gave that a try and just got a different unknown character in hyperterm. I added DEFINE OSCCAL_1K 1 and got an even different result. I read that the 12f675 internal osc may need calibrated. I have no idea if the factory cal has been messed with. I tried the link below from microchip, but it wont compile, with a bunch of errors. From what I read it seems to be a timing problem. Also tried powering with 3.3v instead of 5v and got yet a different result. I have an external crystal here that has 5.000 on it, so I assume that is 5mhz. Will this work for a test? Researching now on how to hook up an external chrystal.

http://ww1.microchip.com/downloads/e...tes/00250a.pdf
- 3rd March 2009, 00:22
Bruce

The internal osc isn't normally accurate enough for reliable serial communications.

It may work in one app, then not in the next. If you want reliable serial comms, go for an
external crystal or resonator. But if you are using the internal osc on this PIC, then you for
for sure want the DEFINE OSCCAL_1K 1 in there to load the factory osccal calibration value
at power-up.

Pretty much any decent device programmer will preserve the factory osccal value, but if it
doesn't, it's never going to work right with DEFINE OSCCAL_1K 1 in your code.

I.E. if your device programmer erases the last program memory location where the RETLW
xx (XX being the factory cal value to load into OSCCAL), and you insert DEFINE OSCCAL_1K
1 in your code, it creates a nasty loop you'll never get out of.

PBP inserts a call to the last program memory loaction when you include this DEFINE. If the
RETLW xx isn't there, it rolls-over back to location 0, and you land on the call repeatedly.

You can check by just reading your 12F with your programmer and checking to see if the
last program memory location has been erased.

If it has been erased, there are several threads here on how to fix this.

Quote:

I have an external crystal here that has 5.000 on it, so I assume that is 5mhz. Will this work

Nope. PBP doesn't support 5MHz osc speeds. Check in the back of your PBP manual in the DEFINE
section for a list of supported osc speeds.

There's also a schematic in your manual for connecting an external crystal with caps.

If you're using a 3-pin resonator with internal caps, ground the center leg & connect the
other two to the PIC OSC1 & OSC2 pins.
- 3rd March 2009, 00:41
sccoupe

Ok, I checked the 03ff location on the 6 different chips that im messing with and two of them have 3fff in that location and as my luck would have it as I switched chips in and out, these are the ones that I tried the 'DEFINE OSCCAL_1K 1' to no avail. The other 4 had values in the 34xx range so i guess that these are fine. I gave all 4 of those this code with the added 'DEFINE OSCCAL_1K 1' and all 4 display what they should in hyperterm. My luck seems to be this way sometimes. :) Little by little i learn.

Thanks again guys. Im off to see if this fixes my serin problem.
- 3rd March 2009, 00:49
Bruce

Ones with 34xx should be OK. The 34h = the RETLW instruction. XX is the value returned
in W.
- 4th March 2009, 00:02
sccoupe

Ok, everthing is working great at 2400 baud. The display and everything is working. Now I need to bump it up to 9600 baud. I read that this requires a faster crystal. Does a standard 2 wire crystal work or are there special ones to use? Is 8mhz all I need? How does one 'hookup' and external crystal. On a propellor chip, its a piece of cake because it has dedicated pins for it, not so on the 12f675. After its attached do I just add a DEFINE OSC 8 to replace the DEFINE OSC 4 command and set the serin to N9600 to replace N2400?

Thanks all.

Jason
- 4th March 2009, 01:01
Archangel

Quote:

Originally Posted by sccoupe

Ok, everthing is working great at 2400 baud. The display and everything is working. Now I need to bump it up to 9600 baud. I read that this requires a faster crystal. Does a standard 2 wire crystal work or are there special ones to use? Is 8mhz all I need? How does one 'hookup' and external crystal. On a propellor chip, its a piece of cake because it has dedicated pins for it, not so on the 12f675. After its attached do I just add a DEFINE OSC 8 to replace the DEFINE OSC 4 command and set the serin to N9600 to replace N2400?

Thanks all.

Jason

Hi Jason,
1. 2 wire crystal works, you do need to use capacitors from the crystal pins to ground.
2. DEFINE OSC xx where xx is the value of the crystal used
3. Yes simply change the number from 2400 to 9600 assuming you have included modedefs.bas
4. Here is the gotcha . . .You must change your config statement from _XT_OSC to _HS_OSC, this allows the PIC to consume enough power to oscillate at the higher FREQ.
I ALWAYS put a config statement into my code at the beginning. The other way is to edit the 12F675.inc file it the root directory of PBP to reflect this change. That is where the DEFAULT config statement resides for THIS chip. You will need to open that file in either case, because even if you choose to write the config statement into your code you will need to comment out ( ;__config . . . ) the existing config statement. Be advised there 2 different config statements in there 1 for MPASM and 1 for the PM assembler,
- 4th March 2009, 01:08
Bruce

Have you read post #4 yet...;o}
- 4th March 2009, 01:55
sccoupe

Quote:

Originally Posted by Bruce

Have you read post #4 yet...;o}

Hmmmm, will that also work for serin without a max chip?

What kinda of capacitors do I need for the external crystal? What pins to hook them up to and what code tells the chip what pins the external crystal is on?

Thanks again all!
- 4th March 2009, 05:30
Archangel

All right Jason,
Grab that data sheet, it's right there under the table leg, :D open it up to section 9.2.2, you will find a nice little chart, and schematic. That chart will tell you the caps need to be in the range of 15 to 30 pf, and will recommend higher capacities make the oscillator more stable but delay it's start up. . . Please download it (the data sheet) and look this over. That said, most use 22 - 27pf, or resonators as they are easier to mess with. Reading the data sheets are a must, you will understand them more every time you do, and they are free.
- 7th March 2009, 03:57
sccoupe

Ok, with your help and a little from the data sheet ;), I ordered some 3 pin resonators at 8mhz and they work fine. Everything works at 9600 baud and all. I hook this project up to my car (ignition on, engine not running) and it works as it should. When I start the car, the display goes crazy with all kinds of numbers. This is what happened when I tried reading an analog voltage using a picaxe. It worked fine on the bench, but didnt work with a running car. I even tried a battery for power and only hooked up the serial line and a ground. Can a schmit trigger be used on a serial line? I can only think that there is too much noise on the line. I can hook that line up to hyperterminal though and it works fine. Any thoughts?

Jason
- 7th March 2009, 04:09
Archangel

Quote:

Originally Posted by sccoupe

Ok, with your help and a little from the data sheet ;), I ordered some 3 pin resonators at 8mhz and they work fine. Everything works at 9600 baud and all. I hook this project up to my car (ignition on, engine not running) and it works as it should. When I start the car, the display goes crazy with all kinds of numbers. This is what happened when I tried reading an analog voltage using a picaxe. It worked fine on the bench, but didnt work with a running car. I even tried a battery for power and only hooked up the serial line and a ground. Can a schmit trigger be used on a serial line? I can only think that there is too much noise on the line. I can hook that line up to hyperterminal though and it works fine. Any thoughts?

Jason

Thinking out loud . . . serial data is a train of 5v pulses, so I would try putting a small value capacitor across the serial input line and bypass the power bus at the PIC too, it may help to shield the circuit in a grounded metal box too - automotive can make tons of RF especially from the ignition system. Even worse if you have a defective ignition wire as you might have 60000 volts going nowhere. A small value choke in series with the input might help too.
- 10th March 2009, 21:28
sccoupe

I just got this thing working. The interference that I was looking for wasnt there. I hooked up the scope looking for noise and realized that I wasnt looking at a TTL signal. After some research on how exactly rs232 works, I found that a Max232 chip was required for the conversion, luckily a guy at work had one. :rolleyes: So, Im going to order some 16F688's so that the built in uart and internal 8mhz crystal minimize my components and get the job done.