High priority/low priority program parts


Closed Thread
Results 1 to 21 of 21
  1. #1
    Join Date
    Jan 2008
    Location
    Selm, Germany
    Posts
    116

    Lightbulb High priority/low priority program parts

    Hi folks,

    I´m working on my 18F1320 + 16F88 projekt and ran into the following problem:

    The 16F and the 18F are communicating via debug/debugin which works great.
    The 18F shows on LCD but has to do the works that needs short reaction time.
    Now I tested and found out that following commands(not the complete program)

    define osc 20
    main:
    count PORTB.3,50,X0
    a very small calculation here that calculates speed on basis of X0
    hpwm PORTB.0 ,speed,2442
    debugin [wait"*.*",dec3 RX,RS,TEMP],13,10
    LCDout line1
    LCDout line2
    LCDout line3
    IF...THEN routine
    LCDout line4

    goto main

    baud is 19200, the 16F runs 20MHz too


    one routine takes up to 0,3 seconds!
    I need a complete routine to run in less than 0,1 second otherwise the complete process ist
    way too slow for my application.
    So I dream to give
    the count/HPWM program part a high priority
    and the LCDOUT a lower one.
    Problem is:
    when XO changes, the HPWM signal has to react fast
    and not to wait for the program to complete LCDOUT

    could I run the count/HPWM thing in an interrupt style and the LCDOUT outside the interrupt thingy?
    I guess the "debugin [wait....]" line slows it down too much

    I appreciate your help

  2. #2
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,516


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

    Since you have a WAIT state in the DEBUGIN statement that part of the code will take as many millesconds or years it takes for that "*" to arrive - simple as that.

    You have lot of nice peripherals available to you, why not make use of them?
    Use the UART for communication and a timer to count the pulses for you.

    Also, each time you update the dutycycle using the HPWM command you'll get a small "glitch" in the waveform (due to the fact that HPWM completely reconfigures the CCP module each time). You're better off just writing to the dutycycle register(s) directly.

    /Henrik.

  3. #3
    Join Date
    Jan 2008
    Location
    Selm, Germany
    Posts
    116


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

    Hello Henrik,
    the HPWM glitch doesn´t matter because its driving an electric fuel pump.
    I read the UART section in the old PBP handbook and it says: "very complicated" which is a nogo for me .
    When i remember right I may use the HSERIN/HSEROUT command? Is that the USART thing?
    Can I let go of the "wait" statement when using HSERIN/HSEROUT?
    And using a timer to count....thanks for the advice that looks like a dive into assembler which causes freezing my neurons.

    Regards

  4. #4
    Join Date
    Jan 2008
    Location
    Selm, Germany
    Posts
    116


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

    hello Henrik,

    for your entertainment a picture that shows some of these clunky metal chunks that are at the center of my profession. Just imagine the mental distance between bringing these chunks back to life for more than 20 years and programming assembler.Yes, its difficult to teach an old dog new tricks.Name:  old metal.jpg
