topic Re: Assembly programmers in S12 / MagniV Microcontrollers

Assembly programmers

mke_et — Tue, 30 May 2006 20:19:25 GMT

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

Re: Assembly programmers

glork — Tue, 30 May 2006 20:47:43 GMT

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

Re: Assembly programmers

imajeff — Tue, 30 May 2006 23:58:37 GMT

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.

Re: Assembly programmers

mke_et — Wed, 31 May 2006 01:08:35 GMT

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.

Re: Assembly programmers

rocco — Wed, 31 May 2006 03:20:11 GMT

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.

Re: Assembly programmers

imajeff — Wed, 31 May 2006 06:58:11 GMT

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

Re: Assembly programmers

glork — Wed, 31 May 2006 10:29:51 GMT

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

Re: Assembly programmers

mke_et — Wed, 31 May 2006 21:27:52 GMT

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

Re: Assembly programmers

glork — Wed, 31 May 2006 22:48:54 GMT

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

Re: Assembly programmers

Frousouna — Thu, 01 Jun 2006 00:49:58 GMT

Thank you,

I would also say I'm old school, and by way of hardward designer. I have been using the 68HC912 for a few years now, and had always written in assembly. I just need to feel comforatable about instruction versus action. I got the DEMO9S12NE64 with the notion that I would be up and running in a couple of days. I must confess, I still haven't been able to load code to toggle an I/O, oh yea, using ColdWorrior.

I would like to open the browser and have the target communicate through http. Seems to me that this would ease the programming effort on the PC. I'll go through the TCP/IP stact learning curve, and stick with assembly.

George

Re: Assembly programmers

glork — Thu, 01 Jun 2006 01:53:18 GMT

