serial communication time

[paul borgmeier]

Mugel,

How is it coming?

I am still not clear what you are trying to do.

I also am not clear on what is causing your 1mS latency ... is it the actual send time of the serial data?

To me, it looks like you could use the USART on both the send program and the receive program and never really have to wait.

Here is MELABS example program on USARTS

http://www.melabs.com/resources/samples/pbp/usart.bas

Once the USART is configured then sending data is as easy as

TXREG = DATA1 ; where DATA1 is your Byte variable to send, your program continues on and the data is sent in the background

And receiving DATA is as easy as

DATA2 = RCREG ; where DATA2 is your Byte variable, your program can be doing other things while the data is coming in. Once the byte has been received in the background, your program can grab the data like this.

It looks like to me you could do what I think you want to do with the USART and without Interrupts.

Again, more details = more help

[Mugelpower]

Ok. To make it clear I want This:

http://www.sportdevices.com/ignition/ignition.htm

but want to do that myself AND by using Picbasic Pro (Full version 2.5). I don´t want to write Asm because I´m unable to do so.
Although I know this could be done with 1 simple PIC I´m willing to take 2 of them or 3 if necessary for Picbasic Pros sake.

Those smart Guys that programmed ignitions don´t even give you the ASM code, only Hex.

Further I need this circuit and software etc. modified for different engines . For that I bought the PBP software.

I know You Guys could programm something like I need in 5 minutes or less but I need something in simple structure so I can handle the software and necessary changes.

My actual problem is the fact that my serial pic to pic communication is far to slow AND the com routine seems to delay the interrupt action by about 1ms which is inacceptable.

Hope this made everything clear.

thanks for your interest.

[skimask]

In my mind...short and simple answers...

High speed PIC's could handle the work...it's all about the guy behind the keyboard
High speed anything don't work too well in the automotive environment...it's all about the guy designing the filters.
9600 baud...not so much...as stated before. You want data transmitted every .4ms . Not going to happen at 9600 baud, I don't care how you program it, unless you want to start dropping bits and sending 3 bits instead of 8. Must go with much higher speed as stated earlier.
You don't want to learn or write in assembly? Well, that's probably not going to happen either. PBP's built-in 'ON INTERRUPT' is designed in such a way that latency is practically unavoidable in a lot of situations. Using DT's Fast Interrupts isn't that hard, and yes, it does require you to learn a little bit about ASM, not much though.

In my mind, any serious ignition work is best suited for a different processor, maybe a dsPIC...not that a PIC couldn't handle it...with the right programmer behind the keyboard. Personally, I think you're playing with matches in a gas fume filled room. One ignition event just a bit early, there goes the intake manifold, a whole load of events a bit early, now you've got 8 pistons that could double as doughnuts and con-rods that could do double duty as horseshoes.

[Mugelpower]

Hi .
Ok maybe I´m not software-smart enough to get my data sending/recieving problem as fast as needed.
So I try to switch to parallel communication.
I like the instruction:

PortB = VAR (byte)

the only problem is the fact that I need Portb.0 for the external interrupt so I will take the PIC16F873 which has more pins. Still need the ZIF socket for my programming adapter.

I will tell how that works.

To Skimask:
yes you are right about your detonation assumptions.
Know a bit about engines myself : http://www.davidpower.de/fotos_mot.htm

[skimask]

So I try to switch to parallel communication.

I don't think it's so much serial vs. parallel as it is the fact that you've got to SPEED up the serial quite a bit, which is entirely doable, or switch over to a CAN based type network, which again, with the newer PICs, entirely doable.

yes you are right about your detonation assumptions.
Know a bit about engines myself : http://www.davidpower.de/fotos_mot.htm

Point taken. Looks like a bit of a fun place to work there! Wish I could read German(?)

[Mugelpower]

in a post i read something like this:

Define Debugin_Reg portc
Define Debugin_Bit7
Define Debugin_Mode 0
Define Debugin_Baud 115200

The baud rate seems to good to be true. is that possible with a 4 Mhz crystal , or maybe a 10 Mhz ? By the way I don´t get my Pic 16F628A-20 to work with max Speed regardless of capacitors. Tried several 20 Mhz crystals: No Go! tried several 10 Mhz crystals with different capacitors (27 pF-yes ,22pF-yes, 15pF-yes , 12 pF-no) and they worked.
What could be wrong?

[Mugelpower]

oh yes what does Portc mean in the upper post,
why not Portc.0 or something?

[Archangel]

in a post i read something like this:


By the way I don´t get my Pic 16F628A-20 to work with max Speed regardless of capacitors. Tried several 20 Mhz crystals: No Go! tried several 10 Mhz crystals with different capacitors (27 pF-yes ,22pF-yes, 15pF-yes , 12 pF-no) and they worked.
What could be wrong?

Remember every piece of wire at radio frequencies exhibits the properties of inductance and capacitence, and the reactance of both. Which means the wire acts as both a coil and a capacitor.

Might be you have too much wire attached to the Xtal lines, too many sharp bends in those wires, too low impeadance due to resistance path between pins somehow, If you forget to change the config fuse from XT to HS then insufficient power to OSC. Try using a resonator without additional caps and keep those wires as short and straight as possible.
JS