Bare Metal Robots

[pygmy_giant]

Hi

I'm counting the days until my pi arives (10) and want to use it in a robot.

I therefore only need input via the SD card on boot and output to the GPIO pins.

So why bother with a full operating system?

I understand the Pi loads the firmware on power-up which then loads the kernel (or any binary called kernel.img) but what does the kernel then load?

I am interested in using Frank Buss's kernel incorporating I2C drivers (see: http://www.raspberrypi.org/phpBB3/viewt ... driver+I2C ) but do I really nead a full os?

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?

[Dave_G_2]

Hi

I'm counting the days until my pi arives (10) and want to use it in a robot.

I therefore only need input via the SD card on boot and output to the GPIO pins.

So why bother with a full operating system?

I understand the Pi loads the firmware on power-up which then loads the kernel (or any binary called kernel.img) but what does the kernel then load?

The kernel then (amongst other things) loads the kernel objects (drivers).

I am interested in using Frank Buss's kernel incorporating I2C drivers (see: http://www.raspberrypi.org/phpBB3/viewt ... driver+I2C ) but do I really nead a full os?

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

[pygmy_giant]

Thanks for explaining about the kernel objects.

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

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

[Dave_G_2]

Thanks for explaining about the kernel objects.

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.

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

Personally I prefer FasmARM, but it's up to you if you want to use GCC.
http://arm.flatassembler.net/

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.

[pygmy_giant]

Interesting.

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?

Should I call it 'init' ?

http://en.wikipedia.org/wiki/Linux_startup_process

Is this more complex than I appreciate?

https://wiki.archlinux.org/index.php/Init_and_inittab

[Dave_G_2]

Interesting.

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):

Code: Select all

#!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:

Code: Select all

sleep 2
YourBinaryName

[pygmy_giant]

Thanks Dave_G_2 - again, interesting. I need to study that - I am grateful for your input. I need to study Linux - I am a Linux 'noob' - at the risk of sounding too demanding:

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?

Please feel free to ignore me if I'm asking the wrong questions or if you've already answered me...

[Dave_G_2]

Thanks Dave_G_2 - again, interesting.

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.

[pygmy_giant]

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

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

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 ....

[Dave_G_2]

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]

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.

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

...alternatively there is 'Linux From Scratch' : http://www.linuxfromscratch.org/

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

Wish I understood more about Linux - expect that is enevitable - any pointers to simpleton speak expalanations of the process it employs would be much appreciated...

[pygmy_giant]

Is there any tool / method that could track the modules / objects called in the process of executing my code to enable me to decide which daemons to slay?

[Dave_G_2]

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.

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.

...alternatively there is 'Linux From Scratch' : http://www.linuxfromscratch.org/

Looks like a lot of work.

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.

[pygmy_giant]

God bless you sir - I doubt I can give you any advice but I would be happy to help with testing when my pi arrives

RE: the hatchet approach, I am looking at Puppi as / when / if it becomes available as it runs in RAM and could be faster than an OS that constantly accesses the SD card...?

[Dave_G_2]

@pygmy_giant

No problem, will need people to test.
I am also glad that DexOS has now joined the RASPI forum as he is very, very competent in assembler
including ARM.

EDIT:

Puppy will be a very welcome addition to the distro options for the RASPI and although it will be
"lean and mean", it's still not a realtime OS.

[pygmy_giant]

dexos: http://www.dex-os.com/ - likey looky

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?

[DexOS]

dexos: http://www.dex-os.com/ - likey looky

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)

Code: Select all

include 'FBasic_L.inc'
CLS
COLOR  11
LOCATE 2,1
PRINT "This app is written in Macro Basic, for Linux "
COLOR  12
LOCATE 2,2
PRINT "With the ease of Basic and the power of ASM "
COLOR  15
LOCATE 2,3
PRINT "It user's the basic commands:"
PRINT " "
PRINT "    CLS"
PRINT "    SCREEN"
PRINT "    COLOR"
PRINT "    LOCATE"
PRINT "    PRINT"
PRINT "    GOSUB"
PRINT "    RETURN"
PRINT "    SLEEP"
PRINT "    END"
PRINT " "
GOSUB TestSub
SLEEP
END

TestSub:
PRINT "  Press any key to quit."
RETURN                                    

This is it running in linux


But it is written in full ASM, with all the power and size you get with asm.

[Dave_G_2]

@DexOS

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.

B.T.W. where can I find FBasic_L.inc ?

[jack3d]

Great idea, look forward to seeing some pics?

[pygmy_giant]

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?

[__----__----__]

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:

Code: Select all

OUT 4,1  ; make GPIO #4 high
OUT 6,0  ; make GPIO #6 low
A = IN(2) ; read GPIO #2
PRINT A : print the result

[pygmy_giant]

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.

[tufty]

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.

[1] Looking at the x86 version, here

Simon

[pygmy_giant]

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

[rurwin]

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:

Code: Select all

A = INN(2)
^ Invalid operation code "A"
   ^ Unexpected character "="

Link: Unresolved label "INN"

Which error messages have nothing to do with what the error actually is.

There are more advanced ways of parsing and implementing macros but, so far as I know, macro assemblers do not use them either.

I would be interested in seeing how MBasic handles arithmetic expressions of moderate complexity, say y = mx+c.