Writing a USB device in assembly? Crazy or doable

[Kerrie]

I am making a new device and I have been assigned the USB implementation, but other programmers on the team are writing their modules in assembly.  Which is our primary language for development and this is a non negotiable.  I am responsible for the USB on this project, previously we have used an FTDI chip to convert our SCI.  Is it possible to write a USB device in assembly, is it ant others have done with success?  I have been looking at some of the examples with PHCH 3.1 stack and trying to familiarize myself with the demo projects. 

Any tips or trick,  suggestions on books or tutorials outside of the freescale website (I feel like I have read the all)?

should I try and go it in assembly? 

We are using the Coldfire 51 JE 256

[ralu]

I was there. It was my first serous programming assignment, havend done any C or something before.

I had USB keyboard and mouse device written in asm and i had to do mass storage device.

It took me 3 months and i still did not finish, but i get to point that windows could see mass storage device but i was not able to format volume.

If you ask me?

DO NOT!!!

But if you still need to do this. Take chip, working C code (most vendors ship drivers whit usb chip) and rewrite in asm.
USB is pretty complicated and buggy protocol in sense that windows drivers does not works by standard (that is what I am still convinced in).
For reference i used USB standard from usb.org (600 pages)

Good luck!

[Mudwog]

Well, I thought it was a great idea.

Step 1 forget about the CMX "stack"
Step 2 get a copy of the USB bootloader example that acts as a mass storage device
Step 3 convert it to GNU
Step 4 change the interrupt handling to be compatible with my existing system
Step 5 make my own LED blinker "dummy application"
Step 6 remove all the unused modules and eliminate all of the nested includes
       at this point my project was around 21 files (including my .ld and .bat)
Step 7 rewrite each USB subroutine one at a time and get each one working before going on.

It took about two weeks working on it part time.
I learned a lot, I'm now a USB beginner.
I still have a lot to learn, it's a whole new world.

[tetsu_jp]

I like assembler. It teached me programming.

It does not confront creative programmers with structure and rules,

and it does not impose structure where not much creativity exists in the first place.

After a number of years, I increasingly found myself emulating things that compilers do,

for instance relocation tables, calls using fake stacks + goto, and custom addressing modes.

It's really an effin' waste in terms of maintainability.

Using assembler ties you to a specific processor model.

It's hard to understand even your own code.

It's very easy to write total bad code, being virtuous with a large number of bits stretching over many pages.

Why does it do that according to a flag that is set upon some weird condition, which itself...in another module...

well...it's accessed using hex masks not names that make sense...

Don't use assembly if any possible! It's totally bad. It will restrict your productivity a lot.

It will take 10x to 15x the time! And it is very hard to maintain. Maybe not so difficult to write assembly initially,

but even reusing smaller sections can be difficult if the interfaces are not clear.

If absolutely required, use assembler for time critical parts, or where the compiler likely will generate code which is

an unneccessary waste of code space.

You don't have to use C like C from a book you can use it very similar to assembler. Simply use the addressing modes that  have native support and use them in a way that is supported natively. You have to know assembler well for that, but, don't use it.

My opinion is 500 words assembler is the margin that is recommendable.

4K words are the absolute margin anything beyond that is not maintainable for ordinary programmers.

I changed from RISC assembler to C recently. I wrote an application, and it was a matter of a few sessions (using all the 2K codespace). It is easily readable, it is even portable. I like it. There are still cases where I have to use assembler (time critical I/O), otherwise I simply don't want to use it anymore.

If they insist on assembler the best arguments are the poor maintainability, and the non-existent portability.

Code space is no longer a valid argument these days. Neither time critical routines for most cases- why not simply use a more powerful MCU? Most of the cycle saving maybe could be done with just a few small assembler sections. It's no argument and not good programming style to code the whole project in assembler. 

[tetsu_jp]

Where I still continue to use assembler is for instance display drive/display refresh.

For instance I am currently working on a project for a large LED matrix.

There are multiple smaller 8bit MCUs each handling a section of the matrix.

Their RAM memory is small so the brightness data is packed, and must be unpacked/processed on the fly.

There is not enough RAM for instance to buffer all the presets so it's just done for one line/out of 6 lines.

These small display refresh MCUs do nothing else than to receive data via serial port, and to drive the LED rows.

In C bit-level manipulation is slow when you want to stream data.

And these MCUs don't have supporting instructions/the compiler is not optimized for that.

The master MCU program is NOT written in assembly

My point here is I think it's much harder to develope an USB stack in assembler.

If you already have it working in C, or if you know all aspects how to implement it,

you could port it to assembler. 

[tetsu_jp]

Recently I started developement for a LED matrix control program.

At first I started off using assembler, but then rewrote it in C language.

One of the reasons is that it takes a lot of time to make changes to assembler sources.

http://forum.cytron.com.my/viewtopic.php?f=21&t=11498

There are some photos as well zipped sources.

Some days ago I continued working at the C source, and it was possible to make it "working" within 3 hours.

It's easy to make changes, and to revert changes.

Using assembler this used to be very time consuming!

I don't really mind it's possible for me to use C or assembler almost equally (from the level of understanding).

Sometimes it's maybe required or can make sense to change to assemler once the code fully works (for exection speed reasons).

One thing I won't be doing anymore for sure is having any kind of debugging/testing based on assembler sources.

I will always use C language now.

Compilers don't always produce good code so it can make sense to port some parts of your USB stack to assembler, once the design is is completely, and works as intended.

Using assembler during developement is kind of "crazy" (I have done it in the past).

