MikroC Ethernet lib RX filters wrong ...

[srdjan]

Hei ...... Who edit my message !!!!!

- That would be me. Sorry, they keep putting quote and edit buttons so close

Well, I can not enable those filters and allow user to change them in the same time in init routine. It will have to be, either let users take care of filters or set them by default.

I don't say that !!

Well, I want to implement it in init routine and keep backward compatibility and make it easy...

[bruno]

Well, I can not enable those filters and allow user to change them in the same time in init routine. It will have to be, either let users take care of filters or set them by default.

to me default POR must be kept and init routine has nothing to do with filters.

why not functions or pseudo-functions like :
Ethernet_Unicast([ON|OFF]) ;
would need only one ROM byte.

[srdjan]

Well, I can not enable those filters and allow user to change them in the same time in init routine. It will have to be, either let users take care of filters or set them by default.

to me default POR must be kept and init routine has nothing to do with filters.

why not functions or pseudo-functions like :
Ethernet_Unicast([ON|OFF]) ;
would need only one ROM byte.

I do think that rx logic must be disabled while configuring filters. So, the easiest way would be to set them in init while rx is not enabled yet.

[bruno]

It is not mentioned in the datasheet that RX logic must be disabled before modifying filters
To me, the init sequence of the datasheets prevents only from receiving unwanted packets

[yo2lio]

I made few tests one moment ago and we can change ERXFCON and MAADR registers, ON THE FLY !

Conclusion : Ethernet filters can be modified at any time !

[srdjan]

It is not mentioned in the datasheet that RX logic must be disabled before modifying filters
To me, the init sequence of the datasheets prevents only from receiving unwanted packets

I see where the confusion lies. Sorry, I did not express myself correctly, there should have been a should instead of a must. I did not mean that you can not modify filter register while rx is enabled, but, exactly what you said, unexpected packets may be received while filters are modified. This is what I was referring to, taken form the microchip's data sheet:

Code: Select all

... to prevent unexpected packets from arriving,
it is recommended that RXEN be cleared before
altering the receive filter configuration (ERXFCON) and
MAC address...

[srdjan]

Ok then,
init routine will keep rx filter reset settings and additional routines will be used for filter enabling. Just another question:
Let's say we will allow this CRC on/off, unicast on/off, multicast on/off, brodcast on/off.
If we make a separate function for each feature we will have 8 different routines.
How about making one routine for enabling one for disabling filters? Both of them will have a byte input parameter whose each bit will correspond to appropriate filter. Bits for advance filtering and and/or bode will be ignored.
Suggestions?
Speak now or be silent for ever

[yo2lio]

Speak now or be silent for ever

Your proposition it's OK !

PS. I want to speak after the new release !

What about I2C bug ? http://www.mikroe.com/forum/viewtopic.p ... hlight=i2c

[bruno]

Ok then,
init routine will keep rx filter reset settings and additional routines will be used for filter enabling. Just another question:
Let's say we will allow this CRC on/off, unicast on/off, multicast on/off, brodcast on/off.
If we make a separate function for each feature we will have 8 different routines.
How about making one routine for enabling one for disabling filters? Both of them will have a byte input parameter whose each bit will correspond to appropriate filter. Bits for advance filtering and and/or bode will be ignored.
Suggestions?
Speak now or be silent for ever

not too late for speaking

if you mean something like :
Ethernet_enable(UNICAST) ;
Ethernet_disable(MULTICAST) ;
it is OK to me too.
be careful with function naming because something like :
Ethernet_setFilter() or clearFilter() is ambiguous : if I set the filter, does it enable filtering (I will not receive packets) or enable reception (I will receive packets) ?

advance filtering needs datasheet understanding anyway, so it is not a big deal to leave it to user.

[srdjan]

PS. I want to speak after the new release !

- You are welcome to speak now and after the release!

[
What about I2C bug ? http://www.mikroe.com/forum/viewtopic.p ... hlight=i2c

- This was entered on the todo list too late for this release. However, on your insistence, I have checked this request. After investigation of pic18f4520 erratas I have concluded that this issues is listed only for the A1 revision. Please, do correct me if I'm wrong.
Therefore, I have removed this request from the ToDo list as it is not going to be implemented.
Anyway, thank you for your suggestion, we do appreciate it.

[yo2lio]

However, on your insistence, I have checked this request. After investigation of pic18f4520 erratas I have concluded that this issues is listed only for the A1 revision. Please, do correct me if I'm wrong.

Yes but is listed for a lots of MCU's.

For PIC18F87J10 is listed in A2 revision

This problem not appear to PIC18F97J60 family ! I don't know, maybe not yet !

Anyway, for safety, is good to put this sequence code :

Code: Select all

1. Configure the SCLx and SDAx pins as outputs by clearing their corresponding TRIS bits.
2. Force SCLx and SDAx low by clearing the corresponding LAT bits.
3. While keeping the LAT bits clear, configure SCLx and SDAx as inputs by setting their TRIS bits.

in I2C_Init for all devices .

PS. I got 100 USD (is not too much...) from my BOSS, because I fix this problems to our devices ! Thanks to Zoran !

[zristic]

PS. I got 100 USD (is not too much...) from my BOSS, because I fix this problems to our devices ! Thanks to Zoran !

I drink BECKS.

[srdjan]

Hi,
Ok, if you have already investigated this issue, share your knowledge with me. You will save me from reading tons of erratas. What i2c modules are affected with this? Only the ones on portC or all of them, because we have a different library for each module.

[yo2lio]

This was tested by me only on PORTC ! I don't know about I2C module2 ?

But ... from PIC18F8722 ERATA A1 rev. :

Before configuring the module for I2C operation:
1. Configure the SCLx and SDAx pins as outputs by clearing their corresponding TRIS bits.
2. Force SCLx and SDAx low by clearing the corresponding LAT bits.
3. While keeping the LAT bits clear, configure SCLx and SDAx as inputs by setting their TRIS bits.

x mean module 1 and 2.

[yo2lio]

I think, this issue appear just in nanoWatt Technology MCU.

For PIC18F452, 252, 458, etc, is not signaled !

At our products (devices) this issue was signaled when was changed PIC18F452 with PIC18F4520.
Also appear randomly, not to all PIC18F4520 in my case.