Assembly programmers

[mke_et]

I was just wondering how many people here are using assembly programming as opposed to C or other languages.

The reason I ask, is that there seems to be a 'divide' between the C people and their forum needs and the 'hardware' people that isn't quite filling the needs of assembly programmers.

Ok, for example...  When I first started with the 9S12 it was with the '9S12 Badge' which came equipped with a 9S12DP256B part.  I got one at a 'seminar' on the Star12.  At that time, the 'rep' warned us about certain 'issues' with the Star12 series and 'tricks' we had to use to do certain things.  (I remember one of them was with lost com interrupts)  Anyway, I wrote my routines in assembly and I have yet to see the problem alluded to in the seminar.  So, I can't help but wonder if the problem is really an issue that the 'C' code was written to how the part was SUPPOSED to work in developement, but my assembly was written to how the part actually DOES work from the spec sheets.  Does that make sense?

Also, I don't use ANY of the templates or other tools in CodeWarrior.  For that matter, I'm running CodeWarrior SE.  The 'early' one that came with the BDM pod.  Originally I was running 1.0, and the ONLY reason I upgraded to 3.x was to get support for the USB-BDM pod.  It also sorta forced me to upgrade my CW 2.0 that I was using for some KX8 stuff.  Well, I 'could' have stayed with CW2.0 for the KX8, but I took the opportunity to upgrade that as well, even though I still have to use the LPT interface for the MON08-MultiLink. 

Another issue is interfacing.  I did my own flash and NVRAM routines.  In assembly of course.  And even I2C routines.  (I'm using a different version part on another project and when it came time to do the I2C, I just wrote my own routines for it so I could develope the original code with my old badge wire-wrapped to a prototype.)

Bottom line is that I think there's a bit of a different 'mindset' for the assembly people than the C people, and just wondered how many other people do assembly programming here.

Mike

[mke_et]

Thing is, I don't see the SCI problem.  Never have.  And I run both com channels on my design.  Don't see a problem.  And one of them I REALLY beat.

But then, I probably write my code with a far greater margin for screwups.  I'm 'old school', having had to write code for 8259 and 8530 implementations.  So I always coded with a 'flavor' of letting the interrupt trigger a process, and then also be able to handle an interrupt that didn't really happen.  (Something even the IBM BIOS didn't do right!)  How many people even knew that the 8259 would give IRQ7's when it couldn't figure out what pin generated the interrupt?  And how many people knew how to check the 8259 for 'in service' if it was slaved?  Hey, I'm not saying the FreeScale are error free, but to me even a gross error, if documented, is OK compared to what I had to 'figure out' back then. 

[imajeff]

mke_et,

I'm wondering if you would like to see the problem, or you are more-so just bragging that you didn't see the problem :smileywink:

It is easy to see it if you want to, and fully understand what the problem is. I definately saw it when I downgraded to maskset 1K79X after developing an app which uses interruts and multiple SCI ports heavily. Just that some apps will never see the problem because it's not in the design.

I might clarify the SCI errata:

* Polling flags would not see the problem, and definately could cause the problem to not be noticed. That is a suggested workaround.
* The problem is not seen between two different SCI ports, only with an even number of interrupts flagged in the same SCI. That makes it unlikely if you have very fast interrupts, even if both TIE and RIE are enabled.

Message Edited by imajeff on 05-30-200606:04 PM

[mke_et]

Well, I've ALWAYS written my stuff so that ISRs are essentially a combination of a trigger response and polling. 

Back when I did Intel (or is that letnI?  "We are the knights who say letnI, and we demand a sacrifice.  We want...   A SEGMENT REGISTER!" ) stuff, there was a NASTY bug (er...  feature?) in the 8259 in that it would loose the vector for the interrupt request if the pin didn't stay stable and valid through the response cycle.  That was discovered where I work when we had an 8048 bang the interrupt on the PC bus.  As a result, you'd miss your desired interrupt and instead see a phantom IRQ7. 

Well, we had to put a driver on the card to make the interrupt not get missed, but it turned out we were seeing a few other spurious ints on IRQ7.

Then with the Tandy 2000, BOTH the 8259 chips were 'slaved' to the 80186 internal 8259 subsets.  Get interrupts at the same time on the same slave and you were dead meat if you did an EOI with another pin still pending on the same slave.  (Something IBM didn't do in their PC-AT BIOS!) 

As a result, I ALWAYS write my ISRs to handle 'bad' cases.  Three parts.  Part one, the entry to the ISR.  Part two, the EOI (as appropriate) immediately.  THEN part 3, which is handling the interrupt.  And in that part, I loop until the sources are clear.  That is, part 3 checks input status of possible requesting devices, and loops until they are ALL clear.  That means ints can stack up and at the same time the ISR is designed from the start to handle a case of a phantom.

I think because I write that way, the 'missing' interrupt doesn't affect me, since I'm servicing the SCI until the channel is clear, and I'm not depending on separate bangs to do each function.

Anyway, what I'm saying is that as assembly programmers, we have differnet mindsets, and we don't see issues that sometimes are hidden in the 'templates' that others use.   Unfortunately, sometimes we see issues that the templates are designed to hide.  Although I have to say usually Freescale is good about that.  I have some hardware I sell with Dallas Semiconductor parts and I found some of their documentation to be flat out wrong.  However if you used their 'developement kit', it worked.  Was a pain you know where to figure out how it really worked.

Message Edited by mke_et on 05-31-2006 10:35 AM

[imajeff]

mke_et,

Sounds like you might still not have the errata workaround, after all that explanation. I don't see where you say that you poll "part 3" from your main program loop.

See, when the problem happens, not a *single* ISR will be called. At least you do have a nice loop to make sure all pending are serviced after the first is called. The bottom line is, your system might not be complex enough to miss the ISR as documented. In that case you could still see it by folowing the instructions using the terminal program.

[glork]

Further Musings on Assembly;
What Mike said on ISRs. Any ISR must be written to accommodate worst-case circumstances, it just doesn't make sense to do otherwise.

I've written a version of Forth and an entirely custom language called 'Strings' and you know what? in the end I always revert to writing new applications in pure assembly anyway. Maybe its the kind of applications I do or maybe its just my mindset but it seems the best way to get the job done in the shortest time. Go figure.

Its been my experience with serial comm. drivers that:
A) 99.9999% of the time the Tx driver can be syncronous with the application 'foreground' and doesn't need to be interrupt driven. This makes it a heck of a lot simpler.
B) The receive driver can almost never be adequately done in polling mode and MUST be interrupt driven.
C) My receive driver seldom pays attention to the uart status flags; I structure the protocol/error handling so as to deal with and recover from any error situation.

