On 4/1/06, Lucian Copat wrote: > > Hello, > > Your version would be the best way, but the problem is that I enable the > CAN interrupt for nothing in CANSendMessage, because ISR wouldn't be > called. It's called only when a buffer *becomes* empty - was full > before. So I have to fill also the buffer when enabling the interrupt. > > Lucian Yes you have to fill it in both plaxes but if you do a function f the "fill buffer" you don=B4t have to write this code twice. There are two places from which this routine will be called from but if called form one of them it wount be called from the other place. That is if the interrupt is disabled you know for certain that there will nit be second call on the routine from the IRQ handler. Cheers /Ake YAP wrote: > > >Hi Lucian, > > > >IMHO better to have something like this > > > >CANSendMessage() { > > // Write data to FIFO or similar > > if ( NOT CANTX IRQ_Enabled ) { > > // Write data into at least one of the CAN buffers > > // Enable CANTX IRQ > > } > >} > > > > > >Irq_routine { > > If ( data left to write ) { > > fill CAN buffer(s) > > } > > else { > > disable CANTXIRQ > > } > >} > > > >If you use a FIFO the IRQ routine will read from the read pointer and you > >will write to the write pointer. No conflict between the two. > > > >Cheers > >/Ake > > > > > >On 3/31/06, Lucian Copat wrote: > > > > > >>Maybe I'm missing something obsious here... > >> > >>Let's say the filling function is called CANPut(), and it fills a CAN > >>message, activates the corresponding interrupt and return True if there > >>was space for the message. I have a function CANSendMessage which does: > >> > >>void CANSendMessage() { > >> > >> //fill the 100-byte buffer > >> > >> while (CANPut()); > >>} > >> > >>In the ISR I have: > >> > >>if (can TX interrupt) { > >> while (CANPut()); > >>} > >> > >>Until here am I correct ? > >> > >>The compiler will give: CANPut() is called from different.... - > >>reentrant code. > >> > >>Lucian > >> > >>YAP wrote: > >> > >> > >> > >>>On 3/31/06, Lucian Copat wrote: > >>> > >>> > >>> > >>> > >>>>I know that a message has at maximum 8 bytes in CAN, that's why I need > >>>>to develop my own higher layer protocol to fragment the data. But when > >>>>the interrupt is enabled, it doesn't activate if the buffer is empty, > >>>>but when the buffer becomes empty (after having sent a CAN message). > >>>> > >>>>In this way, I can only avoid reentrance by writing the same code > twice > >>>>or by setting a flag in the interrupt. > >>>> > >>>>Lucian > >>>> > >>>> > >>>> > >>>> > >>>I can't understand the problem here either if you use the method > Gerhard > >>>suggest. > >>> > >>>1.) When you have data to send fill all free buffers. Enable interrupt. > >>>2.) When you get a frame sent interrupt fill data again if any to all > >>> > >>> > >>free > >> > >> > >>>buffers. > >>> > >>>No need to rewrite code use a function call to fill the buffers. It > will > >>>only be called by one process anyway and don't need to be reentrant. > >>> > >>>/Ake > >>> > >>> > >>> > >>>Gerhard Fiedler wrote: > >>> > >>> > >>> > >>> > >>>>>Lucian Copat wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>My question regards the E-CAN module in PIC18F4680. I have a routine > >>>>>>which loads a message (100 bytes max) into a temporary sending > buffer. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>You know that a single CAN message can only have 8 bytes payload, > >>>>> > >>>>> > >>right? > >> > >> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>I would like that after loading this buffer, when I activate the TX > >>>>>>interrupts, the ISR to be called if there are some free buffers. > E-CAN > >>>>>>module does generate an interrupt only when a buffer _becomes_ > empty, > >>>>>>which means I should load it first. If I load it first and also in > >>>>>> > >>>>>> > >>ISR, > >> > >> > >>>>>>I would have reentrant code. Is there any method to pass this > problem > >>>>>> > >>>>>> > >>? > >> > >> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>You would typically disable the TX interrupt in the ISR when it sees > >>>>> > >>>>> > >>that > >> > >> > >>>>>there are no more bytes. Then, after initiating the next tx sequence, > >>>>> > >>>>> > >>you > >> > >> > >>>>>reenable it. This way, there's no problem with reentrance. > >>>>> > >>>>>Gerhard > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>-- > >>>>*Lucian Copat > >>>>Software Team Leader > >>>>Audiotel Comlabs > >>>>E-mail: lucian.copat@audiotel.ro > >>>>Mobile: (+4)0722.729.658 > >>>>Web: http://www.audiotel.ro* > >>>>-- > >>>>http://www.piclist.com PIC/SX FAQ & list archive > >>>>View/change your membership options at > >>>>http://mailman.mit.edu/mailman/listinfo/piclist > >>>> > >>>> > >>>> > >>>> > >>>> > >>-- > >>*Lucian Copat > >>Software Team Leader > >>Audiotel Comlabs > >>E-mail: lucian.copat@audiotel.ro > >>Mobile: (+4)0722.729.658 > >>Web: http://www.audiotel.ro* > >>-- > >>http://www.piclist.com PIC/SX FAQ & list archive > >>View/change your membership options at > >>http://mailman.mit.edu/mailman/listinfo/piclist > >> > >> > >> > > -- > *Lucian Copat > Software Team Leader > Audiotel Comlabs > E-mail: lucian.copat@audiotel.ro > Mobile: (+4)0722.729.658 > Web: http://www.audiotel.ro* > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- = http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist