High priority/low priority program parts

[mpgmike]

Unlike Henrik, I happen to LOVE autos. What I would suggest is to set your UART Special Function Registers, add the DEFINEs in your header, and use the HSERIN/OUT commands for your serial communications. This puts communications things in the background. When working with LCDs I like to use a PORT for data when I can afford the MCU pins; this means PORTx is dedicated to LCD communication. Setting a PORT to a variable value only takes one instruction cycle. ENABLE = 1 takes one instruction cycle. How long you hold ENABLE High (I use 8 uS) may interfere with other activities.

I suggest you prioritize your activities, use INTERRUPTs for the highest priorities, then use normal lines of code for things like the LCD, you should be good. Like Henrik said, you can also calculate how long it takes for various functions (like LCDOUT) and place them in your code so they don't interfere with other functions. I experienced something where using interrupts the processor would occasionally go into an unexpected RESET. I created a bit variable and cleared it in the normal code and set it in the Interrupt Routine. The Main loop would DO/LOOP WHILE until the Interrupt Routine did its thing and cleared that bit. The Main Loop would then set the bit, do other things, then DO/LOOP until it got the clear bit. You might try throttling (gating) your Main loop to correspond with your ISR.

[Mugelpower]

Hello mpgmike,

thanks for your offer.

I decided to use two PICs because I´m too dumb to program everything correct to do the project with one PIC.
Reason is I began setting footsteps into the PIC world about 10 years ago,"developed" a small singlesided one PIC16F88
board and ordered about 30 of them from a PCB Professional. Now I had a small board to use for simple tasks
like controlling an electric waterpump and switching a cooling fan and showing Temperature and pump load on an LCD.The code was primitive AND very slow, the PIC ran on 4 MHz but for temperature control it was ok. Was lucky with that then.
Paused several years and began a project for one of the cars of my wife with a controller that added an electric fuel
pump. Now problems began because I needed two HPWM outputs.Not possible with a 16F88. I had some simple thingys worked out with a 18F1320 and at the time I had established the right configs (with the help of this community) I wiped the sweat off my forehead and could do the same the 16F88 could but way faster.
Serial communication didn´t work because of a problem in my homecomputer setup. Strange thing because I posted
forum threads 8-10 years ago that showed serial com worked but now without changing the homecomputer or the software it didn´t anymore.
So I purchased PBP3 Gold two month ago , set it up on my notebook and voila, serial com between PICs worked again.
I decided to take two PICs , one for the slower Temperature control (16F88) and one 18F1320 for the faster fuel pump
control. I dont want to run the fuel pump full load all the time because it draws more than 20 Amps.And it costs more than 300$ so I want to save it. Minimum load (plus a reserve) at engine idle and quick response to raising engine speed. Nowadays the cool guys control these pumps via a digital fuel pressure controller that sends a signal about the amount of return fuel, but these units cost about 500 $ and need a controller too (300$).
With two PICs I can use my simple code concentrating on the single task , only the 18F1320 has to run the LCD too.
HA! the "professional" pump controllers use LEDs and no LCD.
here an example for a waterpump controller:

https://www.tecomotive.com/en/products/tinycwa.html

I use a "huge" billet aluminium case, a LCD and military style connectors capable of 40 AMPS.

My problem: the communication of these two PICs and the LCD routine are slowing the 18F1320 down to
uselessness.One mainprogram cycle may take 0.3 seconds. that 3 times more than the acceptable limit.
Because when the engine revs up the fuel pump has to rev up too.Fast.otherwise the egine will bog.
With Henriks help we have pinned it down the problem that the 18F1320 has to wait for the 16F88 to send
a Character. The 16F88 has a slow routine wich slows down the 18F as well.
So the communication between both shouldn´t disturb the 18Fs main routine. Now I have to separate
the "count/HPWM" main routine from the "get charakters and show on LCD" routine. because the LCD routine
can take a whole second or some more, that doesn´t matter.
I appreciate your help.
Next point: I´m somewhat happy getting the serial com between both pics running......old fart thing sort of.

[Mugelpower]

can I use "on interrupt" or do I have to use DT´s interrupts?

I hoped PBP3 Gold had swallowed up these advantage.

[mpgmike]

ON INTERRUPT works just fine, especially when you are only using one interrupt. For multiple INTERRUPTs, your ISR does nothing more than filter through possible Flags & sends the code where it needs to go.

Not sure what all you're controlling, but HPWM can control your coolant fan, with temperature thresholds for duty cycle. Reading the analog port only takes maximum 50 uS (microseconds). If no change in temperature, no change to the HPWM DC%. As for fuel pump Duty Cycle%, what are you using to determine your needs? I would use either a pressure sensor (some of the newer vehicles have them built into the fuel rail) with a MAP where you are maintaining a constant absolute pressure, or perhaps just TPS. Absolute pressure is way more accurate and would be less likely to cause a lean condition at WOT.

May I suggest using something like a PIC18F46K22. It is a 40-pin device. You have an entire PORTB to control your LCD, it has plenty of analog channels, plus it has 5 CCP/PWM modules. Use one Analog port for your ECT, one for MAP, one for Fuel Pressure, and perhaps one for TPS. Controlling the fan is rather simple using SELECT CASE CTS
CASE IS < 90 : HPWM 1, 0, 1000
CASE IS < 100 : HPWM 1, 127, 1000
CASE ELSE : HPWM 1, 200, 1000
END SELECT

For fuel pressure & MAP you'll need to find what voltages equate to what pressures. If turbo, you're probably using at least a 2-BAR MAP. With a 5 volt VREF, anything above 2.5 volts and you have boost. You probably need about 2.4 BAR of fuel pressure.
Duty VAR BYTE
IF (Fuel_Value) < (MAP) THEN
Duty = Duty + 1
HPWM 2, DUTY, 1000
ENDIF

Of course this is rather simplified as you need to do the conversions before comparing.

If you can get by with 28 pins, the PIC18F26K22 is the same basic MCU but with fewer pins.

[Mugelpower]

Hello mpgmike,

you are totally right. Problem is: I already made the PCB for this double-PIC Project and it works halfways.
If I had to begib new i would take your advice and get the 18F26k22. Maybe I got some liying around.
I bought 18F45K... for a projekt Henrik supports me but this device is too big in pin-through case form. Its HUUUGE
compared to a 18F1320 in SMD which I have.
It took me days to develop the PCB and manufacture it and I think optimizing the program is way less work
than starting new.Next thing is : I try the HSEROUT/HSERIN thingy and watch if the cycle gets faster.
I don´t have as much leisure time as I would like to.

[HenrikOlsson]

HSERIN/HSEROUT won't make any difference on it's/their own.

You need to look at the system level. Why is this code taking up to 300ms to execute? Because it sits here waiting for data for 300ms Before continuing (if no data arrives). So, the next question then is what is the F88 doing and how often does it actually SEND data?

And again, think about implementing some handshaking or polling scheme.

/Henrik.

[Mugelpower]

hello Henrik,
I thought HSERIN/HSEROUT would automatcally take care of the handshake. In the background.

On the other hand i could put some more debug commands into the 16F88 code so that it has for example

3 Debug commands between the main program lines. That should translate to 3 times sending the same which
translates to less waiting of the 18F1320 to get what it wants.It doesn´t matter that this will slow down the 16F88, it has the slow task.

Haha! Thats the total primitive method. I guess you will call it "Flintstone style programming".

[HenrikOlsson]

No, HSERIN/HSEROUT does not do handshaking automatically, in the background.
The UART in the PIC can receive one byte/character (and almost a second full byte/character) without the code doing anything but when that byte/character is received the code must fetch the byte from the receive buffer. This is where interrupts come in but you you were quite clear you didn't want to go that route - and frankly, it should not be needed for this.

And again, using HSERIN with a WAIT statement in place of DEBUGIN will gain you pretty much nothing.

Can you post the '88 code for us to take a look at, I'm sure you'll get plenty of suggestions on how to improve it.

/Henrik.