SERIN in acii, hex, decimal?

[sccoupe]

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. The code below works fine with a 12f675 to display 3 digits on three, 7-segment displays using a dedicated driver and shiftout commands.

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.

Main:
  DO

    SEROUT 0, 16780, ["4"]

    PAUSE 500


  LOOP
  END

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

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

[Archangel]

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

Yes it will, not using 4mhz osc.

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.

[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.

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.

[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;

@ 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

[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

[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.

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.