Question on efficiency in SX/B - Using SHIFTOUT or writing a bit banging method

T&E Engineer

I have heard that using SHIFTOUT should be done via subroutines and used somewhat spareingly. However, if another subroutine was written to perform a similar task as the SHIFTOUT command but it was somewhat long, how does one know whether to use a command or re-write a subroutine or function that may be faster, smaller, etc? Is there anyway of measureing this (speedwise) or program size wise in some sort of metrics?

I'm just trying to determine if there is a rule of thumb to follow here on using what is available or spending the effort to re-invent the wheel in "hope" that it might be some sort of savings in speed, program size, etc.

Thoughts...comments?

Peter Verkaik

Best way is to look at the assembly output of such a sxb command,
and then optimize it by hand, and then using an asm/endasm block
for this optimized code in a subroutine.

regards peter

Zoot

Short answer -- look at the generated assembly code that SX/B generates. If you can write better assembly, or substantially shorter assembly, or you absolutely require a different functionality, then do it. If your assembly skills are not too strong, then use the SX/B.

If a given command that generates long chunks of assembly is going to be used more than once, wrap it a subroutine. Examples: SHIFTIN, SHIFTOUT, SERIN, SEROUT, FREQOUT, all I2C, PAUSE and PAUSEUS, higher math functions (i.e. divide, multiply, multiply-high, multiply-mid).

Personally, if the command is only used once in the program, I would never use sub jump table space, nor code space, nor runtime cycles for a sub/func; others would for consistency and neatness' sake.

Examples of possibly re-writing existing commands for purposes of functionality:

- running the equivalent of shiftin/shiftout but in the ISR to possibly allow for interrupt driven CS
- running I2C state machines in the ISR to use the SX as slave device
- serial comm. in the isr with a circular buffer (I'm sure you've seen and used these examples)
- removing all the JMP @Label constructs which can really add up to code space (but changing requires keeping all code for the sub/func on one code page)
- feature adds/removes (I added a timeout during the clock-stretching loop in I2CIN/I2COUT so that if the slave is crashed, the SX won't hang in an endless loop)
- adding pin mask constructs or variable parameters (i.e. some commands do not allow for variable parameters for pins or times, or whatever)

To come back to SHIFTOUT, I don't see what would be gained by rolling-your-own -- esp. given the ease with which it can configured (and you know it will work).

Lastly, while it's hard to say how many future revisions (if any) or bug fixes there will be to SX/B, keep in mind that any optimizations or bug fixes down the road to built-in commands *would* have the newer assembly generated (upon a re-compile); hand-made routines would not. A perfect example is Word adds/subtracts -- I made a hand-built routine that does some extra pre- and post-processing of the Word parameters and results, but I used the SX/B "/" and "*" operator -- the rest was assembly. This was a huge plus when Bean accounted for preserving the carry ("C") flag during Word math operations. Had I done my entire function in assembly, using Bean's code as a basis, I would have to revisit it all. Instead I was able to make a few adjustments to my post-processing code to make sure C didn't get clobbered and not worry about all the rest of it.

I will say that in very long assembly blocks generated by SX/B the biggest hit is often page jumps -- so unless every cycle is precious, or you must have the code space, I would use the SX/B commands. If the page jumps are really adding up I sometimes take the assembly output and convert all the jumps to be local page jumps. But it's tedious and again, you're stuck with it regardless of subsequent changes to the released SX/B compiler.

I'm sure other users may have differing approaches, caveats, styles, recommendations. I'm just one guy

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

Post Edited (Zoot) : 10/6/2009 4:22:07 PM GMT

T&E Engineer

Thanks guys. I really appreciate your input on this.

Since I don't know assembly and probably not going to learn now that there is an EOL on the SX line, I will stick with SX/B. Sometimes I will look to see how other·bit banging routines·in C (for other micro-controllers) that I·want to convert into SX/B so that I can use it more efficiently. They don't use SHIFTOUT but·some left/right shifting and IF THENs at the bit level. I wonder if it would make sense to do something like that or just use what works like SHIFTOUT.

I think now that, if it aint broke, dont fix it - and go with what works. However, I then see other more experienced programmers using fancy tricks to better do what I want and it is faster, smaller, etc.

Just thinking out loud.

Thanks again...