Hi Ilija, Ilija Stanislevik wrote:
> The driver makes use of external interrupt (from one of the general > purpose I/O pins in case of STM32) to get interrupt request from > Ethernet chip. I've found that, in eCos 3.0 implementation for STM32, > the cyg_drv_interrupt_... functions don't set up the AFIO_EXTICRx > register, which is necessary in order to connect particular I/O pin with > the EXTI logic. The driver can always arrange for this outside the > standard functions, but such an approach produces a driver which is tied > not only to Ethernet chip, but to platform too. I think that it's the general case that when using external interrupts there will be some form of platform specific setup, so it's good idea to isolate this anyway. > Another solution is external function provided from application within > the private data structure, to be called from drivers init function. The > driver is still platform-independent and the application programmer > should take care for marshaling of interrupt. Rather than adding a callback in the private data structure, you can add the external interrupt setup to your platform specific initialisation code and then just include the interrupt vector ID in the private area of your SPI device data structure. Once the generic driver knows the vector ID it can then take care of managing the interrupt itself. Chris. -- Christopher J. Holgate Thinking Of The Future @ Zynaptic Limited (www.zynaptic.com)