Rabbit

[Dino]

I've not coded an embedded app before, but I got a call the other day from a guy who needs his controller tweaked - a couple new enhancements and some bugs fixed.

He sent the source for me to go over. Seems straight forward enough, about 5800 lines of code - pretty verbose coding - no comments whatsoever. It does make use of costate in a few places.

Some of the coding techniques seem a bit redundant, like looping 14 times to check if a signal was up, and several places with built-in delays of 25 milliseconds as such.

Are these practices common in Dynamic C?

I suppose if I want the job, and the guy wants me to do it, they'll be providing the dev kit and board.

Any "gotchyas" a first timer to DC and embedded systems needs to be concerned with? Looks like I'll have to boot up Windows under my mac to program with the dev kit.

[stahta01]

Rabbit Dynamic C is not standard C!

Rabbit Dynamic C 9.x does NOT use headers files.
Rabbit Dynamic C 10.x might use headers files. 10.x is getting closer to standard C with each new release.


Logically Rabbit Dynamic C uses a single C file.
Comments are NOT just comments. A special comment is required around each function prototype.
Note: If you try to just put 20 or so function prototypes between a single set of special comments it complains after a limit is reached.

The stack is small in size; so large variables need to be global or static.

Tim S.

[Dino]

Yes, there is not a header file, and there is a heavy use of global vars in this code, and it's all in one file too.

Thanks!

[stahta01]

"#use" replaces some places where "#include" would be used.

.lib files are Dynamic C Source Code files holding Libraries.

First find out if Dynamic C (DC) 9 or 10

rabbit 3000 series uses DC9

http://www.digi.com/products/wireles...abbit3000#docs

Rabbit 4000,5000,6000 uses DC10
http://www.digi.com/products/wireles...abbit4000#docs

Logically Rabbit Dynamic C uses a single C file.

What I meant by the above statement was that there is no linking step. All the source code is combined together by the compiler and the compiler outputs the binary file.

Tim S.

[Babkockdood]

I like rabbits.

[Salem]

First make sure you can compile and program the device without making any s/w changes at all.

Then check out what debug features you have - chances are, they're pretty minimal (extremely so, if you're used to source level debuggers).

Do you have specific tests for the bugs (and can perform tests for the proposed new functions), so that you can repeat the tests to show you fixed them.

Also set up some kind of version control for the s/w, as there will be a lot of "it works, oh no it doesn't" going on. Being able to backtrack through the diffs will be a great help.

[cyberfish]

Some of the coding techniques seem a bit redundant, like looping 14 times to check if a signal was up, and several places with built-in delays of 25 milliseconds as such.

Definitely not common.

In embedded world, sometimes hacks are necessary to get around hardware limitations (they would be well documented), but from your descriptions, who ever wrote the code doesn't know what he is doing, and tried to just hack it along the way to get it to accidentally work.

I wouldn't want to work with a codebase like that. Endless trouble.

[Dino]

... Endless trouble.

Ah, but I see the lemonade here - not the lemons. Endless trouble = endless revenue stream. lol

Good ideas Salem (take it slow, track my progress, take checkpoints). I suspect writing a set of tests would be appropriate here too. (I just googled dynamic c unit testing... doesn't look good).

I'll probably meet with the guy next week.

[cyberfish]

Ah but any small change you make may "break" everything because some assumptions he made won't be true anymore.

For example, if you make a function faster, it may break timing in another part of the code, since he empirically determined/hacked some random delay amount.

And of course they will blame you because the code worked before your changes, and doesn't afterwards.

[Dino]

I've been around the block enough to not deliver broken code. If their requirements are to make this faster, then I'll get into the delay-removal-and-testing business on this project. Otherwise, I'll consider that off limits, that it is there for a very good reason, and there's no reason to make it faster without them paying me to make it faster.

Good advice and heads-up, regardless, thanks.