Can't I just write and compile the programming to operate the robot and have the kernel load and run it? If so, what should I call my robot's custom 'os' so that the kernal can find and load it?

what are the potential banana skins?

No, from what I gather, Frank Buss's code is a kernel object (.ko) which means you need a Linux kernel
for it to work.
As regards "writing and compiling the programming" to operate the robot, the same applies, you need a kernel.
So unless you want to write your own "mini-OS" (very doable) to monitor and control your robot via
the GPIO, you have to use a Linux kernel.
See here: http://www.raspberrypi.org/phpBB3/viewt ... =34&t=5847

I guess I do really want to write my own 'mini os' - what should I call it so that the kernel loads it?

I suspect you misunderstood.
If you write your own mini-OS, you would be writing the kernel yourself, in fact depending on the
size/complexity of your mini-OS, the kernel would be the only thing that would execute.
By kernel, I mean it's the main (and possibly the only) thing that is running.

Keep in mind the boot sequence of the Pi, the GPU starts up, does some
initialization, reads kernel.img (your kernel) from the SD card then executes it.

pygmy_giant wrote:
Is there any reason I can't write it in C++ and compile it with GCC ?

You will need to compile your "kernel" as a "flat" binary and not an ELF binary (to run under Linux)
or an ARMPE which would be to run under WinCE.
Also you can't make use of any libs or resources built into Linux unless you code them yourself.
This is not necessarily a bad thing depending on what you want/hope to achieve.
If all you want to do is monitor some sensors and drive a couple of motors (via suitable H/W)
then coding it all yourself is achievable and has advantages over Linux in that it would be realtime
where as the Linux kernel used with Debian or Arch are not.
If on the other hand you need ethernet and a TCP/IP stack plus fancy graphics and USB support,
then it would be madness to re-write all that and you would be better off finding a realtime Linux
kernel that would run on the ARM/Pi.

Given that I am committed to using Frank's kernel and his I2C driver kernel objects, but need nothing else, how can I get his kernel to then execute my own robot control binary?

Is there a filename that I can give it that garuntees the kernel will run it?

OK, if I understand correctly, Frank has made a kernel or a kernel module (.ko) that is loaded
then you have to access it using a binary.
No problem, depending which distro you are using, put a script in /etc/rc.local (or equiv.) which will call your
binary.
Below is an example of a /etc/rc.local
(yours will differ, but the principal remains):

#!bin/sh
# /etc/rc.d/rc.local: Local system initialization script.
#
# Put any local startup commands in here. Also, if you have
# anything that needs to be run at shutdown time you can
# make an /etc/rc.d/rc.local_shutdown script and put those
# commands in there.
wpa_supplicant -Dwext -iwlan0 -c /etc/wpa_supplicant.conf > /dev/null 2>&1 &
/etc/rc.d/rc.FireWall start &
YourBinaryName

The ampersands at the end of the lines will put each one in the background and proceed to the next.
In the example above, wifi is set up (using wpa) then the firewall is started then lastly your binary
is called.
This is just an example and in practice you can start just about anything this way.
I recommend that you call your binary last as this way any other apps/processes/daemons that might
be required are loaded/executed/started first.
You may even want to put a small delay before it calls your binary by using:

I don't want bloat - I want to create a real-time control system for my robot.

I only ever want one user space program to run on boot and all I want to do is access the GPIO pins via Frank's I2C driver kernel objects.

I don't need to play Quake III arena.

I was hoping I could just have: firmware -> kernel -> init

Is that possible?

If not, what is the minimum I could get away with and how would I go about amputating extraneous appendages?

Many ways to trim the "fat" on any distro but I'm not an expert on that.
Just keep two things in mind:

1) Just because something is in the distro, it does not mean it running and getting in the way.

2) There will be plenty of daemons running in the background and not all of these are required
in your application, but some are crucial to the working of Linux so you can't just "kill" them all.
The ones that you can "kill" are things like web servers, ssh (if you not using it) and if you are not
using a GUI, don't start X at all.

To see all the running processes, go to the command line and type either:
ps -aux
or
ps -ef

It will give you a ID for each of the processes, and if you want to "kill" one of them, type:
kill -9 xxxxxxx (where xxxxxxx is the ID of the process you want to stop), use at your own risk.

Last edited by Dave_G_2 on Sun May 20, 2012 10:27 pm, edited 1 time in total.

