I've recently started porting the C implementation of my project to the NIOS II system and I seem to have hit a snag. My original implementation uses file operations (fopen, fscanf, fgets,etc.). However I'm using the University Program IP Core and therefore have to use the HAL functions provided by Altera.
So the question is, will I have to rewrite the portions where I read in formatted text and read byte by byte and then format? Or is it possible to keep my current code?
PS
I am using Quartus II 13.0 with Eclipse Build Tools and my development board is the Altera DE1.
The only solution I could think of is to save my whole text file into an array and then change the formatted file operations to their string counterparts, however this would probably take up a lot of space. I don't think using an OS on the NIOS II is an option for me either.
Related
I am currently working on a project which requires to use a embedded soft core. I wrote a pong game using VHDL (ISE) and synthesised it onto the FPGA, the next step is going to shift the numerical calculation part to soft core which means i need to rewirte this code in C. However, ISE can not achieve this function, what design suite (software) i can use? Can EDK work?
You have to add a soft processor to your project using EDK and synthesize the new project. Then you can write the software code to run on the soft processor using SDK (Software Development Kit).
I'm trying to write emulator for ARM Cortex M3. How can I read the binary file then decode it? I want to use binary files as a resource of my emulator. I created a project with Atmel Studio and I compiled it. Now, I have a .hex file. I can also convert this file to binary file with hex2bin. After that, how can I use that binary file for fetching and decoding instructions ? I'm working on Visual Studio with C/C++.
First, need to mention that writing an emulator for a processor is not an easy task, other have already spend lot of time on it, you can take a look at QEmu for example. One project is currenlty using Qemu to emulate a Cortex M3 based board, the ZephyrProject.
An intermediate step, could be to use a tool that already understand/decode hex or bin file, and Radare is one of those kind of tool. With it you will be abvle to disassemble many elf files and get the instructions from it (that you'll then have to emulate ;) ).
That said, if you still really want/need to make the emulation, and start to read and understand the hex or binary files, the first thing to do will to study the Intel Hex file format (yes, even ARM is using this Intel format ;) ).
You can find the official specification here or in the technical support website of ARM.
Have fun ;)
I'm a newbie to learning OS development. From the book I read, it said that boot loader will copy first MBR into 0x7c00, and starts from there in real mode.
And, example starts with 16 bit assembly code.
But, when I looked at today's linux kernel, arch/x86/boot has 'header.S' and 'boot.h', but actual code is implemented in main.c.
This seems to be useful by "not writing assembly."
But, how is this done specifically in Linux?
I can roughly imagine that there might be special gcc options and link strategy, but I can't see the detail.
I'm reading this question more as an X-Y problem. It seems to me the question is more about whether you can write a bootloader (boot code) in C for your own OS development. The simple answer is YES, but not recommended. Modern Linux kernels are probably not the best source of information for creating bootloaders written in C unless you have an understanding of what their code is doing.
If using GCC there are restrictions on what you can do with the generated code. In newer versions of GCC there is an -m16 option that is documented this way:
The -m16 option is the same as -m32, except for that it outputs the ".code16gcc" assembly directive at the beginning of the assembly output so that the binary can run in 16-bit mode.
This is a bit deceptive. Although the code can run in 16-bit real mode, the code generated by the back end uses 386 address and operand prefixes to make normally 32-bit code execute in 16-bit real mode. This means the code generated by GCC can't be used on processors earlier than the 386 (like the 8086/80186/80286 etc). This can be a problem if you want a bootloader that can run on the widest array of hardware. If you don't care about pre-386 systems then GCC will work.
Bootloader code that uses GCC has another downside. The address and operand prefixes that get get added to many instructions add up and can make a bootloader bloated. The first stage of a bootloader is usually very constrained in space so this could potentially become a problem.
You will need inline assembly or assembly language objects with functions to interact with the hardware. You don't have access to the Linux C library (printf etc) in bootloader code. For example if you want to write to the video display you have to code that functionality yourself either writing directly to video memory or through BIOS interrupts.
To tie it altogether and place things in the binary file usable as an MBR you will likely need a specially crafted linker script. In most projects these linker scripts have an .ld extension. This drives the process of taking all the object files putting them together in a fashion that is compatible with the legacy BIOS boot process (code that runs in real mode at 0x07c00).
There are so many pitfalls in doing this that I recommend against it. If you are intending to write a 32-bit or 64-bit kernel then I'd suggest not writing your own bootloader and use an existing one like GRUB. In the versions of Linux from the 1990s it had its own bootloader that could be executed from floppy. Modern Linux relies on third party bootloaders to do most of that work now. In particular it supports bootloaders that conform to the Multiboot specification
There are many tutorials on the internet that use GRUB as a bootloader. OS Dev Wiki is an invaluable resource. They have a Bare Bones tutorial that uses the original Multiboot specification (supported by GRUB) to boot strap a basic kernel. The Mulitboot specification can easily be developed for using a minimal of assembly language code. Multiboot compatible bootloaders will automatically place the CPU in protected mode, enable the A20 line, can be used to get a memory map, and can be told to place you in a specific video mode at boot time.
Last year someone on the #Osdev chat asked about writing a 2 stage bootloader located in the first 2 sectors of a floppy disk (or disk image) developed entirely in GCC and inline assembly. I don't recommend this as it is rather complex and inline assembly is very hard to get right. It is very easy to write bad inline assembly that seems to work but isn't correct.
I have made available some sample code that uses a linker script, C with inline assembly to work with the BIOS interrupts to read from the disk and write to the video display. If anything this code should be an example why it's non-trivial to do what you are asking.
I was wondering if anyone knows an efficient way to program the FPGA(PL) for a Xilinx Zynq-7 series or related devices,from a host C program (not on the SoC, but from the host PC). Is there an Xilinx API I can use/include in my program. As the only way I can think of doing it at the moment is invoking command line programming via Impact.
Basically I want to put the SDK "Program FPGA" functionality in my host C program where the user selects a prebuilt .bit file (and .elf file if possible) to program the FPGA/(SoC). This is just for a test of concept, later I would like to put this dynamic configuration onto one of the ARM CPU's.
Many Thanks
Sam
At the very least you'll need an intermediate MPU/MCU that can read from USB, as at startup most FPGAs aren't capable of much at all. I'm guessing this'll make it hard to find a MPU/library pair to do so, because there are so many options, each of which would be pretty application-specific. You're better off starting with programming them off an ARM chip, since you'll need some CPU with the FPGA in any case.
This seems somewhat useful.
I have an old program written about 1990 but modified several times. Around 2005 I started to use a program PixOps.c from Apple Computer to read different kinds of picture files.
It has worked very well until I changed to Apple's new system Mountain Lion. Now I get several errors. Unfortunately PixOps uses a number of routines not available in Mountain Lion any longer.
Can anyone help me how to find a C routine to read JPEG-images from a file, decode them and store them in a simple bitmap? My program manipulates the picture and then the program draws the new picture on the screen. After that I also want to write the new picture back to a file as a JPEG-picture.
You should look into using a library. The standard for JPEG is called libjpeg. It works on most typical operating systems, including Mac OS X.
The project is also on SourceForge, here.