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.

  • \$\begingroup\$ I am not a lawyer, but be careful when doing this. It looks like the two projects have incompatible licenses. If this is the case, you would be unable to distribute the ported drivers. \$\endgroup\$ – Jeremy Kerr Jul 25 '11 at 5:25
  • \$\begingroup\$ @jeremy-kerr good point.. I would need to think about that however I am more geared to the technical side of the stuff for now.. \$\endgroup\$ – Frank Jul 25 '11 at 6:26

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!

  • \$\begingroup\$ Thanks very much.. Excellent answer.. I am doing bunch of other stuff in the mean time, hence the 3 months.. Also, I don't know anything about linux yet. \$\endgroup\$ – Frank Jul 25 '11 at 7:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.