Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Interrupt routines [re: 8051]

Status
Not open for further replies.

mstechca

New Member
After realizing that setting or clearing a port pin can cause an interrupt to occur, it makes LCD programming much easier.

BUT, I have a question.

According to an 8051 manual, If the interrupt for "external interrupt 0" is activated, it states that the program will jump to 0003H. I would assume this is an absolute address since the 8051 can't go past 64K (FFFFH).

It also states that if the interrupt for "external interrupt 0" is activated, the program will jump to 000BH.

Assuming that all interrupts are active, I only have 8 bytes between 0003H, and 000BH for the external interrupt 0.

If I stored a vector address (where the information between 0003H and 000BH points to an address in external memory), then 4 bytes must be all zero's.

But then if I stored actual code in this space, I don't know if the "jumping" code will actually fit, since I need to use a IRET instruction.


Should I just store an address from 0003H to 000BH where the 000BH is the LSB?
 
The internal hardwired vector for INT0 is at absolute address 0003H. What usually goes at that location is a two byte AJMP if the destination is with 2K or three byte LJMP is the destination is further way.

The internal hardwired vector for Timer0 is at absolute address 000BH. The same rule applies. The rest of the interrupts in a particular 8051 variant are assigned to 13h, 1Bh, and so on.

There are some clever souls that actually use the eight bytes between those vectors to write a simple interrupt service routine. The rest of us just let those bytes go to waste.

If an interrupt is actually unused, people often put in a two instruction sequence that sets the specific interrupt enable to 0 (disabling it), followed by an iret. This effectively ignores unused interrupts, and prevents a program from going off into the weeds if one of the interrupts is inadvertently enabled, and there is no code at the hardwired vector location.
 
mstechca said:
After realizing that setting or clearing a port pin can cause an interrupt to occur, it makes LCD programming much easier.
And why is that???
Which pin of the LCD are you intend to connect to INT0 (1) pin??
An LCD have no digital output pin that you can connect to a interrupt pin of the 8051!!
So again: Why is your programming easier??

Is this still for writing 'Hello world' on your LCD??

When using NORMAL programming tools you don't have to worry about these low level things. Just declare code for an interrupt routine and your compiler will write the correct calls at the correct location...

But you're a creative guy ... ...
 
mcs51mc said:
Which pin of the LCD are you intend to connect to INT0 (1) pin??
At that time, I was going to have an external clock that is slower than the processor clock drive the interrupt pin, so that when an intertupt is generated, the LCD will write character for character.


Is this still for writing 'Hello world' on your LCD??
yes

When using NORMAL programming tools you don't have to worry about these low level things. Just declare code for an interrupt routine and your compiler will write the correct calls at the correct location...
thats if the compiler works great, and you go by their commands.

Actually, my "hello world" routine is much better now. I made the LCD processing code in a subroutine, and now all I do is feed whatever I want to see on the LCD into the ram space (30h to 79h), and call the routine, and the correct data is displayed.

Perhaps I should show my code.
 
RAM is definitely not the right place to store messages to place on an LCD!
Now you reserved 73 bytes in RAM for LCD messages :shock: :shock:
And that for a guy that want to write the smallest code possible :?
You see it completely wrong: In RAM you have to care about every byte not in program memory.
Do you have a 73 characters LCD?
If in your next project you use a 4 lines, 40 char LCD what will you do?

Where is your stack located?
Before or after that LCD block?
Remember you don't know the length of the stack, it varies depending in calls and what you put on the stack. You can be pretty sure that one day your "Hello World' message will be overwritten by the stack.

You better place all your messages in code memory and access them using the datapointer. You wanna know how? Tell me and I explain it to you...

A last thing about compilers. The only compilers that doesn't work are the self-made ones because they are not thoroughly tested. Only what one guy tried is tested not all other things that can go wrong.
I use ASM51.EXE for several years now and I can assure you that all the times my code didn't do what I expected it was because I oversee something :oops: not because a compiler error :D
 
mcs51mc said:
I use ASM51.EXE for several years now and I can assure you that all the times my code didn't do what I expected it was because I oversee something :oops: not because a compiler error :D

Presumably ASM51.EXE is an ASSEMBLER?, and not a compiler, VERY different things.

An assembler is a fairly simple program, and shouldn't really have any errors that affect it's operation, I would sincerely expect it to do a FAR better job of changing source code to machine code than a human could do (both of course should produce EXACTLY the same HEX file). In mstechca's case I would expect it to be a great deal better, as he doesn't bother reading datasheets, other peoples code, or even paying attention to what he does read!.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top