Hey everyone.
A recent project of mine has forced me to search for a way to be able to constantly check if any input pins are high, and if they are, carry out a routine. I figured that microcontrollers are not sophisticated enough to have multithread capabilities that one may find in computer programs, however I now feel that it is crucial for my project to be able to constantly check the input pins, as opposed to calling a sub routine that checks if they are high every other line.
My fix for this problem would be to simply have another microcontroller that listens to the input pins, and if one goes high, it sends an output to the main microcontroller, to let it know that a button has been pressed.
I am wondering if this is necessary or not. Do I need two microcontrollers for what seems like a simple problem?
6 replies to this topic
#1
Posted 06 September 2010 - 09:09 PM
|
|
|
#2
Posted 07 September 2010 - 09:54 AM
threading is done in software. Since the pics don't have an instruction to pop and push on stack. You have to write your own save and restore routines. Look at a thread as a subroutine that manages its own memory and location in stack. If your running two threads, one will check for input and have its own memory locations it uses to store info and its location in the stack. On every loop your going to save everything the subroutine is doing plus the location on the stack into ram. Then you run the second thread(subroutine) and do what it needs to do for one loop.After its done doing what it did, then you save everything its working with and go back the the other thread. At 4mhz this looks like there running at same time. Some sudo for you :D
thread1
check for high pin
if pin is high
call thread2
if not goto thread1
thread2
restore values from ram ;If this routine has been ran before
process the input ;process the old values with the new values
check if password is complete ;check if enough input has processed in order to deactivate lock
if yes, goto unlock subroutine
if not, save values to ram
goto thread1
Not the best tutorial but it should point you to new concepts. If anyone can make correction please feel free.
thread1
check for high pin
if pin is high
call thread2
if not goto thread1
thread2
restore values from ram ;If this routine has been ran before
process the input ;process the old values with the new values
check if password is complete ;check if enough input has processed in order to deactivate lock
if yes, goto unlock subroutine
if not, save values to ram
goto thread1
Not the best tutorial but it should point you to new concepts. If anyone can make correction please feel free.
#3
Posted 07 September 2010 - 03:12 PM
Wow this is almost exactly what I was doing already. So i was on the right track, but i need to know how to declare a binary value.
COUNT4 equ 09h
then do i just assign a null binary value to it? b'00000000' ?
Because if this is true, I could simply tell the pic to increment the value each time the correct button is pressed, however this doesn't take care of my problem of checking if any other buttons are pressed.
COUNT4 equ 09h
then do i just assign a null binary value to it? b'00000000' ?
Because if this is true, I could simply tell the pic to increment the value each time the correct button is pressed, however this doesn't take care of my problem of checking if any other buttons are pressed.
#4
Posted 09 September 2010 - 02:24 PM
Threading is a software only implementation, so it is theoretically possible to use threads in a PIC. However the scheduling code and resources needed are prohibitive for a PIC microcontroller, and you should have to write all the logic to handle the threads (not a trivial task).
If you do not have to do any other processing while waiting for the input signals, I think the best option is to continously poll the input lines status. This is very fast and easy to program. If you need to do something else while waiting, you should use interrupts to detect the input lines changes (I think PICs can throw interrupts when some I/O lines change its value). It's a bit harder to program than the polling, but simpler than threads by far and it's very efficient.
If you do not have to do any other processing while waiting for the input signals, I think the best option is to continously poll the input lines status. This is very fast and easy to program. If you need to do something else while waiting, you should use interrupts to detect the input lines changes (I think PICs can throw interrupts when some I/O lines change its value). It's a bit harder to program than the polling, but simpler than threads by far and it's very efficient.
#5
Posted 09 September 2010 - 04:21 PM
So for an interrupter, I can simply call a subroutine right? For example, if I have a main sub, it checks if RA1 is on. If it turns on, I call a button check(sub routine), then goes back and forth from checking if RA2 is on, and if any other button is on. If a button is on, I go to the start of the main sub.
Would this work? Is there a better way to do this?
Would this work? Is there a better way to do this?
#6
Posted 09 September 2010 - 10:33 PM
That's polling. An interrupt runs completely asynchronously. When it fires, it stops your program, saves its state, and executes the interrupt handler. Once the handler returns, it restores the original state and resumes execution.
sudo rm -rf /
#7
Posted 09 September 2010 - 11:44 PM
An interrupt is a hardware assisted facility that allows you to react instantly to some external or internal changes (like a change in an input signal). Each microcontroller has its own interrupts. You should read your microcontroller's datasheet to know what it can do.
You may see the interrupts like a very simple and primitive threading model. You have your main thread running doing something, and another thread waiting for each possible interrupt. These other threads will run when the condition than raises the interrupt is satisfied, stopping temporarily the primary thread. Once the interrupt thread has completed its work, the main thread will resume its execution.
You may see the interrupts like a very simple and primitive threading model. You have your main thread running doing something, and another thread waiting for each possible interrupt. These other threads will run when the condition than raises the interrupt is satisfied, stopping temporarily the primary thread. Once the interrupt thread has completed its work, the main thread will resume its execution.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users


Sign In
Create Account


Back to top