I've been told that I can use chrt -r -p 99 [pid] to set a process's priority ( http://www.cyberciti.biz/faq/h.....y-process/ ) and that I could also tell a program to lock all it's memory in RAM and not allow it to be swapped out..?

All good advice I'm sure ...

... cant help being drawn to the idea of unleashing a hatchet on the os to pare it to the bone though ....

Last edited by pygmy_giant on Sun May 20, 2012 10:33 pm, edited 1 time in total.

pygmy_giant wrote:Thanks again - you seem to have answered alot of my question ...

I think I can also monkey about with 'latencies' ?

You could, but if the kernel you intend to use is not truly realtime, then it's only a compromise
and you will get variances on timing which depending on how quickly you need to react to data
from your robot could be a problem.
There are realtime Linux kernels available but I don't know if they have been ported to ARM,
I would guess that they have.

pygmy_giant wrote:I have found many ARM RTOS's mentioned on the web but none Pi compatible - I have been told that it would be easiest to adapt one built for the ARM11, but I do not have the expertese.

It certainly does not sound like fun at all porting a whole OS.

pygmy_giant wrote:
I can see value in the de-bloat approach - wonder which distro would be best to start with...

If you don't need a GUI, go with Arch as it does not boot into X, then start chopping away at
all the un-needed stuff.

pygmy_giant wrote:
either way I think there is a need for a minimal real-time (ish) distro...

Couldn't agree more and that is why I want to code my own very simple OS specially for use
with the GPIO.
It will take a while as whilst I know X86 assembler pretty well, I'm learning ARM assembler as I go
and info on the nitty-gritty of the Pi is hard to come by as Broadcom is not exactly documentation friendly.

I looked at assembly language when I had a bbc micro back in the day and got scared.

Arm architecture seems to suggest an assembly language that is lower level than x86 (!)

Are there modern macro-assemblers that resemble higher level languages that someone like me who is used to C++ / php might find intelligible?

Dave_G_2 has given you some good advice.
To your ?, some coders from DexOS have been working on a macro basic called MBasic
Its lets you code in asm for x86 (ARM is being add) in a basic like language just by adding the right include file.
Here is a linux example (x86)

Very nice concept your Mbasic.
It certainly is easy and friendly enough even for beginners to start programming and of course
there is nothing stopping one creating a new "language" based on macros.
Would certainly get students thinking and having fun whilst making up new commands and they
are learning very important computer programming skills at the same time.

That code sample has made me nostalgic as it does resemble BBC basic - ahh - the smell of an overheating powerpack, loading from tape, flashing colors that could induce epilepsy, economic programming ... simpler times ... how did it all get so ... complex?

pygmy_giant wrote:That code sample has made me nostalgic as it does resemble BBC basic - ahh - the smell of an overheating powerpack, loading from tape, flashing colors that could induce epilepsy, economic programming ... simpler times ... how did it all get so ... complex?

If DexOS can let us have FBasic_L.inc as a starting point then why not make a BBC or ZX80/1 type BASIC?
I know similar things exist but it would make for a fun and educational project.
Since it uses macros it would be very easy to add/change commands and there
could even be things like IN and OUT for use with the GPIO.
For example:

I am guessing the Mbasic Macro Assembler in essance performs find and replace operations on text to expand higher level code into pure assembly language according to the rules given to it. I anticipate it uses Grep / Regular Expressions and conditional substitutions.

The really clever part appears to me to be the actual substitution rules - that would require a knowledge of assembly language to begin with.

I wonder if this would be achievable to a certain degree via an advanced text editor...?

The most important and exciting part for someone like me who is used to higher level programming would be the ability to use conditional statements such as if/then/else as most other conditional statements can be built out of those.

pygmy_giant wrote:I am guessing the Mbasic Macro Assembler in essance performs find and replace operations on text to expand higher level code into pure assembly language according to the rules given to it. I anticipate it uses Grep / Regular Expressions and conditional substitutions.

Nope. It uses FASM's macro system, which, if it's not actually Turing-complete, is extremely close to being so. That said, it doesn't seem to[1] abuse it *too* much (only using the if/else constructs as far as I can tell), and the transforms it carries out could probably be reduced to repetitive text replacements.

Interesting - I wonder if Mbasic could also be acheived via substitution - I bet most assembly language users could be forced to admitting useing find/replace on a text editor at some point in their lives.... It must surely be a very laborious process otherwise

Most macro expanders use a macro name followed by a list of parameters. The only bits of MBasic that we have seen conform to this format. It is possible to use regular expressions, but you tend to lose control of the error messages because you have no way of knowing whether a given input line should have been recognised by a given regular expression. That means that invalid input lines are passed through to the assembler and are only then rejected as syntax errors. For example in __----__----__'s example, a syntax error would tend to look like this: