+ Reply to Thread
Results 1 to 21 of 21

Hybrid View

  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,185

    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

    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

    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.old metal.jpg
    Attached Images Attached Images

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

    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,057

    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
    Northeast
    Posts
    181

    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.

Similar Threads

  1. DT lOW PRIORITY INTERRUPTS - ASM WARNING
    By longpole001 in forum mel PIC BASIC Pro
    Replies: 2
    Last Post: - 6th September 2014, 00:56
  2. Programme Flow Priority ?
    By gunayburak in forum mel PIC BASIC Pro
    Replies: 4
    Last Post: - 9th August 2014, 23:20
  3. Replies: 4
    Last Post: - 24th January 2014, 19:38
  4. Priority interrupt?
    By Qacer in forum mel PIC BASIC Pro
    Replies: 6
    Last Post: - 6th October 2006, 16: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, 01:58

Members who have read this thread : 17

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