When merging the two i2c libs and declaring callbacks' prototype in ISR lib,
it just works nice. My worry was about when users don't define callabacks
(with a body), what happens ? Here's the result from compiler:

348 tokens, 61493 chars; 1638 lines; 5 files
!!!LABEL i2c_hw_slave_on_error NOT FOUND!!!
!!!LABEL i2c_hw_slave_on_master_hangsup NOT FOUND!!!
!!!LABEL i2c_hw_slave_on_master_stillreads NOT FOUND!!!
!!!LABEL i2c_hw_slave_on_master_reads NOT FOUND!!!
!!!LABEL i2c_hw_slave_on_master_writes NOT FOUND!!!
!!!LABEL i2c_hw_slave_on_master_talks NOT FOUND!!!
generating PIC code pass 1
generating PIC code pass 2
writing result
Code area: 137 of 4096 used
Data area: 8 of 352 used
Software stack available: 96 bytes
Hardware stack depth 4 of 8


Interesting "!!!LABEL ..." :)

My worry now is compiler does not produce an error, and exit status is 0
(success). I still think it's better to have our libs split, and be sure
(because compiler checked it) callbacks are properly defined.

Don't you think ?


Seb
2009/1/6 Sebastien Lelong <[email protected]>

> Ah, OK, I see: define callbacks' prototypes in ISR lib, and in client code:
> include ISR lib, then "implement" callbacks ?
> That would be nice, but I wonder how wrong it would be if no callbacks are
> implemented. Does the compiler say something ? I'll try.
>
>
> Thanks
>
> Seb
>
> 2009/1/6 Joep Suijs <[email protected]>
>
>>
>> couldn't you do it the other way around: define the callback
>> procedures in the lib code?
>>
>> 2009/1/6, Sebastien Lelong <[email protected]>:
>> >
>> > but you'd need to define them on the client code, right ? before
>> > defining callbacks ? not an option...
>> >
>> > seb
>> >
>> > 2009/1/6, Joep Suijs <[email protected]>:
>> > >
>> > > That's why you have prototypes (tnx Kyle!)
>> > >
>> > > Joep
>> > >
>> > > 2009/1/6, Sebastien Lelong <[email protected]>:
>> > >>
>> > >> Hi,
>> > >>
>> > >> >
>> > >> >
>> > >> > >  1. I've written two libs: i2c_hw_slave.jal and
>>  i2c_hw_slave_isr.jal.
>> > >> Only
>> > >> > > i2c_hw_slave_isr.jal (the ISR) is required by client code. I
>> could
>> > >> > > have
>> > >> merge
>> > >> > > them, but I thought it might be useful to keep the
>> init/read/write
>> > >> functions
>> > >> > > apart from ISR, for other purpose (like implementing a i2c slave,
>> but
>> > >> not
>> > >> > > using states). What's your point ?
>> > >> > I think this is a bit confusing for users, an other file with
>> similar
>> > >> > code - what should they choose...
>> > >> > I think it is better to have one file that contains the required
>> code.
>> > >> [...]
>> > >>
>> > >> Well, I was wrong ! Two libraries are needed because:
>> > >>
>> > >>  - before including the ISR, callbacks must be defined
>> > >>  - some callbacks need to i2c_hw_slave_read or i2c_hw_slave_write
>> > >>
>> > >> If those procedures are defined in a unique lib, which also contains
>> the
>> > >> ISR, there is a circular dependency: you can't include one unique ISR
>> lib
>> > >> to
>> > >> get those func to define your callbacks, because you callbacks must
>> be
>> > >> defined before including one unique ISR lib.
>> > >>
>> > >> So I must kept them the way they are:
>> > >>
>> > >>  - i2c_hw_slave: common i2c slave procedures
>> > >>  - i2c_hw_slave_isr.jal: ISR related stuff
>> > >>
>> > >> This also separate things which are ISR related from things which
>> aren't
>> > >> (yeah, I like when things are in the correct place :))
>> > >>
>> > >>
>> > >> Cheers,
>> > >> Seb
>> > >> --
>> > >> Sébastien Lelong
>> > >>
>> > >> http://www.sirloon.net
>> > >> http://sirbot.org
>> > >>
>> > >> >
>> > >>
>> > >
>> > > >
>> > >
>> >
>> >
>> > --
>> > Sébastien Lelong
>> > http://www.sirloon.net
>> > http://sirbot.org
>> >
>> > >
>> >
>>
>> >>
>>
>
>
> --
> Sébastien Lelong
> http://www.sirloon.net
> http://sirbot.org
>



-- 
Sébastien Lelong
http://www.sirloon.net
http://sirbot.org

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to