iam currently using NIOS II with Quartus II v12.0
Since Nios II uses Language C, it would be allowed to open files, but the command fopen("filename","readmode"); is not avaiable for using, cause its not located on stdio.h from Nios, so my doubt is, how can I open a file in Nios? would I need to use a new library? will I have to change my codeblocks stdio.h to my Nios one?
Thanks for now.
I just took a look at the Nios II Software Developers Handbook, and see that uses the Newlib C library, and the developer manual refers to fopen() so I can only assume that you are incorrect. Newlib is open-source, so you could investigate for yourself.
Even then Newlib library does not implement a file-system in any case - stdio is not a filesystem; rather it provides a standard interface to any stream I/O device. The file-system itself is normally provided by an operating-system or third-party library.
Even if you have a file-system, you still have to provide the low-level interfacing between it and stdio in any case, via the Newlib syscalls stubs in this case.
NiosII defines only the processor architecture, any file system hardware would be entirely proprietary, so it is not possible to have file-system support that works out of the box in any case - it would have to be adapted to your hardware.
What kind of device are you intending on creating a file-system on? You might use a third-party library such as EFSL or ELM FatFs. You could use them stand-alone or integrate them into stdio by implementing appropriate syscalls.
I have used the Demonstration project from DE2-115 DVD and got an FAT library, now I can open files.
Related
I trying to develop an application to decode AAC on an ARM Cortex A9 processor. I will not be using an OS. Therefore this will be a bare-metal application.
Are there any libraries already available for this?
I used mstorsjo-fdk-aac library on windows and Ubuntu. Is it possible to compile it for ARM to run on without an OS?
Can anyone point me in the correct direction? I searched a lot in the internet but could not get anywhere.
Thank you.
The fdk-aac codec library does depend on a libc, for standard C functions like malloc, free, math functions like sin, stdio for file handling etc. If you run on bare metal, you need to provide these functions somehow. (If you don't need the sublibrary for opening files, you probably don't need to provide the stdio functions, or it is ok to replace them with stubs.) Even if the files are C++, they don't seem to use the standard C++ library, so you probably don't need to provide that.
Luckily most of these functions seem to be separated out for easy replacement/redirection - have a look at libSYS/src/genericStds.cpp to see which facilities it depends on from the platform.
I have a C program which contains #include <dos.h> header. It shows a compile time error. I know that the dos.h header file is not valid in Linux.
Is there any other equivalent header for dos.h in Linux?
Linux is a Posix/Unix like system, so you should learn the system calls and facilities that you can use. Read the advanced unix programming book (or some equivalent; AUP is considered a very good book). You can also read advanced linux programming (even online, a copy is here). So Linux don't have a dos.h header.
You could also type man 2 intro to get an intro to syscalls, and their list in in syscalls(2) man page. From an application's point of view syscalls are elementary operations provided by the Linux kernel.
The GNU libc provides a big lot of functionality (e.g. standard C functions like malloc and fprintf, and system functions like fgetpwent to query user database, etc etc...) above the system calls. Almost every Linux program uses it.
If you care about coding stuff which should be portably runnable (after recompilation) on other similar systems (e.g. MacOSX or FreeBSD) consider following the Posix standard.
If you want to code a terminal screen application, consider using ncurses.
If you care about graphical interfaces, use a graphical toolkit like Qt or Gtk; they usually interact with an X11 server (and both Qt and Gtk are able to run on some other non Posix systems, e.g. Windows, by providing a common graphical abstraction layer.). Both Gtk and Qt are adding an abstraction layer (Glib and QCore respectively) above system functions and facilities (in particular above the pthreads standard thread library).
At last, Linux is free software; so you might find interesting to look inside the source code (of a library or utility) that you are using. You could even improve it and contribute to it.
In all these aspects, Linux programming is very different from Windows or DOS.
Don't try to mimic every Windows or Dos function into Linux (e.g. don't ask the equivalent of every dos.h function); learn the Posix/Unix way of thinking and coding.
The time(7) man page tells you a lot about time (various meanings and functions about it) on Linux.
Don't forget to ask warnings from the compiler with gcc -Wall -Wextra; as a general rule, improve your source code till you get no warnings.
There cannot be an exact Linux equivalent of dos.h because Linux (i.e. Unix or Posix spec) and Windows are systems with different features and concepts. However several free libraries (I mentioned Glib and QCore) are providing common abstractions to fit into Linux and into Windows, so if you want to develop software portable to Windows and to Linux I suggest using these libraries instead (use them both on Windows and on Linux).
(I also suspect that Microsoft would use legal threats -patent or copyright based- to avoid that free clone of their proprietary dos.h, given their monopolistic reputation and their aversion to standards and to free software; I admit I have strong opinions against Microsoft..)
dos.h header file is interface to the DOS operating system. They are not portable to operating systems other than DOS (means not works in Linux). Which functionality in dos.h you are going to use?
#include<dos.h> is not available for Linux
but if you want to use dos.h for displaying the time you can use the system function and do it like this
prototype -> system(command);
system("date +%H:%M:%S");
if you want your program to sleep for a specific seconds
try this
system("sleep 3") //sleep for a 3 seconds
or use this
std::this_thread::sleep_for(std::chrono::milliseconds(100));
but you have to include the thread header file #include<thread>
I am learning network programming through the sample source codes from this link http://cs.baylor.edu/~donahoo/practical/CSockets/textcode.html. During the compilation, just wondering why in Solaris environment, i have to manually link socket and nsl library in the make file but when in the linux machine, i dont need to do that ?
Documentation used: http://developers.sun.com/solaris/articles/solaris_linux_app.html
This is because linux's libc, the glibc (-lc, which is linked by default to all programs) includes socket part of POSIX; and nis/nis+ dynamic libraries in linux are loaded dynamically by libc too.
But in Solaris, there are a lot of libraries with basic functionality, which are not in libc.
(libc, libucb, libmalloc, libsocket, libxnet, etc). I think, it was a design solution to allow user link only parts of API he needs.
In linux there are some basic libraries outside libc too: libaio, librt, libm.
With separate library it is easier to update only some parts of system; and it is possible to have several implementations (e.g. to provide greater compatibility/workarounds with older versions of UNIX) of some libraries coexisting in same system.
This question is discussed a lot, e.g. http://web.archiveorange.com/archive/v/KcxCHdLNpD6NANxmAt3b http://mail.opensolaris.org/pipermail/opensolaris-code/2007-January/010316.html
are seriously considering folding libnsl and libsocket into libc.
It would be nice to move ONLY the current POSIX-based and other
standards-based functionality (Unix98 etc.) libnsl+libsocket functions
to libc and keep all the compatibilty-wrapper stuff in libnsl/libsocket
to avoid that libc gets bloated with 20years of Unix
backwards-compatibility workarounds
Because in Linux, the entire networking API is implemented in libc.so which is linked into every C program by default, while in Solaris, its implemented in separate libraries.
I am using a custom user space environment that has barely no OS support: only one char device, mass storage interface and a single network socket.
To provide C programming to this platform, I need a libc. Is there any libc project that is configurable enough so that I can map low-level IO to the small API I have access to ?
AFAIK glibc and uclibc are expecting linux syscalls, so I can't use them (without trying to emulate linux syscalls, which is something I prefer to avoid).
There are several different libc's to choose from, but all will need some work to integrate into your system.
uClibc has a list of other C libraries.
The most interesting ones on that list are probably
dietlibc
newlib
FreeDOS has a LIBC
EGLIBC might be simpler to port than the "standard" glibc.
newlib might serve this purpose.
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.