In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Zoot wrote:

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. I 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.

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

---------- End of Message ----------


You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=390916#m390939

Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com

The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)