Looking for HC11 assembly language coding form / worksheet

[smuldoon]

Hi -

I am teaching a class using the HC11 and I recall (about 15 years ago) using printed assembly language coding forms or worksheets to help teach assembly programming by hand.  As I recall, they showed the HC11 programming model (registers) and were like a pad of paper.   They might have even had a Motorola part number. 

Perhaps a bit "old school", but I thought it was an effective learning aid.

Does anyone have an original or something like this scanned as a .pdf or setup in MSExcel?

Regards -

Steve M.

[js]

---

smuldoon wrote:

Perhaps a bit "old school",

---

Why would you want to teach your students an OBSOLETE micro? They will NEVER be able to use any xx05 or xx11 processor to make a living, Motorola/Freescale pretend they never existed.

Throw away all your "old school" stuff anf teach them something practical like the AVR (Atmel) achitecture or even PICs

[JimDon]

Well for one thing, you learn assembly language is for the sake of understanding how the guts of a machine work. I learned assembly language on an IBM 360, and for the most part things have not changed much as far as assembly language goes.

In a real job 95% of the time you will be using "C" anyway. And if you use Freescale, you have a really good free tool chain to boot (not Basic).

Whats more there are still plenty of HC11 student boards available, and many good books to choose from.
And  they have external memory, which is better to learn from.
Instruction sets come and go, the principles don't change much.

As for the coding pad, well I don't know about that. Maybe it is a good way to learn, but that's one thing you won't need on the job. We were delighted to dump the punch cards and coding pads.

[js]

>Whats more there are still plenty of HC11 student boards available,

True but no more HC11 or HC05. Lots of AVR and other student boards too.

How about exposing the students to the Harvard architecture too? I learned micro stuff almost 30 years ago too with the 6800. Loved Motorola, unfortunately they did drop many, many user in the poo by dropping products and NO REPLACEMENTS ie the 2 above.

I have been using Motorola stuff pretty much all my life untill about 8 years ago when I was let down with the HC11 family. I have just finished changing over the last product to an AVR chip when it used the HC11. By the end of the year I should be well and truly over using Moto stuff, no more stock. We used about 2,000 chips a year.

I still use assembler by the way. It was a bit liberating, even if painful, to break away from the Motorola architecture and into the Harvard architecture, first with the PIC and now pretty much all AVR.

Free tools are available for pics, avr, st micro etc.

Don't lead your students into a dead end street.

You can also find me at www.avrfreaks.net I haven't been to this site for a while. A Freescale user asked for help there and I redirected him here. Whilst I was here I thought I would look around a bit.

[bigmac]

Hello,

---

js wrote:

True but no more HC11 or HC05. Lots of AVR and other student boards too.

How about exposing the students to the Harvard architecture too? I learned micro stuff almost 30 years ago too with the 6800. Loved Motorola, unfortunately they did drop many, many user in the poo by dropping products and NO REPLACEMENTS ie the 2 above.

---

This would seem to ignore the "migration path", and backward compatibility of assembly code, provided by Motorola/Freescale. For example,

6800 -> ??? -> HC11 -> HC912 -> 9S12 -> 9S12X

68705 -> HC705 -> HC908 -> 9S08

It is my understanding that assembly code written for the 6800 will actually assemble correctly for the 9S12 (ignoring the peripheral differences).  Migration from the '705 to the '908 was certainly a relatively simple matter codewise.  The most significant difference was the requirement of new hardware tools.

I cannot speak for the AVR product, but my limited experience with PIC assembly code suggested it was quite complex to do things that would be taken for granted with non-Havard architecture.  The instruction set seemed so limited that I would liken it to "attempting to wag a dog by its tail".  To do quite simple things, it appeared that a "workaround" solution was necessary.  Perhaps one needs to have a different mentality.

Regards,

Mac

[js]

bigmac wrote:

This would seem to ignore the "migration path", and backward compatibility of assembly code, provided by Motorola/Freescale. For example,

6800 -> ??? -> HC11 -> HC912 -> 9S12 -> 9S12X

68705 -> HC705 -> HC908 -> 9S08

Can you give an example of a HC12 that will plug into my HC11 boards? How about a HC08 that will plug into my HC05 boards?

I will agree about the source code compatibility. However people have to redesign their working and most time APPROVED boards? This may cost tens of thousand of dollars in redesign and approval costs not to mention the lead time before the new module can be put into the field.

Microchip, as painful as it is asm wise, (about 34 instructions) has always provided a plug in replacement chip, some reassembling and possibly some small code changes and the product can still be manufactured.

Same for Atmel, some chips are in a 5th generation but they will still plug into the old boards, again some reassembling and possibly some small code changes and the product can still be manufactured. No redesign or reapproval costs.

Same core from 8 pins to 100 pin chips, same 32 registers to work with etc.

Having worked with AVRs for the past 8 years or so, it's a dream to port 68xx code across, even in asm.(up to about 135 instructions) It's so relaxing and easy I would even do it for nothing if I didn't have bills to pay   Not so much with the pic, I would probably electrocute myself first!!

I should really thank Motorola for dropping the chip lines, I have seen the light now

[smuldoon]

Well... since I put out the original request, here is how I see it....

