pic telemetry system

[comwarrior]

ok, i got it to output the voltage... so, the analog input now output as a voltage over serial connection... so i'm posting my code for anyone else that wants to use it...

Loop:
ADCIN 0, ADT1
ADT1 = ADT1 / 64
VARHIGH = ((48 * ADT1) / 10000)
VARLOW = ((48 * ADT1) - (((48 * ADT1) / 10000) * 10000)) / 100

HSEROUT ["DEC: ", DEC5 ADT1," V: ",DEC5 VARHIGH,".",DEC5 VARLOW,10]
GOTO Loop:

It's actually reading 2% low in the simulation... but thats good enough for me... may be a completely diferent case when in hardware...

[Ioannis]

In your soft com maybe you have to use n9600 instead of t9600.

Ioannis

[comwarrior]

i tried all combinations of inverted output with none inverted input (into the software uart screen), vica versa and the combo's between...

but the weird thing is... after the first line it gets all the numbers correct... so, it's almost like a sync problem... but this is all done in sim software, so why would their be and sync problems...

next job on my telemetry system is to make a counter... or more precisely, an RPM counter...

I'm mauling over creating a software uart buffer so that while it's waiting for the next AD conversion it can be sending the data...


I miss the good days of sending a full byte to a hardware uart in one go and have the program go do something else... I loved having 8/16 byte buffers on uarts...
I also (kinda) loved frying z80 chips when i got hardware wrong... programming in machine code, tape drives, 3" floppies... ahhh those were the days... although, battery backed ram modules were cool...

[Melanie]

I miss the good days of sending a full byte to a hardware uart in one go and have the program go do something else...

But that's EXACTLY what you do with a PICs USART anyway...

Actually thinking about it...

I also (kinda) loved frying z80 chips when i got hardware wrong... programming in machine code, tape drives, 3" floppies... ahhh those were the days... although, battery backed ram modules were cool...

You can do all of the above with PICs too...

[comwarrior]

Sorry mell, i meant with the software UART... my bad...

my JDM programmer arived today... still waiting on my pair of 16F877's

I can't help but wonder why mplab doesn't have JDM programmer in the list... i'm guessin it's a sales thing...

I got my test board solderd up... it's only 8 mini LED's direct drive from portb whith a knight rider program done myself... simple enough for a test board...

i'm aware of what you can do with a pic... thats why i switched from the Z80180's (it's a Z80 with dual hardware uarts and memort manager that can access upto 1meg with speeds upto 40MHz) but it kinda hard to get hold of them these days...
PIC's seem to be the dogs cahuners...

[Ioannis]

For the soft uart case. I seldom use the software choice, but if I do, I make sure that the first thing the program does is to issue a high on the serial port (or low, depends of the way it drives the line).

Then a pause of 1sec and the serial port is initialized to the idle state. Otherwise, it sees an invalid state and the first at least character is messed up.

Ioannis

[comwarrior]

Morning ioannis,

thats interesting... i completely understand where your coming from... i'm wondering if my trisb is too close (time wise) to my 'initialised' output line...

I'm going to sim some variations including setting the port to high or low and waiting...

Everything i've read on software UART indicates the fastes speed is 9600... can it not go any faster? 19200 would be handy...
i understand why it's speed limited, i'm just asking if it can? other than me programing a software uart myself...

Thanks