Interrupts .....

[Model T101]

Hello again,

             I would appreciate the experience of those on the site with a certain type of functionality i am trying to include in a program.

Basically, i have written a program to control the movement of a robotic arm via signal pulses sent to a series of dc stepper motors controlling the various joints.
the program interfaces with a numeric keypad such that when a key is pressed, the appropriate subroutine is executed (and the arm moves in a certain direction)

The keypad is scanned for detection of any key press that is made.

The hardware includes a PIC16 microcontroller which controls the motors.

The thing is, the program scans the keypad all the time ... i don't want it to do that really. It should only do it when the keypad is being used. If the keypad has been inactive for a while (no key has been pressed). then the keypad should 'rest' as it were.

I have been reading about the 'Interrupt' and 'Sleep' commands .. and i have figured that i could use them (based upon what i have read about their properties) .. in such a way that the keypad would be dormant when not in use (in sleep mode), but upon pressing a certain key on it ... an interrupt would fire which would then make the program commence scanning the keys.

After a period of time has passed and the scan has detected no further pressing of the keys, it should go back into sleep mode until the next time again.

problem is ... i am not fully confident as to how to implement this within my code. (the program as it is, works fine though)

I am using PORTB for my keypad and PORTA for output signals to the robot's motors

I have a spare pin on PORTB that i do not use (RB0), which i understand supports interrupts. I am just clueless as to what to do from here as i do not want to mess up my code which works fine in it's present state.

Just don't think that scanning the keys all the time (even when not in use) is practical really.


Any suggestions would be appreciated.

Thanks in advance.

[FORTRANS]

Hi,

   I don't have any direct experience with PIC16, so this may
be (probably is) off a bit.  But with an X86 DOS environment
the process would be something like:

   Get the code working;
   Hook/get the interrupt vector and point it to the routine in
your code, probably chain to the old handler;
   Go to sleep.  In DOS that is a halt loop or calling Int 28.

   Then the processor is, more or less,  halted until an event
wakes it up.  Of course, if you need to respond to more
than one kind of event you need to hook more than one
interrupt, or have your halt loop look around after an interrupt.

HTH,

Steve N.

Code Select Expand


; Set up everthing!

GoToSleep:
        HLT             ; Halt until interrupt, when your interrupt
                        ; routine takes over.
        CMP     [Die],0FFH
        JNZ     ByeBye
        JMP     GoToSleep

ByeBye:
; Clean up and exit.


[redskull]

On (most) PIC's, there is only a single interrupt pin and a single routine to handle it (ISR); your mileage may differ, depending on the exact chip you are using.  This is a lot different than a Intel, which has an entire seperate chip to handle dozens of interrupts, each with their own handler (the Programmable Interrupt Controller, also refered to as a 'PIC', not to be confused with the PIC microcontoller).  IIRC, the ISR must be placed in memory at 0004, which means your code usually must begin with a jump to skip over it.
In any case, you ensure that the global interrupt flag is enabled, as well at the external interrupt flag (bit 3 and 4 of the INTCOM register?), and then everytime the signal is received, the program will jump to the code at 0004.  Then, in the ISR, just preseve anything you change, clear the interrupt flag, and handle the keypress.  Again, every single PIC is a little bit different, so check the datasheet for the specifics

-r

[dedndave]

it sounds to me like the hardware is using the PIC as the keypad mux/demux
if that is the case, you would have to replace that with circuitry to do what you want
we really don't have enough info - a schematic would be required

i am just guessing, but i think i would call it good the way it is   :P

[BlackVortex]

I want to see a picture of the robotic arm and keypad !

[Farabi]

Hi, if your robot arm is attached to some port you only need to send OUT and IN command.
Have a look about IN and OUT instruction. Your project seems to be insteresting, would you mind to share your knowledge?

You may build your own OS or use existing one that able to use IN and OUT instruction, I guess you can alter Linux OS. XP will not allow you to use that instruction except you use a dll where I forget about the name.

[Farabi]

I hope your robotic arm is as simple as this

Code Select Expand


Mov edx,JOINT_A
mov eax,Degree_you_want
out dx,al


If so, maybe you can tell me where I can buy it?  :green Just ask.

[BlackVortex]

I did a little reading around the net about programming microchips, and it seems great. I'd like to buy a PIC16 and program it etc, but what hardware would I connect it to ?

I'm not good with circuitry etc   :'(
Isn't there a kit or something, with some simple toy-vehicle controllable by chip ? Or some specialized forum about this stuff ?

[redskull]

Microcontrollers are the most fun you can have with your clothes on  :U  Google around for "PIC Development Boards"; they are a little pricey, but they come with all the peripherals you need to program them, easy ways to connect them to breadboards, and can be powered straight from normal means.  Some good places to start looking for parts are newark, digi-key, and allied electronics (make sure you get a DIP version, lest you won't be able to solder it).  The canonical examples are LED projects, lighting them at given intervals, etc, but USB specific microcontrollers make a fun rainy day project too... :bg

-r

[dedndave]

i had a "fun" project for a job about 10 years ago
i worked for a company that made LCD type displays
we made one that was actually a high-tech LED array called HCLD
this particular version of the display was on flex
it was intended for cell phones - good power efficiency, no back-light needed and you could read it in the sun
anyways, i was assigned the task of making a demo unit that looked like a cell phone
motorola gave us several empty cell phone cases to use
the only thing that made it "not fun" was that i had 30 days to do it - lol
anyways, i used a 12 MHz 8051 - designed a special circuit board and wrote the software
had some custom NiCd batteries made
it worked great - would flash several scrolling screens of data - i could make it say whatever i wanted of course
30 days to the date, i had 6 working units
i worked on the hardware at work during the day and worked on the code in the evening at home   :bg

[BlackVortex]

Microcontrollers are the most fun you can have with your clothes on  :U  Google around for "PIC Development Boards"; they are a little pricey, but they come with all the peripherals you need to program them, easy ways to connect them to breadboards, and can be powered straight from normal means.  Some good places to start looking for parts are newark, digi-key, and allied electronics (make sure you get a DIP version, lest you won't be able to solder it).  The canonical examples are LED projects, lighting them at given intervals, etc, but USB specific microcontrollers make a fun rainy day project too... :bg

-r

Thanks for info. So, if I get a PCB, like this :
www.olimex.com/dev/pic-p40.html

and a MCU, like this :
www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010336

then I need a programmer, like this :
www.olimex.com/dev/pic-pg2.html

Right ?

[dedndave]

that looks like a very sensibly priced way to go   :U
it has been decades since i played with a PIC16 - lol
i think it was 1978 - i worked for General Instruments in Chandler
unfortunately, i didn't get to spend too much time on the PIC - the other guys seemed to enjoy it and hogged all that stuff - lol
i got to do a little of it - especially the hardware end
for the most part, i was stuck making test fixtures and code for the memory, calculator and game chips
i did get payed to play a lot of "Tank", though - lol

[redskull]

My only issue with the dev. board is that, at first glance, there doesn't appear to be any easy way to connect elements to the individual port pins; soldering wires on and off the PCB can be a real pain.  It's a godsend to have it rigged up to a pin header (or even a breadboard) for quick connections and disconnections.

-r

[dedndave]

that is true
but, it is an "any-board" PCB
probably room to add 7-segment decoder/driver and display if you wanted to
you could have a hex digit for each port
maybe simpler to write a little program to display the values, though   :bg