I respect opinions regarding the seemingly out-dated nature of the HC11, but quite frankly, learning the basic principles of hand asm coding and dis-assembly are similar for any microcontroller.  The HC11 is still a very well documented and viable learning tool.  The HC11 has a very well defined asm language and register structure, thousands of example programs and applications, and is even currently used in many embedded applications, from recent production automotive applications to many student robotics projects.  It is a known, tested and proven quantity. 

Using the same logic, some would suggest that students not learn "old school" operating principles of vacuum tubes, or maybe even bipolar junction transistors, since there are FETs and other "new - faster - stronger - slicker" semiconductor switching devices out there.  Or, perhaps we should skip asm language all together and just program in C; surely more people use C than asm language?  You see - it is context.  I did not select the HC11 to teach with, I select the methods and basic principles of teaching assembly language programming.  I would use an IBM punch card or a paper tape punch in the classroom if I thought it would add value or re-enforce a basic principle that needs to be comprehended. (And yes, I think you should at least know what those things are, so you can have a perspective of how far we have come.)

The problem with the above approach (abandoning the recent-past in favor of the current or up and coming) is that it ignores basic principles and context.  The hand-coding form is a teaching aid.  It shows that each instruction performs a function that may or may not impact or affect other registers, counters and memory locations beyond what is "obvious" by just coding in the instruction.  It also helps when dis-assembling machine code by hand, to keep track of what is changing or being modified by the instructions.

I re-created the hand coding form for use in my class.  If it helps one student understand the "inner workings" of the registers and counters a bit better, it is worth the effort.  Oh, and guess what - it can be used for HC12 also.  This is an introductory microcontroller course that I am addressing.  There is plenty of time for the students to go through the process of selecting micros and weighing the pros and cons for a particular application or design in future activities and courses. 

Regards - Steve

[JimDon]

Well, I don't think anyone here ever suggest to skip asm language. It is VERY important that this be taught, and I have noted with dismay that some CS programs no longer include this. On the other hand, a strong "C" class is also required, after assembly language. So it is not a black and white thing - it is not C vs asm in a learning environment.

As for the coding pad, if it works then use it. Having said that, I do think that students also need exposure to a modern IDE with a debugger. All of what you said about seeing the effects of instruction execution are nicely displayed in the debugger, and can be an effective learning tool. What's more, a nice example of this tool is available for free. I also think that today's engineering students will have the ability to cope with the IDE, as I would presume that a student interested in engineering would already be quite familiar with using complex PC applications. It can't be any more difficult than Matlab.

I think that which machine is used is not at all important, only that it have modern tools available.

I have also observed that some professors in this domain are not willing to learn these new tools, and I think it is to their students detriment. While the monitor is ok for the first few exercises, there is no reason not to use modern tools. There are good for learning, perhaps arguably better. In fact there are some studies that indicate students progress further with these tools (not that you would need a study to figure this out). I also have have opinion that these tools will be more engaging and interesting to the student, and if equally effective than perhaps better. As to when in the process you introduce this, depends on many factors (unfortunately, one of those factors seems to be the professors willingness to learn the tools).

These methods and ideas are not mutually exclusive. You can use the coding pad and use code warrior. They both have their value as a learning tool. And these are important issues to our nation. as we need a new generation of engineers, and I hope that more professors will realize that there are certain new skills they need to acquire to accomplish this, or  at least step aside and embrace a new generation of teachers.

(I am not saying this about anyone in particular, just in general. What I have said is true in some cases, but there are many exceptions as well ).






Message Edited by JimDon on 2008-02-21 11:59 AM

[js]

>Have fun with your PIC.

I only used pics once. All of my work is based on Atmel chips now.

There is nothing that any HCxx can do that an AVR cannot do, except run a monitor perhaps as code only runs from flash. From porting code from HC11 to avr I have seen speed increases of up to 8 times for an almost 1:1 translation in code. Remember that most avr instructions will execute in a single clock cycle.

The instruction set is not that much different from the Motorola instruction set. Free tools are also available like AVR Studio IDE (which also has a built in assembler and simulator) and GCC.

I wish to apologise if I have taken this thread a bit off topic. However I feel that upcoming engineers should not be mind locked into a particular architecture, they will think that all processors are like the HC11.

It took me quite some time to break free from the mind set of the Josephson style processor after 20+ years of working with that, once the pic scrambled my brain, everything else is a breeze.

Expose them to another architecture. May be a little harder for the teacher to come to grips with, but it will do the students a great service.

Oh, and we give tremendous help to newbees at avrfreaks.net

[JimDon]

Js,

I guess the small  amount of code you write is of little value, but on most substantial complex projects the biggest investment  is in the software. Redesigning a board for a new and improved chip is a usually a nit compared to redesigning the software.

The ability to reuse knowledge of the processor and the code it self is of great value, hence the migration path. Sorry that you were unable to follow it, because now Freescale has top of the line tools, and a great instruction set - not to mention an broad line of hardware. Have fun with your PIC. but I value my time too much to waste it there. Freescale chips are for high end, high reliability designs, and yet they have small chips that can do a cost effective "toaster".

The PIC and AVR have such convoluted instructions sets and hardware - they are NOT good learning tools. Thats why there is PIC Basic - to hide the ugly machine. (as you have already agreed to).
As you mentioned, they are painful. Students have enough to learn with out having to deal with that backward nonsense.