[En-Nut-Discussion] Driver configuration at runtime

Harald Kipp harald.kipp at egnite.de
Thu Oct 10 17:30:58 CEST 2013


Hi Ole,

On 10.10.2013 16:48, Ole Reinhardt wrote:
> Hi Harlad,

Writing my name wrong is my grandma's fault, who selected this
complicated one, but forgetting the "Harald wrote:" tag is inexcusable.
Netiquette looks different.


> Yes. I agree, that working on the configurator could also be of much
> benefit for the users.
> 
> Just a few ideas to mention:

... a list follows to enhance the Configurator.

Thanks for providing this nice point of attack. Remember, that you were
among those who demanded to switch from wxWidgets to Qt, so that more
people can take part in its development? So far you removed trailing
spaces, which you could have done on the wxWidget source too.

(No need to shout back. I'm aware that you are also among the main
developers and have the right to demand it. But hey, the way is paved,
you just need to walk along. And no, I don't want to revert the decision
towards Qt. Now I'll try to maintain Netiquette and being a bit more
polite. <grin>)


>>> - Currently we have NutRegisterDevice(dev, address, irq). Nearly no
>>>   driver uses the parameter address or Irq
>>
>> At least for the majority of 32-bit systems, this looks like a good
>> solution to me. On the other hand, why not introduce a new function?
>> That may avoid all kind of backward compatibility issues. (I'm
>> suggesting this without knowing the details.)
> 
> I think I did not get your point, sorry :-)

What I meant was, you don't need to redefine NutRegisterDevice()
parameters. You could define a new function like NutConfigureDevice() or
similar.


> Exactly. The second ones are the USART drivers of the cortexes. These
> provide that much different options for the pin-settings, that adding
> all options to the configurator is horrible. But defined as a struct,
> these settings became quite lightweight.

Yes, good point. I fully agree.


> Let the preprocessor disable some options, and the remaining could be
> configured ideally on both ways. (e.g. the configurator could provide
> the default settings for the structs during compile time).

I'm ready to follow this new track.

Regards,

Harald




More information about the En-Nut-Discussion mailing list