Views: 513
Size:  176.6 KB
    Attached Images Attached Images  

  5. #5
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,516


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

    Hi,
    > the HPWM glitch doesn´t matter because its driving an electric fuel pump.
    OK, no problem with that then.

    > I read the UART section in the old PBP handbook and it says: "very complicated" which is a nogo for me .
    If you say so.

    > When i remember right I may use the HSERIN/HSEROUT command? Is that the USART thing?
    Yes, HSERIN/HSEROUT is using the USART peripheral in the PIC instead of bitbanging.

    > Can I let go of the "wait" statement when using HSERIN/HSEROUT?
    Depends on how you go about doing the "whole thing". You can use the USART to receive characters in the background using interrupts but I suspect you don't want to go that route either.

    > And using a timer to count....thanks for the advice that looks like a dive into assembler which causes freezing my neurons.
    No need for any assembly language. Look at the Timer n section of the datasheet and you'll see how you can configure it as a counter.

    Here's an idea:
    Read up on how to use a timer as a counter and get that going.
    Write your LCDOUT and housekeeping code in such a way that always takes the same amount of time, like 50ms
    Use that time as the timebase for your counter.
    Instead of sitting around waiting for the other PIC to send data use a handshaking or polling scheme so that you'll get the data when you're ready for it. This might obviously "push" the timing problem over to the other PIC but I don't know enough about your system to say. Even so I'm guessing it would be easier to it all in one PIC.

    Cars are way to messy, greasy and complicated for me. I enjoy driving them but mostly it's just means of transportation for me and I absolutely hate fixing, servicing and messing around with them. It's a good thing we're not all alike :-)

  6. #6
    Join Date
    Mar 2003
    Location
    Commerce Michigan USA
    Posts
    1,166


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

    Mugelpower, I would also like to help so, if you could please explain the whole project overview. Why do you need 2 processors?
    Dave Purola,
    N8NTA
    EN82fn

  7. #7
    Join Date
    Apr 2014
    Location
    OK
    Posts
    557


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

    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.

  8. #8
    Join Date
    Jan 2008
    Location
    Selm, Germany
    Posts
    116


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

    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.

  9. #9
    Join Date
    Jan 2008
    Location
    Selm, Germany
    Posts
    116


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

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

    I hoped PBP3 Gold had swallowed up these advantage.

  10. #10
    Join Date
    Apr 2014
    Location
    OK
    Posts
    557


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

    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.

  11. #11
    Join Date
    Jan 2008
    Location
    Selm, Germany
    Posts
    116


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

    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.

  12. #12
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,516


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

    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.

  13. #13
    Join Date
    Jan 2008
    Location
    Selm, Germany
    Posts
    116


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

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

  14. #14
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,516


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

    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.

  15. #15
    Join Date
    Jan 2008
    Location
    Selm, Germany
    Posts
    116


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

    Hello Henrik,
    thank you for your suggestion
    here:

    '************************************************* ***************
    '* Name : PUMP16F88V1 *
    '* Test with 20-23 °C RB0 = HPWM out *
    '* Author : M.David *
    '* Notice : Copyright (c) 2018 *
    '* : All Rights Reserved *
    '* Date : 01.01.2018 *
    '* Version : AB sensor M12x1,5 *
    '* Notes : 16F88 kein LCD funktioniert halbwegs *
    '* : PORTA.0 analog IN 0-2V channel 0 *
    '* PORTB.1 Fan out PPORTB.0 Water pump out *
    '************************************************* ***************

    #CONFIG
    __config _CONFIG1,_EXTCLK & _WDT_ON & _LVP_OFF & _CP_OFF
    #ENDCONFIG
    Define OSC 20
    TRISB = %00000000

    Define ADC_BITS 8 ' Set number of bits in result
    Define ADC_CLOCK 3 ' Set clock source (3=rc)
    Define ADC_SAMPLEUS 50 ' Set sampling time in uSec
    DEFINE DEBUG_REG PORTB
    DEFINE DEBUG_BIT 2
    DEFINE DEBUG_BAUD 19200
    DEFINE DEBUG_MODE 0
    DEFINE DEBUG_PACING 500

    define CCP1_REG PORTB 'für HPWM
    DEFINE CCP1_bit 0 'HPWM port B.0


    TRISA = %11111111 ' Set PORTA to all input
    ADCON1 = %00000010 ' Set PORTA analo
    CMCON = 7 ' Disable analog comparator
    ANSEL = %00000001 ' set AN0 (RA0) as analog, others to digital




    FAN VAR PORTB.1
    Uin VAR Word
    Temp Var word
    speed var word
    Pump var word
    RX var word
    RS var word
    B0 var word

    Speed = 0
    FAN = 0
    pause 1000
    DEBUG 10,13

    main:

    ADCIN 0,Uin ' Read channel 0 (RA)

    DEBUG "*.*",DEC3 RX,dec3 RS,dec1 FAN,13,10 ' dec3 is important
    DEBUG 10,13
    HPWM 1,speed,2442

    IF Uin => 64 then
    B0 = Uin/2
    Temp = 100-B0
    else
    Temp = 131 - Uin
    endif
    TEMP = Temp-5 ;Korrekturfaktor nach Kalibrierung Anzeige ok bei 75-90°C


    RX = TEMP
    RS = pump


    Select Case temp
    Case is < 67
    speed = 0
    pump = 0
    case 68, 69, 70, 71, 72
    speed = 8
    pump = 3
    case 73, 74
    speed = 16
    pump = 6
    case 75, 76
    speed = 32
    pump = 12
    case 77, 78
    speed = 64
    pump = 25
    case 79, 80
    speed = 124
    pump = 50
    case 81,82
    pump = 75
    Speed = 191
    case is > 80
    speed = 255
    pump = 100
    End Select

    IF (Temp <= 84 ) then
    FAN = 0
    else
    FAN = 1
    endif

    goto main

    END ' End of program

  16. #16
    Join Date
    Jan 2008
    Location
    Selm, Germany
    Posts
    116


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

    Here three pics of that housing and so on:Name:  Pumpcontroller1.png
