pic telemetry system

[comwarrior]

...really what adult talks about their code exploits at 13 anyway?

... the ones that have been programming for fun since an early age and know a few languages...

As for atitude, as i allready said, i'm considerd a pro or expert or guru in various other forums and i'd be ashamed of myself if i answerd a newby's question like that...

Did not got exactly all the answers? Why not re-ask? No hurt. Blaiming for un-helpful and no-one is going to help in the future. Why bother? Our time is precious besides...

1. Set up is fine.

2. You got it. But consider to use (if you don't) the Usart for most efficient way to send receive data and also interrupts (look for DT-INTS on the forum).

3. As stated a resistive voltage divider is all that is needed. Simple ohms law to find the values according to your Vin/Vout needs.

Ioannis

Ioannis, thank you, direct answer saves time...

I'd actually ruled out using a resister type voltage devider for the reason that it draws curent from the source your measuring... I had thaught of an opamp or another type of amplifier...


What i'm intensly looking at and trying to resolve is a little problem i seem to have with the data coming out of both hardware and software comm ports in oshonsoft's PIC simulator IDE... dispite having Baud, stop bit and parity correct I regularly get glifs coming out of the ports... but the two ports have gilfs in diferent places... and the software port reciever is reporting stop bit errors????? weird... must be a config error somewhere, thinking about it, I wonder if stop bit/parity is set to none if pic's allow it... meh, i'f sure it's a conf error, i'll find it...

Thanks to...
Ioannis & Dave

Also, I think the PBP way of handling interupts is stupid... you should be allowed to write interupt handlers in PB without PBP inserting all that extra code...

X

[Dave]

comwarrior, I have never seen in my 40+ years of hardware where you would have a start bit and no stop bit.. I would check the frequency being sent to the baudrate generator (clock) and see if it needs some adjustment..

Dave Purola,
N8NTA

[Ioannis]

I'd actually ruled out using a resister type voltage devider for the reason that it draws curent from the source your measuring... I had thaught of an opamp or another type of amplifier...

Then use higher value resistors (Mohms) and a suitable opamp as an unity gain buffer, like the LMC662 series (rail to rail).

Also, I think the PBP way of handling interupts is stupid... you should be allowed to write interupt handlers in PB without PBP inserting all that extra code...

Read my post again. Answer is DT-INTS. It has nothing to do with PBP interrupts. Credits go to Darrel Taylor for his great contribution. Look also his site www.pbpgroup.com for the software.

Ioannis

P.S. I still have that old ZX Spectrum and Zeus assembler. What days was those...

[comwarrior]

ok, i see what your saying for interupt handling and i'll read more when i get fedup trying to sort the comms out...

here is a little test program i've done to try and debug the problem with the serial comms...

include "modedefs.bas"
include "bs1defs.bas"
Define CONF_WORD = 	0x3d71
Define  OSC				4				' Set clock speed

Define  ADC_BITS        10     			' Set number of bits in result
Define  ADC_CLOCK       3     			' Set clock source (3=rc)
Define  ADC_SAMPLEUS    50    			' Set sampling time in uS

SPBRG = 25              ' Set baud rate to 2400
RCSTA = %10010000       ' Enable serial port and continuous receive
TXSTA = %00100000       ' Enable transmit and asynchronous mode

RCSTA = %10010000       ' Enable serial port and continuous receive
TXSTA = %00100000       ' Enable transmit and asynchronous mode

ADT1 var word							' Create ADT1 to store curent ad conversion for AD channel 0
ADT2 var word                   		' Create ADT2 to store curent ad conversion for AD channel 1
ADT1MAX var word						' Create ADT1MAX to store curent ADC0 max val
ADT1MAX = 0
ADT2MAX var word						' Create ADT2MAX to store curent ADC1 max val
ADT2MAX = 0
ADT1VAL var word
ADT1VAL = 0
ADT2VAL var word
ADT2VAL = 0
ADV1 var word

TRISE = 255							' Set PortE to all inputs
TRISD = 0							' Set PortD to all outputs
TRISC = 0							' Set PortC to all outputs
TRISB = 0							' Set PortB to all outputs
TRISA = 255 						' Set PORTA to all input
ADCON1 = 0 							' PORTA is analog

HSEROUT [" initialised",10,13]
SEROUT PORTB.1,t9600,[" initialised",10,13]

Loop:
ADCIN 0, ADT1
HSEROUT [DEC5 ADT1,10,13]
SEROUT PORTB.1,t9600,[#ADT1,10]
goto Loop
end

From software UART i get...

+¥ֻ±Í•´
0
0

software uart output is reporting incorrect stop bits when it sends the "initialising" stream...

I should re-point out, i'm experimenting in a PIC simulator untill i get the right output...
i have a pair of 16F877's due to arive tomarow and JDM programmer and max232 converts (serial and USB versions) due to arive at any time...

I know i've not included the half second pause for ADC...
so, what have i missed out from my initialisations?

Thanks

[comwarrior]

and now... i'm having Floting Point Math 'issues' too...

FPM sux...

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