serial communication time

[skimask]

Now it works but only with this Baud rate of 2400.
BUT I WANT a Baud rate of ONE ZILLION or so.
seems I´m still at the beginning.
Or is it possible to run the data transfer in the background using some asm code ?
Greetings from Mugel

I guess I still don't get what you're trying to accomplish in the end.

It probably works at 2400 baud because there's enough time in between transmitted characters to send the data out to the LCD. At higher speed, when PBP returns from displaying to the LCD, the next transmission/reception is already halfway done and it gets missed. Either that or your oscillator is out of tolerance.

As far as using high baud rates, no you don't really need asm code...just a good understanding of the PIC, it's registers, the USART module, and some interrupts.

And it seems I'm right back to saying what I said back on 1Feb...

[Mugelpower]

Hello famous Skimask,

my LCD is only for controlling the principal of transmission.

I got 3 Pics together:

1. : getting Input, storing freq in VAR "CNT" and sending out with Debug
2. : taking the VAR "CNT" with Debugin, calculating a Delay and sending out a 1ms Pulse
after RB0 gets High + Delay time.
3. : taking the VAR "CNT" and showing on LCD just for control purposes

Showing my extremes:

a)cranking a 4-cyl. engine makes about 180/min. with a fixed 50° before OT input signal we need a delay of 37 ms until Ignition which makes 10° before OT which is great for starting an engine.

b) 4cyl 8000/min: we need only 0.2ms Delay after fixed 50° Input signal to get 40° before OT Ignition which may be great for a racing engine.

The delay has to include the PICs intern calculation delay.
The calculation could be done in the first PIC which measures only 10 times a second
BUT the "Execution PIC" has only about 1.5 ms for receiving the Var and being ready for the next action.
And an 8cyl at 6000/min leaves only 0.8 ms.
thats why I need transmission speed

[Archangel]

Hello famous Skimask,

my LCD is only for controlling the principal of transmission.

I got 3 Pics together:

1. : getting Input, storing freq in VAR "CNT" and sending out with Debug
2. : taking the VAR "CNT" with Debugin, calculating a Delay and sending out a 1ms Pulse
after RB0 gets High + Delay time.
3. : taking the VAR "CNT" and showing on LCD just for control purposes

Showing my extremes:

a)cranking a 4-cyl. engine makes about 180/min. with a fixed 50° before OT input signal we need a delay of 37 ms until Ignition which makes 10° before OT which is great for starting an engine.

b) 4cyl 8000/min: we need only 0.2ms Delay after fixed 50° Input signal to get 40° before OT Ignition which may be great for a racing engine.

The delay has to include the PICs intern calculation delay.
The calculation could be done in the first PIC which measures only 10 times a second
BUT the "Execution PIC" has only about 1.5 ms for receiving the Var and being ready for the next action.
And an 8cyl at 6000/min leaves only 0.8 ms.
thats why I need transmission speed

Hi Mugelpower,
.8ms, interesting number, how did you get that? 8cyl eng @ 6000 rpm fires 4 times per rev so 6000 * 4 = 24000 per minute 24000 % 60 seconds = 400 pulses per second so 1000 ms % 400 = 2.5 ms No?

[skimask]

my LCD is only for controlling the principal of transmission.

Loses something in the translation here

1. : getting Input, storing freq in VAR "CNT" and sending out with Debug

What INPUT?

2. : taking the VAR "CNT" with Debugin, calculating a Delay and sending out a 1ms Pulse after RB0 gets High + Delay time.

What does CNT represent? What is the delay for? Where does RB0 get a high pulse from?

The delay has to include the PICs intern calculation delay.

Which at times can be a variable delay due to the way math is done with PBP.

thats why I need transmission speed

Transmission speed? RPM of the input shaft? output shaft? MPH? KPH? GPM?

[Mugelpower]

Hi Skimask,

I try to answer with a minimum of translation losses....(Reminds me of principal Skinner, hehe)

1. Input is a 50% Duty cylce with 1/2 frequency of the magnetic/Hall pickup from the distributor because the Duty cycle varies sometimes with the frequency. So I took a 4027 to cut it in Half and got a nice constant 50/50 square signal. Makes 6Hz up to 300Hz. Thats my 1/2 frequency range. Threfore I have to multiply my VAR CNT by 2 to get the real freq, If I want to.Now I can handle this Input(my Variable CNT) mathematically like i want or need.
The easy thing is: we need this Input Variable only changed every 0.1 sec. thats fast enough.When the engine runs with constant speed for example for 1 minute we dont even need to change the Input variable because theres no difference.Thats the task of my first pic including sendig (by DEBUG)this Variable or the calculatet Delay (variable name and task is the same here) to PIC #2.