And it's much harder for other people to read the source code.

One really bad thing I sometimes see (and these are professional programmers), is assembler sources, which have comments on every line. More comment text than source code! 

[micro_kid]

Hmmmm..

Two paradym shifts in a single post:

- people should tend to develop in C rather than assembler because it is easier and more efficient

- people should remove comments from code to make it look more professional

Interesting points that we should all start working on - are there any consultants specialising in the deletion effort that can be recommended?

Cheers

Micro

[tetsu_jp]

You get the best results, if you run through 4 or 5 revisions, and each time, rewrite your code.

Until you reach what is possible technically, optimal code.

This is not always in the need to hire 100% assembler.

I think one page or half a page "should" be working on the data based on a "concept" .

You load the "display code" in the "accumulator" , "shift it" by 3,

but that's not worth commenting it.

I don't say one comment or two/page, but like anything else,

don't use more comments than to give explanation WHAT the source is doing.

Don't really comment HOW it is doing this.

In C you can't comment like that because typically, one line can do more than one thing.

Unfortunately, the commercial market does not always have the time to do 4 or 5 revisions.

So we get USB stuff that really does not always work correctly (I don't think Freescale based, anyway).

Did the OP explain what the USB device is doing, and why it must be maxed out (for performance) using assembler?

Good C programmers can write C code almost as powerful as assembler. If it is needed, time-critical parts are done using assembler. 

If they insist and say "This project must be done 100% assembler", I try to list up technically why this is not good advice, and eventually, refuse to do the job. Or demand extra rate for such a bad job, using all assembler along the road. 

[TomE]

---

Kerrie wrote:

... assembly.  Which is our primary language for development and this is a non negotiable.

---

Some forms of insanity make for interesting stories, or interesting lessons.

Have they given any reasons given for this decision?

Did someone have a bad experience with an old buggy C compiler? They're a lot better now than they were in the 1980's. Do they want to do things on the cheap and don't want to pay for a compiler? Cant do much better than this (what we're happily using):

... I was going to post a link to Code Sourcery Lite Edition for Coldfire, but they seem to have been taken over by Mentor Graphics, and the only option for Coldfire now costs $1600 per user. That's a bit of a shock!

Consider that coding in assembly for a specific chip won't do much for your resume. The best thing that you could have on your resume iwould be to have overturned the dogma and converted the place to coding in C.

Tom

[FridgeFreezer]

On the one hand, there is the fact that anything is possible, and that doing something like this for the hell of it / because you want to is entirely fine as a learning experience / intellectual exercise. Being forced into it by pig-headed luddites who belong on the pages of the Daily WTF is entirely another thing.

Depending on the situation & politics there are a few options:

- Kick it up the chain until someone sees sense (preferably also promoting you for demonstrating competence & consciencousness)

- Repeat the mantra of one of my old colleagues: "If that's what they want, that's what they'll get", and just keep taking the money & working through it, probably whilst browsing the job pages on your lunch-break.

- Built it in C, dump the assembler code and present it as done.

- Kill them. Kill them all.

But hey, I can't even make Freescale's CMX stack work in C on their own **bleep** demo board, so I can't really talk.

[scifi]

To sum it up: doable, but crazy nonetheless.

[mjbcswitzerland]

Hi

I would take an existing (working) USB implementation (you didn't specify exactly which class(es) you will be needing since each class is a development in itself)

- generic USB driver part

- class part with application interface

and compile it. Then generate the disassembled code and use that as you assembler input to the project.

I have developed USB drivers for various processor families and several classes (only device for now) and find it fairly difficult work (in comparison to other peripherals and protocols). I was pleased to have a good USB analyser (I invested $6'000 in analysers and it was worth it since it would otherwise have taken much longer) and also used a simulator to help verifying test cases.

It would certainly have been possible to work in assembler (with a lot of assember experience one can work fairly efficiently but needs to really have the experience to ensure that module reuse is possible, is well documented and hope that it doesn't have to be maintained by someone else in the future!!). However, once you have things working as you need it will be a big task to move to another processor - as you probably know, so it is not a very good investment for a company to develop such code unless it is clear that there will be no need to port it at some point. By using a C-code base it would at least be possible to generate starting points for new processors later if needed.

Starting from scratch (zero knowledge) I would estimate 1..3 months full time to get a (highly) reliable CDC class device. I don't write assembler any more so wouldn't contemplate not using a higher level language but a really good assembler programmer would probably do it in the same time and a less good one may take twice as long (which is however also true for higher level languages of course...)

Since there are a number of implementations available in C, using these (at least as reference) does represent the most efficient solution (as mentioned before disassembling the generated code will essentially give assembler to start with too).

Regards

Mark

[stalisman]

There is no logical reason for why Assembler only would not be a way to proceed, it is however exceedingly stupid unless one is completely up to speed and confident in all aspects of the target MCU, and in particular in knowledge of the peripheral subsystems primarily of interest.

Quite why any sensible organisation would insist on such says little more than that they have chosen the wrong chip in the first place.

Mark's comments are all valid and I concur.  I would however add though, that whilst C based examples exist for the upper layers of USB stacks, you will be lucky to find them freely available for the lower layers of your proposed stack.  Thus although a good idea it still leaves you with the task of getting to grips with your particular hardware .. and that task in itself will be of the same complexity whether you choose C or Assembler.

Given the size of the tasks ahead I'd have though that your company would be well advised to consider aspects of the job that improve productivity and the likelihood of success and not impose 'dogma' that merely complicates unnecessary issues.

Good luck

:smileyhappy: