2011/5/6 William <[email protected]> > > Because I have already tested the old routine and have units in the > field running the old routine. Besides the CAN device, there is a spi > eeprom/mac address chip, as well as some unpublished code, all of > which would need retesting. >
So, this is the reason why you don't want your init procedure to be changed ? Can you confirm this, that is, you don't want this change because you have plenty of tested program out there and you don't want to test your code again ? If so, do you think this position is valuable for an open source, community project ? Please reply. > > Matt, you may recall that you and I have debated your proposed changes > to the spi module previously, so I was a little surprised to find them > included under the subject heading of mssp2. My position hasn't > changed. However, I am offering a compromise -- go ahead and keep > your new routines, but don't mess with my original spi_init routine > unless there are bugs or changes in the way bit-fields are defined, > new compiler technology, etc. Seems quite fair and reasonable to me. > I do have another compromise, which keeps init procedure split, but produce the exact same HEX code, that is, same md5sum. This would, on the other side, consume more memory for program using SD Card for instance. This involves removing "inline" from spi_init() and move it set_mode(). You'll notice this is only a matter of "inline" procedures, that is, a matter of how the code get called (compiler level), the change we did isn't that big and particularly doesn't change the logic. Do you agree with the previous statement ? > > By the way, I actually wonder if the new spi_init routine saves code, > it might be less than you think, and it also consumes an extra stack > level. When you say "it consumes an extra stack", did you verified ? I'm asking, because I did, and depending on the sample I tried, this is not true. Particularly, when considering the randomly picked :) sample/16f819_canopen_mcp2515_txhb.jal, it doesn't consume an extra stack. When considering SD card, it consumes an extra stack as set_mode is getting called more than once. On the other side, it saves few bytes of memory. Cheers, Seb -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
