6 hours for a comma, a space, and some caps.....

Printable View

- 11th March 2009, 14:18
boroko

6 hours for a comma, a space, and some caps.....

I'm not sure if this will aid anyone, but I do feel the need to expose my own stupidity and hopefully make it easier for someone else.

The situation was this: I had a couple of software modules that were pretty much working on an '877A. I knew that I would need the power of an 18 series device, to I tried to move them over put them together on a 18F1230 after some clean up.

This is the first time I have used an 18F, and it uses Darrel's DT_INT so I expected that there would be a few pains.

Loaded up everything and changed the INT includes to the -18 versions. Tried to compile and got a bazzillion errors! The really fun part was that the errors were showing on MCS in lines that were in the 1400 range. My main program was only about 550 lines long,...hmmm. Started looking through DT_INTS-18.bas and ReEnterPBP-18.bas. They were 954 and 245 lines respectively. Were to look? Darrel's .asm in INTs started to make me even more confused. There were conditions for a 18F1230 that were different from the others. More issues! I had composed a post for the forum (which I loath doing) and tired to lay out the situation without sounding too stupid.

In the process of laying out the post, it occurred to me to try to strip almost everything out except the most essential lines. I opened it in a side-by-side comparison. I started to notice a few things. It wasn't the special configuration of the 1230, it wasn't the overwhelming 312 page datasheet or even the change to using -18 of DT_INTS.

The problems turned out to be all right here

Code:

ASM INT_LIST macro ; IntSource, Label, Type, ResetFlag? INT_Handler TMR1_INT, _Transmit, PBP, yes INT_Handler TMR0_INT, _BlankGain, PBP, yes INT_HANDLER CMP2_INT _ GetEcho, PBP, yes endm INT_CREATE ; Creates the interrupt processor ENDASM

There are three errors that I let slip in there. they caused an unbelievable number of errors that I had no idea how to find.

I guess the moral of the story is this. Even if you are not completely understanding everything, there are ways to coax problems to show themselves. Just minimizing all of the distractions helped me divide and conquer. I thought I had worked out the modules and figured that the migration would be the issue. Turns out that it was just the simple stuff.
Keep trying!

and, yes, I realize that I haven't explicitly explained the errors, I wanted to "share" the learning opportunity.

Bo
- 11th March 2009, 16:38
Navaidstech

Bo...

don't sweat it. I'm sure we've all been there at one time or another.
I've been down that road before and best advice I can offer is this: walk away from it for a while (ie. go take a nap, walk, or something) then get back into it with a fresh mind - the mistake will stick out like a sore thumb.

:)

just my $0.02

Alex
- 11th March 2009, 16:49
Chris Barron

Quote:

Originally Posted by boroko

I'm not sure if this will aid anyone, but I do feel the need to expose my own stupidity

The problems turned out to be all right here

Code:

ASM INT_LIST macro ; IntSource, Label, Type, ResetFlag? INT_Handler TMR1_INT, _Transmit, PBP, yes INT_Handler TMR0_INT, _BlankGain, PBP, yes INT_HANDLER CMP2_INT _ GetEcho, PBP, yes endm INT_CREATE ; Creates the interrupt processor ENDASM

There are three errors that I let slip in there.
Bo

Okay if you're being stupid, then I will have to expose my extreme stupidity (and curiosity) by asking you to explain what the errors were in the code, please !

I'm not familiar with this interupt technique but if i were to use it what should I be aware of ?
- 11th March 2009, 17:11
Archangel

Hi Bo,
Don't feel like the Lone Ranger, we all have that soft spot in our foreheads (see mister_e's avatar ). What you might try in this particular situation is copy Darrel's code, into the top of your's, rather than including it, then "I THINK" MCS will compile and give you accurate line number info for the error. 
Chris:
extra space between int_list and macro, missing comma after CMP2_INT, MPASM is fussier than your 5th grade English teacher.
- 11th March 2009, 18:55
ErnieM

6 hours is nothing, I spent most of a working week finding some missing brackets on CODE THAT COMPILED WITHOUT EVEN A WARNING.

(Note from user: bad code (syntax) should provoke a good compiler to say something.)
- 12th March 2009, 11:40
boroko

Hi All,
I was presenting all this primarily show that this kind of thing can really take you for a ride.

Navaidstech: I agree that taking a break gives you new eyes to look at things. It doesn't make up for my ignorance, but it usually helps me.

Chris: Joe S. explained the things that I missed. To amplify, the third was the capitalization of the third INT_HANDLER. As for the interupt technique, it is a macro that is at the heart of DT_INTS. If you haven't used it before, you may want to look at it. I was afraid to use interrupts before I found Darrel Taylor's program that simplifies the whole process. Absolutely wonderful piece of work.

Joe S: I hadn't thought of literally copying the code in like that. That is obvious once you think of it and definitely a "soft forehead" moment.

