Everybody is probably going the other direction, moving their systems etc. to linux. I have the following problem. I like to use a WiFi chipset along with its Linux driver on my RTOS (FreeRtos). If I do this the conventional way, it will take me 3 months to port it. (Now I work for a small company, therefore I don't expect any support from the chipset vendor with my volumes. However I have a very strict cost target so I cannot use this really expensive but easy to use modules. I am targeting sub 5$ wifi module here)
Is there a simple way or do I have to really go in deeply understand the driver and port it slowly. I don't know Linux but I know RTOS concepts relatively well. I am looking for a wrapper some sort that translates Linux system calls to more conventional RTOs stuff.
I know it is a long shot but I had to try.
And, do not suggest uCLinux as the OS, I have been down that road, it seems to be the best way however the code size is prohibitive to run with the on chip resources of my CPU.
Bonus question: Any WiFi experts out there who could recommend a b/g chipset with RTOS drivers that are readily available. I have looked at CSR,Realtek and Nanoradio, they all provide Linux drivers but no RTOS support. Atheros didn't even entertain to talk to me, I guess the effect of Qualcomm.
Best Answer
Porting the driver manually is the only way to go about it if you're unwilling to write the driver from scratch. @jeremy-kerr's right, you have license issues to be careful about, but essentially what this will mean if the driver is GPL is that your ported driver will also be GPL. You won't have to open up you're entire RTOS source code.
Three months is probably a conservative estimate for the porting effort; if you can identify the APIs used (network, interrupt, timers, waiting/locking, I/O, callback, file operation, etc.) and create a rough-and-ready map between the Linux API used and what is available on your RTOS it will make the process go MUCH more quickly, especially since you can then start to stub out the Linux API call used and "translate" it to the API and data structures used on your RTOS.
It won't be a simple task, but it's certainly doable and if the Linux driver is written well then you will have a very good idea of what each part does and why, which always makes porting easier. Good luck!