Hi William, guys,
I've committed a proposal for SPI master libs, as revision 2640
It would be great if you could review the whole content of this revision
(code + header). If you:
1. don't agree and:
a. wants to revert it back to revision 1537, just tell me
b. wants to modify few things, please make it so, and tell me what I
should change
2. agree: great, just tell me too
As an overview of changes:
- spi_master_common.jal renamed to spi_common.jal, as SPI slave code needs
to access some of its constant so it's not only about "master", it's also
about "slave". Thus the renaming to a more generic name: "spi_common". This
invoved updating include statements in your lib.
- removed "pragma inline" from spi_init()
- added "pragma inline" to set_mode() (see question at the end about this)
- created 4 procedures, one for each mode (00, 01, 10, 11), all inlined
- set_mode() is using these 4 procedures
Benefits & improvements:
* duplication of code is avoided, thanks to the 4 procedure modes and the
use of them within set_mode() procedure, and also, ultimately from a
external point of view (sd_card.jal for instance), which will just:
- alias spi_master_set_mode_11() to either mssp1, mssp2 version
- call this aliased procedure to set mode, without having to directly
access device registers (that's how we can now use sd_card with mssp1, mssp2
or even spi master software).
* this version, as expected, produces the exact same HEX file as rev 1537
for sample 16f819_canopen_mcp2515_txhb.jal:
- r2585 (most recent revision where your file wasn't changed, ie.
spi_master_hw.jal@2585 == spi_master_hw.jal@1537
Please check again.
$ ./compiler/jalv24o -s
include/device/\;include/peripheral/spi/\;include/external/can/\;include/jal\;include/protocol
sample/16f819_canopen_mcp2515_txhb.jal
jal 2.4o (compiled Mar 6 2011)
generating p-code
301 tokens, 80113 chars; 2233 lines; 8 files
generating PIC code pass 1
generating PIC code pass 2
writing result
Code area: 663 of 2048 used (words)
Data area: 93 of 240 used
Software stack available: 80 bytes
Hardware stack depth 5 of 8
0 errors, 0 warnings
$ md5sum sample/16f819_canopen_mcp2515_txhb.hex
2277b4c58e7103bdcdc0ddb890247fef sample/16f819_canopen_mcp2515_txhb.hex
- r2640
$ ./compiler/jalv24o -s
include/device/\;include/peripheral/spi/\;include/external/can/\;include/jal\;include/protocol
sample/16f819_canopen_mcp2515_txhb.jal
jal 2.4o (compiled Mar 6 2011)
generating p-code
301 tokens, 81017 chars; 2268 lines; 8 files
generating PIC code pass 1
generating PIC code pass 2
writing result
Code area: 663 of 2048 used (words)
Data area: 93 of 240 used
Software stack available: 80 bytes
Hardware stack depth 5 of 8
0 errors, 0 warnings
$ md5sum sample/16f819_canopen_mcp2515_txhb.hex
2277b4c58e7103bdcdc0ddb890247fef sample/16f819_canopen_mcp2515_txhb.hex
* it still expose spi_master_hw_set_mode() to external lib, this gives
flexibility in using this library. But...
Question: in this revision, spi_master_hw_set_mode() is inlined, so it
produces the HEX file as before. But, let's forget the goal of having the
same HEX, and in this context, should it really be inlined ? I mean, if this
procedure is called several times, it will consumes a lot of resources (as
its inlined). My question is, in SPI world, does setting *different* modes
is something usual within a same lib? If so, should we consider making this
procedure *not* inlined ? Or, does setting mode is done always the same, as
sd_card.jal, where mode 11 is always used. In other words, is it possible
that a lib using SPI and driving one device may set mode 11 and then mode 01
(for instance) ? If so, what do you think about inlined vs. not inlined ?
Well, I hope you know what I mean...
Thanks in advance for your input.
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.