I guess I haven't seen any uart errors in years (the last I can remember was with the R65C52 duart). This may be because I don't use the uart in a maximum sort of way.
ron

[rocco]

Hi, Mike, Ron and Jeff:

Me four.

I have always used assembler on microcontrollers (I'm old school, as well), but do use C, C++ and C# on PCs. I started using C in 1979, before I used Motorola microcontrollers, so it's not a matter of needing to learn a high level language. I use assembler because:
1) I gives me better insight as to what the hardware is doing, and
2) I have 25 years of MC68xx code at my disposal, starting with the good old MC68701.

Having said that, C has potential advantages:
1) You can take college grads and stick them on a project, regardless of the microcontroller that the project is using.
2) You could migrate the code to a different microcontroller when Freescale drops support for your favorite.

But both of these advantages are hard to realize. For #1, the college grad still needs to learn the tool-set and the capabilities of the chip. I feel that part of the task is much easier with assembler. For #2, You still have to port I/O drivers and hardware support routines for each platform, which can be the bulk of the firmware. Processor Expert tries to alleviate that burden, but I've yet to have PE generate code that was suitable for my needs. There just aren't the check-boxes that I want.

So I will stick to assembler, for now. I believe I can code much faster when it's not me that the Warrior is fighting against.

And, yes, it does make me pretty useless in the CodeWarrior forum.

[glork]

Hi All.
One other class of problem often raised here is 'processor expert' (really?? by what yardstick do you measure that?) and 'beans'.
I DO NOT understand people who want to rely on an 'off-the-shelf' code snippet written by someone you will never know, who knows nothing about your application/needs. Even if it appears to work...when you deliver it to YOUR customer it will have your name on it. I don't like that at all.

Its been pointed out to me regarding this attitude that I use Freescale hardware, which is very complex, which I know nothing about. That is an apples/oranges comparison. I can't do anything about the hardware except trust Freescale BUT I will control the software I ship. Besides, I worked with computers when an ALU was a mess of msi chips on a board; I think I understand hardware pretty well.

Sorry, just my little rant. Besides, why should I think the people who write 'beans' are better programmers than I?
ron

[imajeff]

Me three. I am one to complain that people can't seem to distinguish "compiler suite support" questions, and post them over at
http://forums.freescale.com/freescale/board?board.id=CWCOMM
or whatever forums for ICC12, Cosmic, etc.

I think the important thing for me as an assembly programmer though is not that I get code samples and libraries. So I never really thought CW should be useful for assemblers. All I need is real technical details and a tool that can do them. Sometimes I think a lib would be nice, but they would probably never code it the way I wanted for optimization.

Concerning your question about the SCI errata (missing interrupts), I have a good simple description of how to prove the problem:
======
A simple way to prove that the two devices are different is to
place a BKGD instruction in the code right after a char is
transmitted. (setting TDRE) If you then send a char from
hyperterm, (setting RDRF) then single step. You should jump to
the ISR. (even # of interrupts). If you repeat this and type
two characters (causing OR to be set) no ISR jump will
occur on the 1k79x maskset. (It should on the 2k79x)
=======

I haven't mastered this procedure. It makes sense that the 'bgnd' I insert needs to be after the 'rti' so that the I mask isn't still set durring the tx interrupt.

[glork]

Hello Mike_et.
I write only in assembly, and I do quite a lot of embedded-type programming.
It seems that a majority of the issues raised on this forum have to do with either 'how do I code this in C?' or 'why doesn't the compiler find my include file?'.
My opinion is that any time you spend on language or compiler issues you are NOT spending on your application. Since I make my living doing this (poor though it is) I cannot afford to do that.

One of the reasons I prefer Freescale micros is the excellent (and I really mean this) instruction set. For embedded applications these processors are a dream to program in assembly.

Anyway, I think there is room for most everyone in here and I try to learn what I can from all the posts, and I must say that I've found that most problems can get solved here. There are some really good people lurking in the shadows, you just have to present them with a tough problem in order to draw them out.

Other than that I share your view.
ron