I look for an open source RTSP/RTP stack with C language because I want to connect from a micro-controller to media servers to play internet radio stations
live555 is an open source project which contains RTSP/RTP stack, implemented in C++.
So you may need to encapsulates a C interface to it.
A number of open source clients for RTSP/RTP exist such as mplayer, xine, gstreamer, vlc, etc. -- all of them have client code for RTSP/RTP within them.
Here's a webradio project that runs on ARM Cortex-M3 platforms and includes RTSP Shoutcast/Icecast functionalty. It looks like they wrote their own stack. I'm not sure how portable it might be. It looks like it's maybe at least minimally abstracted from the StellarisWare drivers they're using. It's under the New BSD License as well.
Related
I'm attempting to utilize the socket.h functions within Windows. Essentially, I'm currently looking at the sample code at https://beej.us/guide/bgnet/html/multi/clientserver.html#datagram. I understand that socket.h is a Unix function -- is there anyway I can easily emulate that environment while compiling this sample code? Does a different IDE / compiler change anything?
Otherwise, I imagine that I need to utilize a virtualized Linux environment, which may be best anyways as the code will most likely be running in a UNIX environment.
Thanks.
You have two options:
Use Cygwin (Unix emulation library).
Port to Winsock (Windows standard library).
Cygwin: lets you compile your Unix sources mostly untouched, but ties you to the Cygwin emulation library. This have two implications: general performance -no only network- will probably be less than optimal; and the target environment must have (at run time) the Cygwin DLL installed.
Winsock: this requires you to replace sys/socket.h (BSD sockets library, UNIX standard for the TCP/IP stack) with winsock2.h, and rewrite some parts of the code - not much, but some.
Some related questions with valuable info:
Differences between winsock and BSD socket implementations
Some Issues About Cygwin[Linux in Windows] (socket,thread,other programming and shell issues)
Examples for Winsock?
I think you are looking for Winsock library.
Writing cross platform network applications is not easy with what the BSD standard provides you. Sure it will work but you'll have to make some replacements like replacing ioctl (if needed) with ioctlsocket (on windows). More differences here.
My advice is to use a library that hides these ugly differences and provides a unified way of communicating. I personally use ACE. You have plenty of examples that show you how to create a server and a client. Copy from the samples and see how they do it there. Their mailing lists are of great help also (don't forget to use the PRF - see the source tree for the Problem-Report-Form). You can borrow the books for more information. Important note: by using ace you can use ACE wrapper functions like socket, setsockopt, ioctl etc. without worry that they will not work. Unfortunately this adds a library dependency which is not always an option. But ACE has more powerfull features which I'm sure you'll like once you discover them. Hints: Reactor, Proactor.
I've been tasked with adding streams support (C89/C90) to the libraries for my company's legacy embedded C compiler. Our target hardware typically has 1MB or less of code space and does not have an operating system.
We have a lot of stream-like implementations throughout the codebase that I can use as a starting point. For example, a console that works over a TCP sockets or serial port, a web server that reads from FAT on SD card or in-memory file, and even a firmware updater that reads from many sources.
Before I go and re-invent the wheel, I'm wondering if there are existing implementations that I could either port or use as a starting point for my work. Even though we provide full source code to our customers, GPL-licensed code isn't an option since our customers don't want to release source code to their products.
Can anyone recommend a book (annotated Unix source, CompSci text) or public domain/BSD-licensed source? I'd prefer to look at an older OS targeted to a single device, as current operating systems contain a tangle of macros and layers of typedefs that make following even a simple struct definition difficult.
Take a look at P.J. Plauger's book The Standard C Library, which describes in detail one possible implementation of the complete C89 standard library.
You should be able to pull most of what you need from the source code for the GNU C standard library. It is licensed with the Lesser GPL, which means you can link to the library without affecting the license of your software (or forcing your customers to release their code). Porting this to your platform (thus keeping the LGPL-ed code in its own library) may be easier than implementing your own from scratch.
Several different projects have taken GNU GLIBC and optimized it for embedded systems. You may want to look at:
Embedded GLIBC (LGPL)
uLIBC (LGPL)
Newlib (multiple free licenses)
In particular, EGLIBC and uLIBC were designed to run properly on embedded systems that lack a MMU.
You can also have a look at BSD's implementation of libc
Alternatively there is STLSoft, who provides several libraries (including the C standard lib) under a BSD license. I can't attest to their quality since I haven't used their code myself, but it might be worth looking at if you can't work LGPL-ed code into your project.
Wouldn't *BSD (Net|Open|Free)'s libc be suitable? At least as a starting point.
Try looking at http://www.minix3.org/
Check your development tools. Some development tools come with their on source for their software libraries.
I took the source for the Compiler's printf and adapted for a debug port on an embedded system. There is less work when you have a foundation to build from.
I'm lookin for a portable wiimote library. I want to use the wiimote for the hardware it has (but I don't need to access any data stored on it).
Required features:
access to all the buttons (as an exception, no use of the power button is OK)
make the wiimote play sound
talk to nunchuks and classic controllers
preferably: make the wiimote rumble.
interface with C. Preferably native C. Bonus points for bindings with Haskell or python.
The library should port to Linux, Windows and OS X (in order of importance) and should be agnostic with respect to CPU architecture.
Anyone got a good suggestion?
Haven't use it (I've only read about the managed Wiimote library really), but you may want to check out wiiuse. It seems like the most complete of the native libararies.
Others include:
GlovePIE
WiiYourself
You can use my WiiMouse program to do this (which is based on the wiimotelib open source project), it allows you to connect via named pipes and play PCM sounds and use all the attachments including the MotionPlus, it even calculates the MotionPLus vectors for you, you can get it here:
http://home.exetel.com.au/amurgshere/wiimouse.phtml
See the download for an example on how to connect to a wiimote via named pipes and play sounds and stuff.
I am trying to create a GUI for a c code written in LINUX.
This code basically connects two systems, opens the serial port, writes data from one system to the other via the port.how do I go about this?
The development tools present with me are Qt designer version 3.3.5 and K Develop, which one should I use.and how to go about it?
In Linux, every hardware device is mapped to the file-system using standard file-system permissions.
If you're just using a simple serial port protocol under Linux, you can treat any serial port device as a file. Meaning, they can be opened, read, written and handled just using standard files.
The 'filename' for a serial port is typically /dev/ttyS0 or /dev/ttyUSB0 depending on the type of serial port. It is often symlinked to /dev/modem on regular distributions.
I think you may be looking in the wrong place. You should probably search the web for a tutorial on C++ programming, or get a book on it (there are plenty out there). Once you're comfortable with C++ (it'll take a while if you're not already), you can start to read about writing KDE applications. There are probably some introductory things to read on the KDE website, and don't forget that Google is your friend throughout the process ;-)
By the way, Qt Designer is just a program for doing GUI layouts, while KDevelop is a full featured IDE that combines Qt Designer, a text editor, and a bunch of other stuff. You can use KDevelop for writing anything from very simple "Hello World" C++ programs up to, well, something as complex as KDevelop itself.
If you've actually got to write the serial port part (I'm not clear on this from your question), the other system calls you'll need to know about are 'ioctl' and 'termios', to set various serial port parameters.
Seems your using QT. You should try QextSerialPort which is a serial port class for QT.
The doc.trolltech.com site has a huge amount of documentation. You should go definitely take a look.
I would use the latest available Qt library for your distro, since it is a new developpment.
Regarding the serial port C code, I would keep it and call it from your C++ code. Beware of time consuming operations that can ruin the interactive feeling of your app.
What things should be kept most in mind when writing cross-platform applications in C? Targeted platforms: 32-bit Intel based PC, Mac, and Linux. I'm especially looking for the type of versatility that Jungle Disk has in their USB desktop edition ( http://www.jungledisk.com/desktop/download.aspx )
What are tips and "gotchas" for this type of development?
I maintained for a number of years an ANSI C networking library that was ported to close to 30 different OS's and compilers. The library didn't have any GUI components, which made it easier. We ended up abstracting out into dedicated source files any routine that was not consistent across platforms, and used #defines where appropriate in those source files. This kept the code that was adjusted per platform isolated away from the main business logic of the library. We also made extensive use of typedefs and our own dedicated types so that we could easily change them per platform if needed. This made the port to 64-bit platforms fairly easy.
If you are looking to have GUI components, I would suggest looking at GUI toolkits such as WxWindows or Qt (which are both C++ libraries).
Try to avoid platform-dependent #ifdefs, as they tend to grow exponentially when you add new platforms. Instead, try to organize your source files as a tree with platform-independent code at the root, and platform-dependent code on the "leaves". There is a nice book on the subject, Multi-Platform Code Management. Sample code in it may look obsolete, but ideas described in the book are still brilliantly vital.
Further to Kyle's answer, I would strongly recommend against trying to use the Posix subsystem in Windows. It's implemented to an absolute bare minimum level such that Microsoft can claim "Posix support" on a feature sheet tick box. Perhaps somebody out there actually uses it, but I've never encountered it in real life.
One can certainly write cross-platform C code, you just have to be aware of the differences between platforms, and test, test, test. Unit tests and a CI (continuous integration) solution will go a long way toward making sure your program works across all your target platforms.
A good approach is to isolate the system-dependent stuff in one or a few modules at most. Provide a system-independent interface from that module. Then build everything else on top of that module, so it doesn't depend on the system you're compiling for.
XVT have a cross platform GUI C API which is mature 15+ years and sits on top of the native windowing toollkits. See WWW.XVT.COM.
They support at least LINUX, Windows, and MAC.
Try to write as much as you can with POSIX. Mac and Linux support POSIX natively and Windows has a system that can run it (as far as I know - I've never actually used it). If your app is graphical, both Mac and Linux support X11 libraries (Linux natively, Mac through X11.app) and there are numerous ways of getting X11 apps to run on Windows.
However, if you're looking for true multi-platform deployment, you should probably switch to a language like Java or Python that's capable of running the same program on multiple systems with little or no change.
Edit: I just downloaded the application and looked at the files. It does appear to have binaries for all 3 platforms in one directory. If your concern is in how to write apps that can be moved from machine to machine without losing settings, you should probably write all your configuration to a file in the same directory as the executable and not touch the Windows registry or create any dot directories in the home folder of the user that's running the program on Linux or Mac. And as far as creating a cross-distribution Linux binary, 32-bit POSIX/X11 would probably be the safest bet. I'm not sure what JungleDisk uses as I'm currently on a Mac.
There do exist quite few portable libraries just examples I've worked within the past
1) glib and gtk+
2) libcurl
3) libapr
Those cover nearly every platform and so they are extremly useful tool.
Posix is fine on Unices but well I doubt it's that great on windows, besides we do not have any stuff for portable GUIs there.
I also second the recommendation to separate code for different platforms into different modules/trees instead of ifdefs.
Also I recommend to check beforehand what are the differences in you platforms and how you could abstract them. E.g. this is some OS related stuff (e.g. the annoying CR,CRLF,LF in text files), or hardware stuff. E.g. the previous mentioned posix compability doesnt stop you from
int c;
fread(&c, sizeof(int), 1, file);
But on different hardware platforms the internal memory layout can be complete different (endianess), forcing you to use conversion functions on some of the target platforms.
You can use NAppGUI for both console and desktop apps. The SDK uses ANSI-C and your code will work on Windows/macOS/Linux.
https://www.nappgui.com
It's free and OpenSource.