I am planning to implement Hiawatha web server on a non-linux platform which is uC/OS-II RTOS.
I need help to port the Linux dependent API's to RTOS platform.
Kindly let me if there are already build libraries that I can use to port Linux on RTOS.
Thanks in Advance
Any code that uses more than just the standard C library will require some porting effort - the extent to which non-standard and OS specific libraries and calls are made will determine the effort required or even the feasibility of such a port.
Most Linux code of any complexity will require a POSIX API and networking code will probably use BSD sockets. Multi-threaded code would likley use pthreads. uC/OS-II has neither of these; it deals with only scheduling, timing, synchronisation and inter-process communication; it is a scheduling kernel, not a full OS in the same sense as Linux - it does not even have a file system - a requirement of most Linux code. Of course adding additional libraries and extensions may provide some or all of what you may need.
Moreover uC/OS-II's simple one-thread-per-priority-level scheduler would make typical Linux multi-threaded code hard to schedule in the manner intended. Most RTOSes (including uC/OS-III) support round-robin/time-sliced scheduling of tasks at the same priority level, but uC/OS-II does not; possibly making it unsuitable for this task.
Something more sophisticated that uC/OS-II may be in order, or perhaps using code more suited to uC/OS-II perhaps. eCos for example is a far more complete RTOS for embedded systems; it is open-source and includes a POSIX API, file-system support and a socket API. It would be far easier to port Linux code to that. Equally there are many lightweight embedded webserver examples that are probably more suited to uC/OS-II and other simple RTOS or even no OS at all. LwIP for example is a TCP/IP stack for small embedded systems for which uC/OS-II ports exist and for which there are web server examples.
The point is that Linux are uC/OS-II are not comparable; one requires < 10Kb of code, the other has a minimal foot-print of about 4Mb! To get Linux code to run on such a system will require you to add a lot of additional code to provide the missing services, and it may not be feasible on your target platform.
[Edit: 08 July 2012]
Have you considered using Micrium's own TCP/IP stack and μC/HTTPs web-server add-on? It is likley to be better integrated to uC/OS-II and provide better performance than non-RTOS specific third-party code.
Related
I wish to write a graphical tool with which one could configure and query information about a Linux system.
In order to achieve some independence from the underlying Linux distribution, I am planning to require that the target system uses systemd, and that the target system has the PackageKit console program installed.
With this, I will have excluded Slackware Linux, since it does not use systemd.
What other considerations should I have in mind when designing such a tool? With the use of an abstraction layer away from the package manager, and with the use of systemd, are there any other things that I would have to consider?
I know Rust can handle windows and *nix filesystems. I saw there is support to fork processes - is this also cross-platform? Would I be able to write a *nix daemon and a Windows service with the same codebase?
There is no such thing as fork on Windows (it uses CreateProcess instead).
More generally, Unix daemons and Windows services are very different (the latter has to comply with specific Windows interfaces), so you would need a significant abstraction layer if you want to share some code base. As far as I can tell, there is no library providing such an abstraction layer yet.
I have an application which I need to port on Linux. I was thinking to use Free Pascal the problem is the application uses Windows API's to perform tasks such as serial port communication etc... Is there a msdn for linux users or a book covering how linux works internaly if there are apis.
I am very confused.
Well, it's sad to say but if your code in very Windows-dependend (not VCL depended!) then probably it'll be faster to write the application from the begining rather then porting it.
But if it's only serial port matter then give a try to multiplatform SynaSer library, find it here: http://synapse.ararat.cz.
hope this help :)
Robert Love has a book on Linux Systems Programming - that will cover this area and Love's books are generally good, so it is worth looking at.
It's not entirely clear from your question, but if your concern is that there are specific calls to hardware controlling functions in your Windows application that make it difficult to port I would suggest that is a misplaced fear. Both Windows and Linux operate on the principle that the application level programmer should be kept away from the hardware and that all that should be handled by the operating system kernel and only be accessible to applications via system calls. As the kernels of different operating systems face similar demands from users/applications, they tend to have system calls that do the same sorts of things. It is necessary to match the system calls to one another but I can see no reason why that should be impossible.
What may be more troublesome is that your Windows application may rely heavily on the Windows executive's windowing code/API. Again finding analogues for your code is not impossible but is likely to be a bit more complex e.g. in Linux this stuff is generally not handled in the kernel at all (unlike Windows).
But then again, your code may be written against a portable toolkit/library like Qt which would make things a lot easier.
Good luck in any case.
If the program contains GUI code you must use linux libraries like GTK/XLIB in order to create windows, forms, buttons, etc...
Windows specific functions (like EnterCriticalSection, WaitForSingleObject or _beginthreadex) must be replaced with equivalent linux api functions (a nice tutorial can be found here:
"www.ibm.com/developerworks/systems/library/es-MigratingWin32toLinux.html") or you can use libraries such as w2lpl or wine
A useful library for this kind of problems i've found at http://www.adontec.com/windows-to-linux-port-library.htm
I've had great experiences just using WINE. (https://www.winehq.org/)
You don't really port your app at all. You just make sure it doesnt violate some of the basc constraints of WINE and just run it as is. WINE (though is says it is not) is an emulator of the windows API's and will just do the translation for you. It's pretty complete in its coverage of the API's.
I need to produce an embedded ARM design that has requirements to do many things that embedded Linux would do. However the design is cost sensitive and does not need huge amounts of horse power. Mostly will be talking to serial interfaces. Ideally I would like to use one of the low end ARMs. What is the lowest configuration of an ARM that you have successfully used embedded Linux on.
Edit:
The application needs a file system on some kind of flash device and the ability to run applications for processing the data. Some of the applications might be written by others than myself. I also need to ability to load new applications or update old apps using the serial ports to accept the apps.
When I have looked at other embedded OSes they seem to be more of a real time threading solution than having the ability to run applications. I am open to what ever will get the job done.
I think you need to weigh your cost options here.
ARM + linux is an option but you will be paying a very high operating overhead for such a simple (from your description) set of features. You can't just look at the cost of the ARM chip but must also consider external RAM which will very likely be required as well as flash to get enough space available to run the kernel + apps.
NOTE: you may be able to avoid the external requirements with a very minimal kernel and simple apps combined with a uC with large internal resources.
A second option is a much simpler microcontroller with a light weight OS. This will cut your hardware costs on the CPU and you can likely run something like this without external RAM or flash (dependent on application RAM and program space requirement)
third option: I don't actually see anything in your requirements that demands any OS at all be used. Basic file systems are very simple, for instance there are even FAT drivers out there for 8 bit PIC's. Interfacing to an SD card only requires a SPI port and minimal external circuitry.
The application bit could be simple or complex. I've built systems around PIC18 microcontollers that run a web server and allow program updates via a simple upload screen, it just stores the new program into an EEPROM or flash, reboots into a bootloader and copies the new program into internal program memory. You could likely design a way to do this without the reboot via a cooperative multitasking type of architecture. Any way you go the programmers writing the apps are going to need to have knowledge of the architecture and access to libraries / driver you write. Your best bet to simplify this is to provide as simple an API as possible and to try to automate the build process for them.
The third option will be the "cheapest" in terms of hardware as there will be very little overhead in the processing of your applications allowing you to get away with minimal processing power and memory. It likely will require some more programming/software architecting on your part but won't require nearly the research you will need to undertake to get linux up and running in addition to learning to write the needed device drivers under a linux paradigm.
As always you have to include the software development costs in the build cost of the device. If you plan to build 10,000+ of these your likely better off keeping hardware costs down and putting more man power into designing a software solution that allows that hardware to meet the design goals. If your building 10 of them, your better off spending an extra $15-20 on hardware if it can cut down on your software development costs. For example an ARM with MMU with full linux kernel support and available device drivers.
I kind of feel that your selecting the worst of both worlds at the moment, your paying extra to get a uC you can run linux on but by doing so your also selecting a part that will likely be the most complex to get linux up and running on, especially having not worked with linux on embedded platforms before.
I've had success even on ARM7TDMI, so I don't think you're going to have any trouble. If you have a low-requirements system, you could use any kind of lightweight real-time executive and have a lot better experience than you would getting Linux to work.
I've used a TS-7200 for about five years to run a web server and mail server, using Debian GNU Linux. It is 200 MHz and has 32 MB of RAM, and is quite adequate for these tasks. It has serial port built in. It's based on a ARM920T.
This would be overkill for your job; I mention it so you have another data point.
For several years I've been using a gumstix to do prototyping and testing and I've had good results with it. I don't know if the processor they are using (Intel PXA255 on my board) is considered low-cost, but the entire Verdex line seems pretty cheap to me for an adaptable device.
ucLinux is designed specifically for resource constrained targets, but perhaps more importantly for targets without an MMU.
However you have to have a good reason to use Linux on such a system rather than a small real-time executive. Out-of-the-box networking, readily available drivers and protocol stacks for complex hardware and support for existing POSIX legacy or open source code are a few perhaps. However if you don't need that, Linux is still large, and you may be squandering resources for no real benefit. In most cases you will still need off-chip SDRAM and Flash if you choose Linux of any flavour.
I would not regard serial I/O as 'complex hardware', so unless you are running a complex, but standard protocol, your brief description does not appear to warrant the use of Linux IMO
My DLINK DIR-320 router runs Linux inside.
And I know some handymen, flashing it with Optware and connecting USB-hub, HDDs, USB-flash, and much more.
It's low-cost ready for use "platform". (If you don't need mass production). But maybe more powerful than you need.
Additionally, it can be configured wirelessly via web-interface even through your pda :)
I'm asking this question because I was investigating the Haiku OS (a BeOS descendant).
The goal of the BeOS operating system was to create a desktop environment that handles multimedia well and is very responsive. They manage this by creating a kernel that has "pervasive multi threading".
Other operating systems (Linux, Windows etc.) don't have this "pervasive multi threading" and hence, aren't that responsive. (no flame wars please...)
Could someone explain the (subtle) differences between the "pervasive multi threading" (like in BeOS/Haiku) and the multi-threading used in Windows or Linux?
What are the implications for a developer for the different multi threading systems?
I found an interesting site about BeOS Multi-threading...
BeOS Multi threading
Copied from an answer I made for the now closed question "What is/was so terrific about BeOS [closed]", but applies here quite nicely:
From memory, the odd thing about BeOS development is that the GUI really is multithreaded, unlike GUI frameworks on other platforms, which tend to be absolutely single-threaded.
This meant that developing GUI applications for BeOS is completely different, but I assume that this meant the GUI's were more responsive, without requiring explicit design at the application level for handling GUI interactions.
Of course, this does mean that using mutexes and the like are more important, and porting GUI applications from other OS's to BeOS are difficult unless the BeOS GUI library is effectively turned into a single-threaded library by using and enforcing a single application-wide mutex.
Linux, Windows, and almost all other OS's I can think off that I've used in the past decade support multithreading, Linux and windows both which utilise multithreading in substantially different ways but do so very well - however, BeOS really uses multithreading pervasively - and this is made obvious by, eg, the GUI framework, whereas most others are strictly single-threaded. (Or, at the most extreme, permit multiple threads from access with undefined consequences...)