I am new to embedded systems and have been trying to port over a MP3 conversion program to an ARM-based STM32L476G-DISCO development board. I'm also using the free System Workbench software based on Eclipse. I've been successful to the point that I have compiled the program and flashed it onto the board. It even runs right up to the point that the program asks for file input (.wav).
My question is how do I implement the file handling part? Previously when running the original windows console app I would just send in a command line argument like "'>C:\file.wav < C:\file.mp3".
The board comes with 128Mbit of flash memory utilizing QSPI for communications as well as internal flash. Do I need a file system to read/write a file into my program? I was thinking to start simple and just embed the file but I don't know how to call it in my code. I can program the memory manually via the programming software but again, all I know is the address of where I flashed the data.
If you have written the data to the internal flash, all you need is its address - it is no longer a "file" it can be treated as if you have read the data from the file into that location. Rather then separately programming the data from your application you could write a code generation tool that reads teh fike on teh development host and converts it to a C code data array thus:
static const uint8_t wav_file[] = { '\x00, `\x55` ...
...
... } ;
that you then compile and link to your application code.
This would then allow the linker to locate your data and avoid any issues of the application code and the data encroaching on each other. Moreover it gives toy data a symbolic start address and a size that can be determined by sizeof(wav_file).
You cannot however use this method if the data is stored in the external flash since that is not memory mapped. In that case the data will need to be read into RAM for processing.
If your audio library expects a file and you do not wish to modify it, then yes you need a file system. A file system is probably the simplest and safest means of managing the external flash in any case.
Related
I am currently writing a C program on an Industrial PC.
The operating system is Ubuntu. The PC is using flash file system.
I did some researches on flash file system. It turns out that flash file system has limited times of rewriting data on the same spot.
However, my program may need to fwrite files over and over to keep the config data.
My program needs to keep running on this PC over years, and it needs to record data every minutes.
I am wondering if I fwrite a file many times, is the system gonna rewrite data on the same memory spot? Is that going to cause the flash file system to be broken?
First thing to see is whether you are using a NOR flash file system or NAND flash file system. Because both of them differs in the number of erase cycles that can be done reliably .
Please see the link for differences between the two https://focus.ti.com/pdfs/omap/diskonchipvsnor.pdf
The problem also depends upon the amount of data you want to write. If its small you can write a custom filewrite function using putc instead of using the fwrite.
You can see one method here
https://bytes.com/topic/c/answers/876395-fwrite-efficiency-alternative
Hope it helps.
I am trying to load an ascii file into memory using the command line and I would like to know if there is a command that does it using ARM DS-5 IDE.
I have in the past use the previous ARM tools (RVDS) and been able to perform this task using the readfile command.
Thanks in advance.
The DS-5 loadfile and load commands will annoyingly only work with executable images because they both demand to know an entry point address. Simply putting arbitrary data (such as your text, or a raw binary like a Linux zImage) into the target's memory is done with very-unintuitive-named restore command, with which you still have to add the binary argument to avoid getting the same error as the others about not understanding the file format.
ARM Infocenter: DS-5 File-related commands
How to get the hardware information using C code in Linux like information regarding CPU, RAM, Network adaptor, Video adaptor, Sound adaptor etc.?
I don't want to parse /proc/*info file and also don't want to use hwinfo/dmidecode. Is there any open source library available?
I've been following the "Mike OS Guide" to make my own kernel, and I got it working. But then I went onto the many guides on the internet for making a boot sector in NASM that loads a main function from a compiled C object. I have tried compiling and linking with all kinds of GCC installations:
x86_64-pc-linux-
arm-uclinux-elf-
arm-agb-elf-
arm-elf-
arm-apple-darwin10-
powerpc-apple-darwin10-
i686-apple-darwin10-
i586-pc-linux-
i386-elf-
All of them fail once I put them onto a floppy like I do with the MikeOS bootstrap. I've tried various tutorials on http://www.osdever.net/ like the one here and I've tried http://wiki.osdev.org/Bare_Bones , but none work when trying to compile on a Mac, yet I have not tired on an actual Linux machine yet. But I was wondering how I could get a bootstrap in assembly the calls the C function and put them together into a working kernel file and then load the onto a floppy file then onto an ISO like in the MikeOS tutorial. Or should I just make the kernel.bin and load it with syslinux? Could anyone give me a tip on how to make this all work on a Mac developement environment? I have tolls via macports and homebrew so that helps. Anyone successively done this?
EDIT
Here's my bootsector so far.
I just wanna know how to jump to an extern function from the C and link it.
There's a few problems with this. First of all, all the compilers you mentioned output either 32-bit or 64-bit code. That's great, but when the boot sector starts, it's running in 16-bit real mode. If you want to be able to run that 32-bit or 64-bit code, you'll need to first switch to the appropriate mode (32-bit protected mode for, well, 32-bit, and long mode for 64-bit).
Then, once you switch to the appropriate mode, you don't even have that much space for code: boot sectors are 512 bytes; two bytes are reserved for the bootable signature, and you'll need some bytes for the code that switches to the appropriate mode. If you want to be able to use partitions on that disk or maybe a FAT filesystem, take away even more usable bytes. You simply won't have enough space for all but the most trivial program.
So how do real operating systems deal with that? Real operating systems tend to use the boot sector to load a bigger bootloader from the disk. Then that bigger bootloader can load the actual kernel and switch to the appropriate mode (although that might be the responsibility of the loaded kernel — it depends).
It can be a lot of work to write a bootloader, so rather than rolling your own, you may want to use GRUB and have your kernel comply to the Multiboot standard. GRUB is a bootloader which will be able to load your kernel from the disk (probably in ELF format) and jump to the entry point in 32-bit protected mode. Helpful, right?
This does not free you from learning assembly, though: The entry point of the kernel must be assembly. Often, all it does is set up a little stack and pass the appropriate registers to a C function with the correct calling convention.
You may think that you can just copy that rather than writing it yourself, and you'd be right, but it doesn't end there. You also need assembly for (at least):
Loading a new global descriptor table.
Handling interrupts.
Using non-memory-mapped I/O ports.
…and so on, not to mention that if you have to debug, you may not have a nice debugger; instead, you'll have to look at disassemblies, register values, and memory dumps. Even if your code is compiled from C, you'll have to know what the underlying assembly does or you won't be able to debug it.
In summary, your main problem is not knowing assembly. As stated before, assembly is essential for operating system development. Once you know assembly thoroughly, then you may be able to start writing an operating system.
I am doing a project with a fairly powerful 32-bit microcontroller, the STM32F4 (with 192K RAM and 1024K Flash). I am using C. The system I wish to create consists of this controller (I'll call it the 'host') and a small module (the 'client').
The client simply contains a memory bank and an LED controller that both use the same data line (I2C) to connect to the host. The host can read from the memory and send commands to control the LED outputs on the client.
I want to be able to write code directly on the client's memory. Then at runtime, the host will pull the code from the client and run it - and the code will be limited to doing two things:
Manipulating variables in an arbitrary way
Sending commands to the LED driver based on these variables.
I want these limitations so that anyone can write code for a client without being able to do something malicious to the host. I am looking for a way to run a scripting language interpreter on the microcontroller for this purpose. The code on the client would then be text-format and it would be interpreted on the host.
I have looked into eLua but it looks like it would require me to implement all of my C code on the host as Lua libraries, which I would like to avoid. Does anyone know of a solution where I can just interface to the I2C library and run simple scripts without too much pain?
If not, is there something out there that I can build on to build this simple interpreter myself?
I can provide any clarification if needed.
You have two variants runs on a single engine: bytecode interpreter.
Today I found this intro video: http://www.youtube.com/watch?v=OjaAToVkoTw
Very simple tutorial on making VM from scratch.
And two variants:
cross/target scheme: run compiler you write yourself (flex/bison as
a first candidate) on a host (Windows/Linux/...), and transfer readily to
use bytecode image to Cortex-M target, or
self-hosted compiler runs on target Cortex-M: (a) in native code or (b)
written itself in a bytecode
As a most simple variant, you can implement FORTH system -- its parser need the only lexer, you can write in an hour from scratch, or generate by flex. And you can find a lot of FORTHs some of them works on (1) method: host compiler, and target bytecode interpreter connected via UART.