Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am looking for general purpose programming languages that
have an interactive (live coding) prompt
work in 32 KB of RAM by itself or 8 KB when the compiler is hosted on a separate machine
run on a microcontroller with as little as 8-32 KB RAM total (without an MMU).
Below is my list so far, what am I missing?
Python: The PyMite VM needs 64K flash, 8K RAM. Targets LPC, SAM7 and ATmegas with 8K or more. Hosted.
Lua: The eLua FAQ recommends 256K flash, 64K RAM.
FORTH: amforth needs 8K flash, 150 bytes RAM, 30 bytes EEPROM on an ATmega.
Scheme: armpit Scheme The smallest target is the LPC2103 with 32K Flash, 4K SRAM.
C: Interactive C runs on 68HC11 with no flash and 32K SRAM. Hosted.
C: picoc an open source, cross-compiling, interactive C system. When compiled for AVR, it takes 63K flash, 8K RAM. The RAM could be reduced with effort to keep tables in flash.
C++: AngelScript an open source, byte-code based, C/C++ like scripting language with easy native calls.
Tcl: TinyTCL runs on DOS, 60K binary. Looks easy to port.
BASIC: TinyBasic: Initializes with a 64K heap, might be adjustable.
Lisp
PostScript: (I haven't found a FOSS implementation for low memory yet)
Shell: bitlash: An interactive command shell for Arduino (ATmega). See also AVRSH.
A homebrew Forth runtime can be implemented in very little memory indeed. I know someone who made one on a Cosmac in the 1970s. The core runtime was just 30 bytes.
I hear that CHIP-8, XPL0, PicoC, and Objective Caml have been ported to graphing calculators.
The Wikipedia "Lego Mindstorms" article lists a bunch of programming languages that allegedly run on the Lego RCX or Lego NXT platform.
Do any of them meet your "live coding" criteria?
You might want to check out the other microcontroller Forths at the Forth wiki . It lists at least 4 Forths for the Atmel AVR: amforth (which you already mention), PFAVR, avrforth, and ByteForth.
(Links to those interpreters, as well as this StackOverflow question, are included in the "Embedded Systems" wikibook).
I would recommend LUA (or eLUA http://www.eluaproject.net/ ). I've "ported" LUA to a Cortex-M3 a while back. From the top of my head it had a flash size of 60~100KB and needed about 20KB RAM to run. I did strip down to the bare essentials, but depending on your application, that might be enough. There's still room for optimization, especially about RAM requirements, but I doubt you can run it comfortable in 8KB.
Some AVR interpreters/VMs:
http://www.cqham.ru/tbcgroup/index_eng.htm
http://www.jcwolfram.de/projekte/avr/chipbasic2/main.php
http://www.jcwolfram.de/projekte/avr/chipbasic8/main.php
http://www.jcwolfram.de/projekte/avr/main.php
http://code.google.com/p/python-on-a-chip/
http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=688&item_type=project
http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=626&item_type=project
http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=460&item_type=project
http://www.harbaum.org/till/nanovm/index.shtml
Wren fits your criteria -- by default it's configured to use just 4k of RAM. AFAIK it hasn't seen any actual use, since the guy I wrote it for decided he didn't need an interpreter running wholly on the target system after all.
The language is influenced most obviously by ML and Forth.
Have you considered a port in C of Tiny Basic? Or, perhaps rewriting the UCSD Pascal p-machine to your architecture from Z-80?
Seriously, though, JavaScript would make a good embedded scripting language, but I've no clue what the minimum memory requirements are for the VM + GC, nor how difficult to remove OS dependencies. I played with NJS a while back, which could possibly fit your needs. This one is interesting in that the compiler is written in JavaScript (self hosting).
You can take a look at very powerful AvrCo Multitasking Pascal for AVR. You can try it at http://www.e-lab.de. MEGA8/88 version is free. There are tons of drivers and simulator with JTAG debugger and nice live or simulated visualizations of all standard devices (LCDCHAR, LCDGRAPH, 7SEG, 14SEG, LEDDOT, KEYBOARD, RC5, SERVO, STEPPER...).
You're missing EmbedVM, homepage here, svn repo here. Remember to check out both [1,2] videos on the front page ;)
From the homepage:
EmbedVM is a small embeddable virtual machine for microcontrollers
with a C-like language frontend. It has been tested with GCC and AVR
microcontrollers. But as the Virtual machine is rather simple it
should be easy to port it to other architectures.
The VM simulates a 16bit CPU that can access up to 64kB of memory. It
can only operate on 16bit values and arrays of 16bit and 8bit values.
There is no support for complex data structures (struct, objects,
etc.). A function can have a maximum of 32 local variables and 32
arguments.
Besides the memory for the VM, a small structure holding the VM state
and the reasonable amount of memory the EmbedVM functions need on the
stack there are no additional memory requirements for the VM.
Especially the VM does not depend on any dymaic memory management.
EmbedVM is optimized for size and simplicity, not execution speed. The
VM itself takes up about 3kB of program memory on an AVR
microcontroller. On an AVR ATmega168 running at 16MHz the VM can
execute about 75 VM instructions per millisecond.
All memory accesses done by the VM are parformed using user callback
functions. So it is possible to have some or all of the VM memory on
external memory devices, flash memory, etc. or "memory-map" hardware
functions to the VM.
The compiler is a UNIX/Linux commandline tool that reads in a *.evm
file and generates bytecode in vaious formats (binary file, intel hex,
C array initializers and a special debug output format). It also
generates a symbol file that can be used to access data in the VM
memory from the host application.
The C-like language looks like this: http://svn.clifford.at/embedvm/trunk/examples/numberquizz/vmcode.evm
I would recommend MY-BASIC, runs with in minimum 8 KB RAM, and easy to port.
There's also JavaScript, via Espruino.
This is built specifically for Microcontrollers and there are builds for various different chips (mainly STM32s) that fit a full system into as little as 8kB RAM.
Have you considered simply using the /bin/sh supplied by busybox? Or on of the smaller scripting languages they recommend?
Prolog - http://www.gprolog.org/
According to a google search "prolog small" the size of the executable can be made quite small by avoiding linking the built-in predicates.
None of the languages in the list in the question or in the answers proved satisfactory for the requirement of super easy compilation and integration into an existing micro controller project (disclosure: I didn't actually try every single one of the suggestions).
I found instead tinyscript which is a single .c+.h file that compiled with the rest of the source files on my project with the only additional configuration required being to provide a void outchar(int c) which can be empty if you don't require output from the scripts.
For me speed of execution is far less important than ease of build and integration and interop with C, as my use case is mainly just calling some C functions in order.
I have been using in my previous work busybox on a BlackFin.
we compiled perl + php for it, after changing s/fork/vfork/g it worked pretty good... more or less. Not having an MMU is not a good idea. The memory fragmentation will kill the server pretty easily. All I did was:
for i in `seq 1 100`; do wget http://black-fin-ip/test.php; done
It died while I was walking to my boss and telling him that the server is going to die in production :)
I would suggest use python. But now the only problem is the memory overhead right? So I have great idea for people who may be stuck in this problem later on.
First thing's first, write a bf interpreter(or just get source code from somewhere). The interpreter will be really small. Also bf is a Turing complete language. Now you need to write your code in python and then transpiler it to bf using bfpy( https://github.com/felko/bfpy/blob/master/README.md ). I've given you the solution with the least overhead and I am pretty sure a bf interpreter will easily stay under 10KB of ram usage.
Erlang - http://erlang.org/
it can fit in 2MB
http://www.experts123.com/q/is-erlang-small-enough-for-embedded-systems.html
Related
I am new to programmming in rtem and was wondering how are the two, rtems and linux, are different in terms of programming. I understand rtems is an real time operating system but if you were to make a hello world app, wouldn’t the program be the same?
Note that your question is quite generic. There are a lot of detail differences.
One of the biggest is the format of your binary: Most RTEMS binaries are statically linked together. You only have one big binary containing your system and application. There is some dynamic loading supported but it's not the case used by most users.
As already mentioned my n.m. in the comments RTEMS has a lot of the POSIX API (at least the embedded sub set). So you can use a lot of the same API like you do on Linux.
A big differences is that RTEMS has a global address space (on most targets). So you don't have a separation between tasks. That makes pointer errors a bit harder to debug.
Also a difference: Most embedded systems are targeted for long running applications. In such applications (regardless whether you are on Linux or on RTEMS or on any other system) you should be careful to clean up your stuff (close files, free memory, ...). In Linux (or other desktop class systems) you have processes and the kernel cleans up all resources after your process exits. Although you can create threads in RTEMS no one cleans up after a thread exits.
The POSIX attribute defaults for threads are not specified in the standard and may vary between RTEMS and Linux.
I am a complete newbie to operating system and aiming to write my own kernel.
I understand that i will have to write my own device drivers as well.
How do i start with writing my driver?
The tasks of project are as follows.
1.Defining GDT in assembly language
2.Creating boot sector
3.Interrupt handling
4.Screen Driver
5.Keyboard driver
6.Hard disk driver
7.File system
8.I/O programming
9.Physical memory management
Also is it possible to do this in 3 months ( team of 2 )
As you know (or about to find out) OSes are extremely complicated and interconnected. For example, how are you going to have a working Keyboard driver before you have implemented interrupt handling?
It sounds like your question actually is: "How do I start writing my own OS?" You start by reading "Required Knowledge," "Beginner Mistakes," and "Getting Started" on osdev.
Good luck, and it is going to take a long time... especially if you are learning as you go (which is okay, since your goal is learning and not to make a commercial OS).
Edit: Modifying the Linux kernel is a good way to learn about the internals of an OS. It will let you focus on individual aspects (such as just writing a keyboard driver) and your work environment will be sane. Depending on what you want to do, you will be able to further ease development by creating a kernel module instead directly modifying the kernel.
Define your project and its scope
Set up your work environment (my suggestion, run Ubuntu Server in QEMU)
Learn how to either boot a custom kernel or use the module system
Get to work!
You can try looking into contributing to minix (http://www.minix3.org/)
There are a loads of things that are needed to be done .Have a look at (http://wiki.minix3.org/Wishlist).
I need some directions to start learning about programming my own operating system kernel.
Just for educational purpouses.
How can I write my own Kernel?
I would first ask: why did you pick "writing a kernel?" Any answer other than "the idea of implementing my own task structures in memory to be swapped by a scheduler that I write and using memory that is managed by code that I wrote and is protected by abstractions of machine-level atomic instructions and is given I/O access through abstractions that sit atop actual hardware interfaces appeals to me" is probably a bad answer that indicates you haven't done any research whatsoever and are wasting your time.
If you answered similarly to the above, then you have a good starting point and you know what you need to research (that is, you are able to pinpoint to some degree what information you do not know but need to find out).
Either way, I don't think this question is worth asking. In one case, you have done no research of your own to discover if you can actually do this, and in the other case you asked an overly-broad question.
It isn't that hard, but you need to learn about proper resource management and low-level device I/O. If you're targeting a commodity x86 box, then you'll need to learn about how the BIOS works and how the disk is structured. For example, the BIOS will read the first block of the disk into memory at some fixed address and then jump to that address. Since there probably won't be enough space in one block to store your kernel, you'll need to write a boot loader to read your kernel off the disk and load it.
Writing a minimal kernel that does some simple multitasking and performs I/O using just the BIOS isn't too difficult, just don't expect to be throwing up any windows and mousing around any time soon. You'll be busy trying to implement a simple file system and getting read() and write() to work.
Maybe you can start by looking into OS/161, which is a Harvard's simplified operating system for educational purposes. The OS runs on a simulator, so you don't need a new machine to run it. I used it for my operating system course, and it really did help a lot.
Also I think you may really want to consider taking an operating system course if you haven't done so.
Is it possible to have a Unix OS for 80286 machine (or any machine without paged memory mechanism but with segmented memory)?
80286 is a CPU without TLB, Page tables; only with segmented virtual memory and segmented protection of memory.
Is it possible to have a Linux on such machine?
UPD: the processor is very old, so I only ask about historic versions, not the ultra modern linux 2.6.42.11 or Solaris 13 or FreeBSD 10 or ...
The Linux/Microcontroller project (µClinux) is a port of Linux to systems without a Memory Management Unit (MMU).
There's the older ELKS project too.
However, due to the lack of MMU, many standard UNIX features (like fork and mmap) are not supported.
Today's Linux will only compile for a 486 or higher. So it's unlikely. I do remember 386s being somewhat supported in the 2.4.x era, but I don't remember anything about 286s.
User Zack says that Xenix (based on original UNIX) was capable of running on 80286:
There certainly were Unixes that ran on the 80286 -- Xenix comes to mind -- but I don't know if there's anything that implements what you would call a modern programming environment.
I'd checked, the Xenix FAQ http://www.uni-giessen.de/faq/archiv/sco-xenix/msg00000.html says
QA1 ... The PC/AT offered hardware memory protection, and SCO Xenix/286 took advantage of it.
So it was a PC/AT (80286) unix, which did used a memory protection using segmented memory (unlike modern unixes which use page based memory protection).
According to http://www.deinmeister.de/x86modes.htm 80286 have memory protection only in terms of segments, not a pages (pages was added in 80386).
Not sure how interested you are in the programming of it (if at all), but I was playing around with OpenCourseWare class from MIT awhile ago and they had a version of Minix they ported to x86 (not sure if it was just for 386+ or not and can't seem to find the link anymore). Anyway, if you're interested you can check it out here: MIT OpenCourseWare Operating System Engineering
I doubt so. From the very beginning, Linux was designed for the 386, using 386-specific features. MINIX, on the other hand, predates the 386 (and 286), so there should be a 286-compatible version out there.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
How do I test IO performance in Linux?
IO and filesystem benchmark is a complex topic. No single benchmarking tool is good in all situations. Here is a small overview about different benchmarking tools:
Block Storage:
IOMeter - Highly customizable and allows to coordinate multiple clients. Needs a Windows PC for the coordination application. Developed by Intel. On Linux, take maximum rates of older (at least 2006.07.27 and earlier) with a pinch of salt because the submission method was not optimal.
File System (synthetic):
FFSB - Flexible Filesystem Benchmark. Very neat benchmarking for Linux. Good customization of workload. NFS benchmarking (net-ffsb) a bit unsound.
Filebench - Extremely powerful, but originally developed for Solaris. Linux support isn't good.
sysbench - Mainly a DB benchmarking tool, but also basic filesystem benchmarking tool.
bonnie - Seems to be obsolete.
bonnie++ - C++ port of bonnie. Easy, but seems not to be very customizable.
File System (workload):
Postmark - Simulates the IO behavior of a mail server. Too small to stress good IO systems.
Stony Brook University and IBM Watson Labs have published a highly recommended journal paper in the "Transaction of Storage" about file system benchmarking, in which they present different benchmarks and their strong and weak points: A nine year study of file system and storage benchmarking. The article clearly points out that the results of most benchmarks at least questionable.
A note: Is the question programming related? Maybe not, but maybe it is. I spend a lot of time benchmarking the IO performance of the systems I develop. At least for me, questions about how to benchmarking these things is highly programming related. Please: Do not close all questions that are not development/programming related from your point of view. The point of view of other developers might be different.
tool: fio
link: http://freshmeat.net/projects/fio/
test physical disk IO:
./fio examples/disk-zone-profile
set parameter:
sequential r/w: rw=read or rw=write
random r/w: rw=randread or rw=randwrite
if you need a quick way without hassle of installing anything . This is the method I use for write speed test:
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
And the output is something like this
root#rackserver:/# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 4.86922 s, 221 MB/s
Also :
delete the test file after this to recover the extra space used
Some explanation :
bs = block size
count = the no of blocks to be written
Adjust these parameters to change the size of the file written as per your server specs and the amount of time you want to spend writing.
the read speed as suggested already by gtsouk, can be checked by using /dev/null as output.
dd if=/dev/sda of=/dev/null
Let this run for a few minutes and stop it with ctrl+C. It will print the read transfer speed of your drive/controller. This is the maximum read speed you can get out of your drive.
sysbench
See http://www.howtoforge.com/how-to-benchmark-your-system-cpu-file-io-mysql-with-sysbench
Example
sysbench --test=fileio --file-total-size=150G prepare
sysbench --test=fileio --file-total-size=150G --file-test-mode=rndrw --init-rng=on --max-time=300 --max-requests=0 run
It can also test cpu, memory, threads, and database server performance,
It's awesome.
Or testing software written in java: http://www.dacapobench.org/
you need to specify what you're testing for, otherwise benchmarks will only mislead. There are different aspects of IO performance that you need to chose to optimize for, and different parameters to play with.
Your system parameters:
storage device: HDD, SSD (which?), Raid (which?)
filesystem, block size, journal mode
file cache, dirty thresholds, amount of memory
IO scheduler, its tunables
number of CPUs
kernel version
Your test parameters:
read or write performance?
sequential or random?
1 thread or multiple?
size of requests
optimize for throughput or request delay?
There is an excellent program to test block storage IO on Unix called IORATE. You can get a copy at iorate.org.
It can generate complex mixed IO, including re-use (hits) and hot zones for tiered storage testing.
Take a look at IOzone:
http://www.iozone.org/
If you would like to read a whitepaper illustrating real-world usage on an HPC cluster, please see this pdf, page 36:
http://i.dell.com/sites/content/business/solutions/hpcc/en/Documents/Dell-NSS-NFS-Storage-solution-final.pdf