Gaps In Knowledge

[gez]

I've been studying PIC programs in various back issues of EPE mag etc I've collected over the years - bit like looking at schematics - to find out how certain things are done.  I keep seeing bits of code that never seem to get explained in text books etc and not even in data sheets (well, they're not in the index).

Example:

                       ORG           0X000
start                goto    init                ;reset vector

                       ORG           0X004
noint                goto    init                ; interrupt vector

there then follows the instructions for initialisation.

I keep seeing ORG, but what the hell is it and what does it do?  I haven't been able to find anything about it by googling (maybe I'm searching using the wrong terms?) and although it's in all the program examples in one of my text books there's no explanation.

Also, in the above example why is there a 'noint'?  Is it there in case the thing fails to initialise first time??  Why does it have a different ORG value???

I have other headscratchers, but these will do for the time being! 

PS  Keep explanations simple please!

[bioroids]

Hi!

This is just speculation based on what I read about AVRs and previous knowledge on 8086 assembler:

noint means number of interruption or something like that, and it's only a label.
After the reset vector (thats where code starts to execute when the chip resets) comes the interrupt vectors (where the code jumps when a given interruption raises). The ORG is probably a compilator directive, and the number (0x000, 0x004) means the position in program memory (apparently the goto instruction is 4 bytes long). You can have several interrupt vectors (or none) and then comes the main code.

Now this is the part when someone who actually knows tells us what is this stuff really  

Luck!

Miguel

PS: I just received my STK500 kit on the mail! 36U$S including shipping (used, I bought it on a online auction site)

[Peter Snowberg]

Very god questions. 

ORG stands for "ORiGinate". You use that assembler directive (note: not an instruction) to tell the assembler the memory address that you want to start assembling code at. In the start of a program, ORG 0x0000 tells the assembler to start at the beginning or program memory. You have to start somewhere right?

Very often, the beginning or end of the uC program space contains a series of special use addresses called "interrupt vectors". The first one is often the RESET vector, where the uC jumps upon a RESET "interrupt" occurring. In this example, RESET is at $0 and it contains a jump to the first line of the real code, which is placed after the interrupt vectors. The second ORG tells the assembler to start putting code at location $4 which is where this uC will jump when it receives an interrupt. This code apparently does not use interrupts because it contains a jump to the same location that RESET jumps to. I think that is why the label is called "noint"; because there will not be any interrupts for this code to deal with. The jump at $4 is simply to make sure that IF an interrupt occurred for some reason (cosmic radiation from the Sun, radioactive decay of ¹⁴C in the encapsulating epoxy, or Elvis), the uC will simply restart instead of crashing.

Keep those questions coming.

[gez]

Keep those questions coming.

Don't worry, I will!!

Thanks for the replies chaps.  I think I understand but need to do a little reading on interupts.  I've been learning things on a need to know basis and the chapter covering this area is one of the few I've skipped so far.

Will be back soon I'm sure! 

[gez]

The jump at $4 is simply to make sure that IF an interrupt occurred for some reason (cosmic radiation from the Sun, radioactive decay of 14C in the encapsulating epoxy, or Elvis), the uC will simply restart instead of crashing.

OK, I've done some reading and have got it now.  There aren't any interupts in this particular program so the code is acting as a failsafe.

Is there any point putting it in though?  I mean, if Elvis does come back (heaven forbid) wouldn't just turning the PIC off then back on again start things up again?  I can see that in some situations this would be unsatisfactory, but how likely is the device to crash?  Or am I missing something?

[Peter Snowberg]