2. PIC #2 reacts when the RB0 pin shows a change fromlow to high. thats the same Input signal from our Distributor but the original frequency . The signal has to be changed into a square signal by a comparator or Schmitt-trigger.But here we need the precise starting point. After that a delay (Stored in the Var DELAY and calculated before depending on the input VAR CNT ) is startet ("ON Interrupt "or an asminterrupt handler needed here )
to get the right time for the Ignition action. This could be in the simplest way 10° befor OT at low speeds and 40° at high engine speeds (rotations per minute, Input signal fromthe distributor stored in VAR CNT). As you can see, even if you want a constant ignition action say 20° before OT the time of the delay after the delay starting signal (50° before OT = constant) the delay is reciprocal to the engine speed and reciprocal to VAR CNT.

3. Ignition action is a simple Output signal from the pin we choose (here PORTB.7) of 1ms high. This is send to the ignition coil driver wich switches 10Amps and 12Volts.The End of the 1ms is The Ignition timing point.

4.Due to PICs internal and software delays we need a correction factor for the VAR DELAY depending on Engine speed. Once we got this I´m happy. maybe in a list with just 10 points from low engine speeds to high speeds. Cranking is another thing because theres no constant cranking speed so the VAR DELAY has to be calculated for every cranking speed.
From 1000/min up we need only 10 different pre-ignition values, maybe 1000-1500,1500-2000 and so on. BUT: VAR DELAY would be different for a constant ignition timing for 1000/min or 1500/min.

If I can make anything more clear I will do so.

Transmission speed: The calculated VAR DELAY has to be sent from PIC1 to PIC2 (The ignition action PIC) .
BUT I put in a PIC#3 thats just for control purposes to check the VAR DELAY thats sent.
At the time theres no calculation OF The VAR DELAY and I´m sending just the "rough data VAR CNT". Calulation code is implemented after the transmission works.

Now: How will I send a WORD Variable fromPIC to PIC at Engine speeds of 8000/min? just 0.2 ms left. Or its done in the background with the famous USART registers which I try to use with DEBUG .......

[skimask]

Hi Skimask,
1. ..........Now I can handle this Input(my Variable CNT) mathematically like i want or need.

Multiplying by two is the same as a LEFT SHIFT, which only takes a single clock cycle on a byte, about 3-4 cycles on a word

4.Due to PICs internal and software delays we need a correction factor for the VAR DELAY depending on Engine speed. Once we got this I´m happy. maybe in a list with just 10 points from low engine speeds to high speeds. Cranking is another thing because theres no constant cranking speed so the VAR DELAY has to be calculated for every cranking speed.
From 1000/min up we need only 10 different pre-ignition values, maybe 1000-1500,1500-2000 and so on. BUT: VAR DELAY would be different for a constant ignition timing for 1000/min or 1500/min.

Learn how to use the hardware timers and you won't have a problem with the PICs internal software delays. Let the timers run on their own and interrupt the main program to trigger whatever you need triggered.

Now: How will I send a WORD Variable fromPIC to PIC at Engine speeds of 8000/min? just 0.2 ms left. Or its done in the background with the famous USART registers which I try to use with DEBUG .......

DEBUG doesn't use the internal USART, it too is a software bit-banged command.
8000 RPM = 133.3 RPS...
A word = 16 bits, 2 bytes = 8 bits x 2 + start/stop bits = 20 bits for each word.
134 (133.3 rounded up) x 20 bits = 2,680 baud, use 9600 baud so it's a standard baud rate.
Each word takes 2.083 ms, 134 times per second, 278ms used by the serial port per second at maximum RPM, leaves you with 722 ms to play with total in between words, 5.38ms on average between each word sent.
But, cut each of those numbers by 1/4 for an 8 cyl engine, still leaves you with 1.34ms between each ignition event.

Completely software driven is NOT the way to go with this. You NEED to learn how to use the hardware timers/interrupts, etc. to get this done with blowing holes in pistons.

[Mugelpower]

Thanks Skimask,

thats exactly what I was afraid of. OK it took one year to get me this far maybe I can make the whole thing go in another 6 months.....

I know Darrel Taylor got some interesting asm routines for interrupts. That may be a starting point.

AAAARRRGGGGHHH!

[skimask]

Thanks Skimask,
thats exactly what I was afraid of. OK it took one year to get me this far maybe I can make the whole thing go in another 6 months.....
I know Darrel Taylor got some interesting asm routines for interrupts. That may be a starting point.
AAAARRRGGGGHHH!

Afraid of!!!???!!!???
Don't be afraid... As long as you don't have whatever it is connected to a fuel burning 'thing' of some sort, what's the worst that could possibly happen?

The learning curve is steep, but once you're over the intial hump, everything else falls into place...for the most part