Hi Frousouna.
I also have the NE64 kit (which I haven't fired up yet). I have an application coming up soon. I don't expect any serious trouble with the application itself till I get to the end, at which time I have to 'ethernet-enable' it.

In any case the only significant learning curve will be the ethernet part, and I hope to just license a tcp/ip stack that I can integrate into my main ASSEMBLY program. Any thoughts on this?
ron

Re: Assembly programmers

imajeff — Thu, 01 Jun 2006 03:57:47 GMT

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.

Re: Assembly programmers

peg — Thu, 01 Jun 2006 05:45:16 GMT

Hi,

I always use assembly too.

I am always amused by the many posts to this forum that start with lines like:

I am having trouble implementing this in C or trouble with processor expert, beans, initialisation blah blah blah to do such and such.

At this point I usually mumble to myself:

Well I could show you how to do it in a few lines of assembler, but I would not want to slow down/corrupt your rapid, abstract development methodology by dirtying it with horrible low level assembly language.

Regards David

Re: Assembly programmers

eeetee — Thu, 01 Jun 2006 08:04:36 GMT

hi:

me too for assembly programmming! i'm not real big on code warrior as it's way too huge of a development tool than i require. been using mini-ide as a tool, but it doesn't have the xgate support. is there an alternative that includes xgate support? basically i just want to type code and run it.

i must confess that a buddy got a reasonably well coded (in c) multi serial port comm's program up and running (yeah, it did run on the bench but it was never tested for error detection/correction etc.) in an hour.

regards,

Re: Assembly programmers

pittbull — Thu, 01 Jun 2006 17:15:13 GMT

glork wrote:
>>In any case the only significant learning curve will be the ethernet
>>part, and I hope to just license a tcp/ip stack that I can integrate
>>into my main ASSEMBLY program. Any thoughts on this?

There's a very good and free TCP/IP stack: http://sourceforge.net/projects/opentcp/
It is pure C code and easy to port to embedded platforms. If you want call C functions from an assembly program, you must figure out how parameters and return values are handled. In most cases, this is well documented by the compiler vendor. Otherwise, you can write your assembly code in C using inline assembler.

Topic: In my opinion there are only few needs to do assembly programming. That's not a matter of being an 'old school programmer'. Assembly is useful to do very special things that one couldn't do with a high level language. For example: Writing a scheduler that must deal with register saving/restoring, switching stacks an so on... On the other hand, there are tons of C sources for almost everything. Most of them are high quality, mature, tested and approved by thousands of programmers in the world...

Re: Assembly programmers

glork — Thu, 01 Jun 2006 20:48:58 GMT

pittbull wrote:
glork wrote:
>>In any case the only significant learning curve will be the ethernet
>>part, and I hope to just license a tcp/ip stack that I can integrate
>>into my main ASSEMBLY program. Any thoughts on this?

There's a very good and free TCP/IP stack: http://sourceforge.net/projects/opentcp/
It is pure C code and easy to port to embedded platforms. If you want call C functions from an assembly program, you must figure out how parameters and return values are handled. In most cases, this is well documented by the compiler vendor. Otherwise, you can write your assembly code in C using inline assembler.

Topic: In my opinion there are only few needs to do assembly programming. That's not a matter of being an 'old school programmer'. Assembly is useful to do very special things that one couldn't do with a high level language. For example: Writing a scheduler that must deal with register saving/restoring, switching stacks an so on... On the other hand, there are tons of C sources for almost everything. Most of them are high quality, mature, tested and approved by thousands of programmers in the world...

Hi Pitbull.
Thanks much for the tip on the tcp/ip stack, I'll follow up.

I understand your point on 'tons of C sources'. I don't actually disagree with it, as such. However, I'm very skeptical of 'off-the-shelf' software (not including a tcp/ip stack). I think that mapping the general to the specific is an inherently 'lossy' process in several ways, not the least of which is the loss of the sense of control which is so vital to egotistically-challanged people like me.

Here is a couple of real-world examples:
1. In a recent project involving a 9S12 variant the embedded firmware was supposed to be written in C. The C programmer became 'un-available' and I had to take over and write the firmware in assy (I don't write in C). This firmware included 2 separate communication systems, each with its own protocol and error handling, etc., an interface/driver for a CF card and a complete custom file system for handling the CF card. This entire program assembled to just over 4K-bytes and took approx 4-5 man-weeks to write. I'm sure it could have been written faster in C but we would have sweated to get it into the 32K-byte space.

2. Through-out the years I've had to write very similar pieces of code for common tasks such as ascii/hex & hex/ascii conversion, driving a multiplexed led display, etc. There is only a very small group of things like this which can be more or less 'canned' and used over and over. But even then in has to be tweaked for each micro variant. || Ok, here is where you say that if I did it in C it would automatically be variant-independant (sheesh, that almost sounds like an oxymoron thingy). Well, that may be somewhat true but only at the expense of raw effeciency. I think it is true to say that efficiency is inversely proportional to generality.
ron

Re: Assembly programmers

rocco — Fri, 02 Jun 2006 02:12:28 GMT

pittbull wrote:
... On the other hand, there are tons of C sources for almost everything. Most of them are high quality, mature, tested and approved by thousands of programmers in the world...

This is true.

However, I never find myself needing any of it. Most of the code in our projects are either dealing with the peripherals blocks, or implementing algorithms of our own design.

Another issue is the calling conventions. Depending on the need, we might pass parameters in registers, on the stack, or in some combination. But, in assembler, we can make that determination on a per-function basis.

Re: Assembly programmers

imajeff — Fri, 02 Jun 2006 03:45:51 GMT

> It is pure C code and [...]

This was always the funny thing about C programmers... trying to get pure C code, as if there was such a thing. I know pitbull doesn't mean this, but some people convince themselves that pure C contains no assembly, but then it wouldn't do anything if it wasn't completely made out of asm

Re: Assembly programmers

imajeff — Fri, 02 Jun 2006 04:26:43 GMT

Concerning both the mentioned SCI errata and Assembly programming, here is something I think is cool. I program in GCC (http://m68hc11.serveftp.org/). I have a good Assembler startup which I've uploaded to "community files", and I'll try attaching here.

It is experimental code to excersize the SCI port fairly fast using interrupts. It happens to show the 1K79X errata immediately after transmitting the fisrt byte. It can either work with a physical serial loopback, or a config option in the source code to enable the internal LOOPS.

Some people have tried and failed to use GCC (gas), but I think this setup works well. It even lets me debug visually with NoICE.

(hey, I attached the file before, but I think "Preview" removed it. trying again..)

Message Edited by imajeff on 06-01-2006 03:28 PM

Re: Assembly programmers

bigmac — Fri, 02 Jun 2006 04:35:49 GMT

Hello All,

For "low end" projects, most low pin count MCUs are limited to 8K of flash, or less. So unless the application is very simple, it will always be problematic whether there be sufficient resources to support C coding - whereas quite complex assembly applications will fit in these devices.

For example, I am currently updating an old HC705 project to use a HC908 device. The original assembly code size occupied slightly less than 4K. I could possibly convert the original code to C, but it would be uncertainty whether the code would fit within 8K, and this would not really be known until the coding was complete. Currently, to go beyond 8K would involve a MCU with considerably more pins, and higher cost, which I don't need. In this case, it will make sense to convert the HC705 assembly code to HC908 assembly code.

The extra machine code generated by a C compile, compared with assembly, may also impact on execution speed. This might result in the use of a higher bus frequency to compensate, with potentially higher current draw - important for battery operated projects. For example, I currently utilise POCSAG paging algorithms at transmission rates up to 2400 bits per second. With assembly coding, the processing speed is adequate for a bus frequency of 1.8MHz, but this may not be the case for C programming. The use of substantial in-line assembly seems "messy" to me.

My current projects use absolute assembly, with ORG directives to control where everything goes. This seems much simpler than fiddling with PRM files independently of the source code. By separately calling the assembler and debugger/simulator from outside the IDE, I can also use a much simpler directory structure than the over-complicated CW structure.

Having said all of the above, I believe that it is still necessary for me to be familiar with the finer details of embedded C programming. I might tend to use C for a simple "quickie" application, or to test a specific algorithm. Another use could be where an application needs to migrate to another MCU type (perhaps HC908 to HCS12) where conversion of assembly code would be more complex and error prone, (assuming the new device has adequate resources).

Regards,
Mac