Those are the kind of thing that I was trying to pull out of the list by starting this. Maybe a thread where people are exposing the traps that they have fell into and the way that they got out of them. A place to go to reduce some of the noise on the list and improve all of our skills. Maybe the effort will keep the list from burning out the major contributors, so we can preserve their attention for the cool stuff.

I hope that someday, when I grow up, one of my posts will become a sticky. Then I will have arrived..... :D

Bo
- 12th March 2009, 16:04
Darrel Taylor

Quote:

I hadn't thought of literally copying the code in like that. That is obvious once you think of it and definitely a "soft forehead" moment.

Noooooo .... please don't do that.

That's my biggest pet peeve.
It's an Include module, not a cut&paste snippet.

And as you've already found out, the errors were in your code, not the include file, so it would have accomplished nothing.

Yes, you would have received errors with line numbers referenced to your main program file, but they would not have been any more informative since those lines would still not have pointed to the original problem. And now your main program is filled with stuff that looks like Russian or Chinese (a.k.a. ASM macros). Trying to find errors in your own code only becomes more difficult and confusing.

Then you end up editing something that shouldn't be edited and suddenly nothing works, and I get blamed again.

Put the Include file down and step away from the computer, before you hurt someone. :)
- 12th March 2009, 16:14
Archangel

Quote:

Originally Posted by Darrel Taylor

Noooooo .... please don't do that.

That's my biggest pet peeve.
It's an Include module, not a cut&paste snippet.

 

I meant it for troubleshooting only Darrel, not to steal your code. Of course the final cut must use it as "licensed" by you, as an include file.
- 13th March 2009, 02:31
Darrel Taylor

Quote:

Originally Posted by Joe S.

I meant it for troubleshooting only Darrel, not to steal your code. Of course the final cut must use it as "licensed" by you, as an include file.

Well, the only "License" is ... Yours to use as you see fit.

So it's just my own personal problem, wish, desire ... peeve.

I seem to be getting more of those, which are Directly proportional to the lack of color in my hair at any given time. :o
- 13th March 2009, 02:42
Archangel

Quote:

Originally Posted by Darrel Taylor

Well, the only "License" is ... Yours to use as you see fit.

So it's just my own personal problem, wish, desire ... peeve.

I seem to be getting more of those, which are Directly proportional to the lack of color in my hair at any given time. :o
 

Well Darrel, most of here are Gentlemen / persons. Your generosity has provided us all with talent, most of us do not have, and we are grateful. So the " license " is not to tick you off. Now as for hair color . . . at least you have some ! I encourage everyone to use the code you provided as you prescribed as includes. Copy past should be reserved for troubleshooting only, and the final cut should / must be as includes.
- 13th March 2009, 11:10
boroko

I have thought about it, and listing all of the code in sequence would not have pointed out my problem in this situation. It may have given me some idea of line number, but it would not have helped.

With that in mind, are there any better ways to help see these obscure problems?
The whole point of this thread was to help identify troubleshooting techniques.
In this case, the only thing that helped me was stubbornness and stripping things down until there was nothing left that could be wrong. Then I started adding back sections until the problem reoccurred. Case sensitive searches of the same variables pointed out the caps problem. Nothing brilliant, but things that I hadn't thought to do right away. Oh, that.... and a bunch of luck.

Bo
- 13th March 2009, 19:11
Darrel Taylor

Quote:

With that in mind, are there any better ways to help see these obscure problems?

With the code from post#1, the first error you would have received would be ...
Found label after column 1. (INT_HANDLER).

That narrows it down to one of 3 lines in the program.
Technically, it points to the exact line, since it was the only one with INT_HANDLER in upper case.
Commenting the lines would have easily shown which one was the problem.

Often, it's not the line numbers in the error that give the best indications, but the (words in brackets) at the right end of the error.
And start from the top of the error list. The first one listed is usually the most important, and resolving that one frequently fixes many of the following errors too.
- 13th March 2009, 20:31
boroko

As a matter of fact,

Quote:

Found label after column 1. (INT_HANDLER).

was exactly what I saw first. The problem for me was that it referenced something like line 1400 and I had not noticed the caps problem. The line number tempted me to start looking in your program to see if I could get any hints of something that I hadn't done right. I hadn't for a minute thought that your program was at fault. I was more concerned that I hadn't passed a correct parameter. I saw that DT_INTS had special handling for the 18F1230 on it's comparator interrupt and started to wonder if it was a situation similar to the 8 pin devices where GPIO aliased to some other name. A few hours were spent in that loop until, in desperation I just stripped the bone and started to make some progress.

It was kind like "where's Waldo" for a while looking between the 2 copies until it started to become clearer.

Again, I'm trying to pry some tricks out of the group to elevate the process for the less experienced. I'm still one of them, but I'm becoming "less" less experienced. :D

Bo