Computers do crash and Elvis aside (yeah, like it's not him every time), you do have serious effects from cosmic radiation and the decay of radioactive carbon-14 in the potting epoxy. The world just isn't perfect. There are semiconductor fabrication techniques called "Rad-Hard" that reduce these effects. Airplane auto-pilots, missile guidance systems, and nuclear instrumentation are places you can't afford to get false readings but the processes are expensive so it takes things like this to justify the cost..

PICs are embedded controllers and an embedded system that's a little bit unreliable is like a woman being a little bit pregnant.

You always want to cover all the possibilities you can, so you have to make a conscious decision to make your system less reliable if you want to leave out the fail-safe jumps in the vector table.

Microcontrollers contain a timer called the "watchdog". This is a counter that will cause a system reset if it ever times out. The idea is that when your program in running properly, you can just keep resetting the counter so that it never runs out. If your code gets stuck in an infinite loop or the chip temporarily goes odd from ionising radiation and crashes, the counter stops being reset which eventually causes the chip to be reset.

It happens. You need to deal effectively with it. 

[gez]

Thanks for your input Peter, much appreciated.

[R.G.]

Good advice, Peter. Let me extend it one more step. One of the most confusing, potentially project-killing things that can happen in uC development is not explicitly either programming the watchdog timer and using it, or explicitly turning it off.

Having your uC periodically resetting itself for no (apparent) reason is sanity threatening.

[Dave_B]

Having your uC periodically resetting itself for no (apparent) reason is sanity threatening.

As I've mentioned, it really knocked the wind out of me.  In my experience, it throws the timing off just enough to make the circuit unusable in a critical setting. 

On that topic, can anyone speak to the debugger in the STK500?  I don't have any experience using debuggers and I'm curious if the one on the STK500 will help prevent the madness R.G. writes about.

[The Tone God]

On that topic, can anyone speak to the debugger in the STK500?  I don't have any experience using debuggers and I'm curious if the one on the STK500 will help prevent the madness R.G. writes about.

The STK500 is just a programmer and development board. It is not really a debugger. Are you talking about the software simulator ? If so then you can observe the watch dog timer to make sure it plays nice.

Andrew

[R.G.]

There are really only two ways to deal with watchdog timers:
1. Explicitly check for an make sure that the watchdog timer is turned off by the setup configuration when you program a part.
2. Program for and handle watchdog timeouts.

Anything else is just wishful thinking.

[Dave_B]

On that topic, can anyone speak to the debugger in the STK500?  I don't have any experience using debuggers and I'm curious if the one on the STK500 will help prevent the madness R.G. writes about.

The STK500 is just a programmer and development board. It is not really a debugger. Are you talking about the software simulator ? If so then you can observe the watch dog timer to make sure it plays nice.

I was thinking about ICD's.  I don't know much about them, so maybe I'm on the wrong track.  I wasn't having any luck duplicating the glitch on the PIC simulator.  I thought an ICD would be the next step. 

By the way, my post sounded a little smartass when I read it back just now.  R.G. if you're reading, I in no way meant it like that!

[R.G.]

No, I took no offense.

I have used ICDs. I find that they're most useful when you have not followed the "string of pearls" development process I outlined, or when you did not write the code you're debugging.

My experience with PICs has been that If you start with a PIC and a plugboard and write, then test one subroutine at a time using LED indicators on the board, you mostly don't need ICDs or simulators. They're nice sometimes, but I don't use them much anymore. If I felt the need for some isochronous code, maybe.

ICD's are great if you are in the middle of one of the messes I mentioned. If it absolutely, positively has to work, and you haven't or can't take the time to do incremental development, then they may be your only saviour. I just hate to assume ahead of time that I'll do that to myself.

[The Tone God]

I was thinking about ICD's.  I don't know much about them, so maybe I'm on the wrong track.  I wasn't having any luck duplicating the glitch on the PIC simulator.  I thought an ICD would be the next step.

The STK500 is not a ICD atleast not without extra hardware. There are ICDs for AVRs but they cost more money and to be honest unless you doing something massively complicated, need to test in real time, or are on a razor thin deadline you don't need it. It is not a magic wand that is going to save you from bad coding and testing habits.

You may or may not know it but you are now starting to quitely develop your debugging skills which funny enough may end up teaching more then most text can, well except the datasheet of course. You have to learn to break down your code into functional bits and test each part then slowly reintergrate each bit making sure every piece is playing nice with the other pieces. I belive a few of the Microcontroller Commandments come into play now like:

"Thy will make use of an attached LED for debugging purposes. If Thy's design does not include an LED thy will keep atleast one output line available for an LED."

"Thy will check all fuses and other preprogrammed settings at the start of every new program and uC installed."

"Thy will only make one change per debug cycle."

"Thy will only enable one piece of internal hardware at a time and will not enable anymore internal hardware until the current piece of hardware is functioning fully."

Back to the topic of watch dogs and AVRs Atmel I belive ships AVRs with the timer on but the interupt is not enabled. You have have to enable the interupt yourself manually through a specific sequence otherwise it is not in play. To be honest I don't enable watch dogs until the end just so I don't have to worry about them.

Andrew