Paul & Sabrina's cheap DIY 144v motor controller - Page 156 - Fuel Economy, Hypermiling, EcoModding News and Forum

squiggles · 06-05-2009, 02:33 AM

Simple question.
I am not familiar with the Atmel chip, is there an assembly language programming tool available? If it ever gets to the point of extreme code optimisation you will get better results with assembler than with a higher level language compiler.

Actually it is worth looking at the code generated for function calls, compilers often stick quite a lot of unnecessary overhead in them.

dcb · 06-05-2009, 08:23 AM

Get it working, measure, see if optimizations are required.

Optimizations (I.E. rewriting stuff in assembler) frequently obfuscate the code, so should be done only as necessary.

It would be nice (though it is terribly unimportant at this stage) if the output from the cpu could drive something like this, then users could see something interesting:
http://www.sparkfun.com/commerce/pro...roducts_id=461

OF course I would want to mix in a vehicle speed signal so that watts/mile could be displayed, then buttons and yadda yadda

But not important for version 1, think "scope control" for now.

MazdaMatt · 06-05-2009, 08:41 AM

I would definately not scrap the idea of uart on a prototype. I transform ideas into prototypes into production boards for a living - the UART is a BIG help in the prototype phase and totally useless in production. It would be a really big help to see the streams of incoming data, intermediate calculations and output data. You COULD use it to change up the PI values and other scalars and safety limits, but just for data logging it is powerful.

It is not really that complicated to do an ugly, raw, one-way data stream out. I could email paul some automatically generated code for a freescale to run the uart by interrupts, but i don't have anything for the atmel. Usually it comes in the form of a couple simple ISRs and a simple software FIFO. I'll spend a few minutes googling to see if i can find something.

dcb · 06-05-2009, 08:45 AM

And I hate putting in code that isn't for production. That is asking for trouble. Put an isp connector on there and read and write from the eprom directly if it is a configuration thing.

MazdaMatt · 06-05-2009, 09:50 AM

quick googling turned up nothing... are the atmel users just not interested in interrupt driven communication? Every uart code snippet I saw had a while(blah blah){sit here with your thumb up your...}

I don't have time for the rest of the day to put together some interrupt driven code... i am SUPPOSED to be doing work right now... Maybe on Monday if you don't have it sorted, i will send you some freescale code. You'd just have to change some registers and stuff around, it would be quite compatible.

squiggles · 06-05-2009, 09:53 AM

"obfuscate" what a great word, I'm going to find a place to use that!

Well written assembler, that is lots of comments, is just as clear as any other code. The problem is these days programmers are not taught the rudimentary principles of good programming. Resources are too cheap, computers are lightning fast, no need for efficiency, not enough need for proper program design. Then they step up to an embedded system and confusion reigns supreme. I'm old, pig headed and all that, but I will tell you what learning to program in machine language and then assembler taught some very valuable lessons and a few tricks along the way.

MazdaMatt · 06-05-2009, 09:53 AM

dcb, that's a good point, too. Could you datalog from an ISP?

However... having been through this process in a production environment that does custom engineering... hardware and firmware that is not "for production" is a major help in getting the job done. We add all kinds of headers, test points and circuitry to boards, as well as self-troubleshooting and configuration code just so that we can get from idea to sale faster.

MPaulHolmes · 06-05-2009, 09:55 AM

Hey Matt, I'm pretty sure I can get it working with interrupts. I don't think that's a problem. I'm just trying to throw something dirty together for the sole purpose of testing the functionality of the hardware in a lab, in order to fine tune pull up resistor values, etc... By the way, R16 needs to be bigger than 1k. hehe.

MazdaMatt · 06-05-2009, 09:55 AM

squiggles... I totally see where you're coming from, but you'd have a tough time arguing that to a table full of embedded programmers. Modern compilers can do wonderful things with efficiency that you'd spend months fine-tuning by hand. This mpu will run this program with ease, written in C. No worries.

squiggles · 06-05-2009, 10:18 AM

Quote:

Originally Posted by MazdaMatt

squiggles... I totally see where you're coming from, but you'd have a tough time arguing that to a table full of embedded programmers. Modern compilers can do wonderful things with efficiency that you'd spend months fine-tuning by hand. This mpu will run this program with ease, written in C. No worries.

You are 100% right, I work as a project manager now days, trying to keep the table full of programmers on track!!

Also your point about test points and headers in pre-production is spot on, put them on every available signal, make life easier.

Unused I/O pins should have them as well, just in case you think of some handy use for them.