Views: 419
Size:  735.0 KBName:  Pumpcontroller2.png
Views: 397
Size:  700.4 KBName:  Pumpcontroller3.png
Views: 429
Size:  762.8 KB

  17. #17
    Join Date
    Mar 2003
    Location
    Commerce Michigan USA
    Posts
    1,166


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

    Mugelpower, I would also like to help so, if you could please explain the whole project overview. Contact me directly via, [email protected] or private email to this site. I have designed N.O.S. controllers for Bracket racers and timing equipment for National Drag Boat Association here in the US. I'm getting ready to retire from current job and need something to do with my spare time...... Been working with PBP for 20+ years.... BTW, I like the Billet housing...
    Dave Purola,
    N8NTA
    EN82fn

  18. #18
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,516


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

    If that's the complete code for the '88 it does not seem to be the culprit after all....

    The message being sent is 12 bytes, that's 6.35ms @19200 baud, then you have 500us pacing so that's Another 5.5ms for a total of around 12ms. There's nothing else in there that should be taking any considerable amount of time.

    Do you have a scope? Can you verify the speed at which the '88 is actually sending messages? It looks like it should be in region of 80Hz...

    /Henrik.

  19. #19
    Join Date
    Jan 2008
    Location
    Selm, Germany
    Posts
    116


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

    Hello Henrik,
    i used a scope and found out that the 16F88 program runs with about 60Hz.
    So the 18F1320 doesn´t have to wait too long.
    The 18F1320 program runs much slower. If I count only 50ms it runs 16Hz. with 100ms it runs 8Hz thats too slow.
    50ms count is too short to count while cranking.
    So i set it up to 75ms.
    The 18F1320 program now runs at 11 Hz. So I call it a day.
    I guess the LCD routines gobble up much time.
    I put in some IF-THEN commands that showed hardly any effect in slowing down.
    I´ll try modifiing "DEFINE LCD_COMMANDUS 1500 "
    maybe that can speed things up a little bit.

  20. #20
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,516


    Did you find this post helpful? Yes | No

    Default Re: High priority/low priority program parts

    So, now you're saying it does - sort of - work? No more 300ms delays?

    Regarding the LCD: You can try tweaking the default 1500us setting but it's highly dependant on the specific LCD module you're using.
    I suspect most of what's on the LCD is static text. If that's true you might gain a fair bit of time (and a much better appearance on the LCD) by just updating the part of the LCD that's actually changing.

  21. #21
    Join Date
    Jan 2008
    Location
    Selm, Germany
    Posts
    116


    Did you find this post helpful? Yes | No

    Wink Re: High priority/low priority program parts

    Hello Henrik,
    I set the baud rate to 38400, that helped a bit.
    Then tried set the LCD_COMMANDUS to 1500 that gained hardly anything but made the LCD a bit unreliable.
    The count time is down to 75, 50 is loo little, i get no signal when cranking,100 slows the routine cycle down to 8Hz.
    Now I got the frequency of a complete routine up to 11.5 Hz.
    I guess that should do.
    Now I´m back into hardware, soldering and juggling tools, after that testing with real electric motors.
    Noise suppression is a real challenge in car electric.

    I appreciate your help and the help of all of you folks.

Similar Threads

  1. DT lOW PRIORITY INTERRUPTS - ASM WARNING
    By longpole001 in forum mel PIC BASIC Pro
    Replies: 2
    Last Post: - 6th September 2014, 01:56
  2. Programme Flow Priority ?
    By gunayburak in forum mel PIC BASIC Pro
    Replies: 4
    Last Post: - 10th August 2014, 00:20
  3. Replies: 4
    Last Post: - 24th January 2014, 20:38
  4. Priority interrupt?
    By Qacer in forum mel PIC BASIC Pro
    Replies: 6
    Last Post: - 6th October 2006, 17:47
  5. Can you give varied levels of priority to blocks of code?
    By Archangel in forum mel PIC BASIC Pro
    Replies: 7
    Last Post: - 12th August 2006, 02:58

Members who have read this thread : 2

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts