I am looking for some information on programming ARM devices, in a particular non-particular way [1]. Assume that I am writing code for an ARM processor that is used a machine similar to a Apple II/Atari "**" XL/Commodore 64/DOS-PC, or even something that runs a multitasking OS like VMS or SUNOs. Assume further that any peripherals/OS specific stuff has already been abstracted into subroutines.Examples of this type of programing might be: a text/curses based game like rogue or moria; a curses based word processor ( or rather something based on a curses like library ) ; or a modem/terminal program.
I'm looking for two things. Materials to help learn ARM programming, though the ARM System Developers Guide may be enough, other resources would be helpful I'm looking in particular for something which explains the software ( and relative hardware ie registers ) differences of various generations of processor.
The other thing I'm looking for is a development environment which inculdes, emulation, a decent macro assembler, and a debugger. Along with any thing else that will help me see what is going on inside my programs.
[1] OK. Sorry I just couldn't resist that particular pun.
You have the choice of using ARM Cortex M or A series. If you are going to develop high end applications such as those which run on smartphones / tablets, then learning about ARM A is your choice. If you are going for an emphasis with hardware/low level stuff such as controllers then you should go for ARM Cortex-M. If you are into real time applications (which I doubt is your case, them use the R series).
Most of these new ARM generations are based on ARMv7 architecture and ISA, so reading the manuals on that could get you started. Most recently, a new ARMv8 architecture and ISA have been announced, it supports 64 bit processing.
Download the reference and technical manuals from ARM site to learn about the HW/peripherals.
I would go with auslen's suggestion of buying a board, you could go with TI's Stellaris Launch pad which has an ARM-M4F processor (supports floating point and SIMD), it sells for 12.99$
http://www.ti.com/ww/en/launchpad/stellaris_head.html?DCMP=stellaris-launchpad&HQS=stellaris-launchpad-b
or you could go with ST's discovery board (based on the same processor as above), but has audio, accelerometer and usb on board. it sells for 14.99$ http://www.st.com/internet/evalboard/product/252419.jsp
or the STM F3 board (10.99$)
http://www.st.com/internet/evalboard/product/254044.jsp
In any case, you need to check the examples which come with the board, without which you could go nowhere easily. The board comes with its own drivers, all is abstracted in a way, so you could get started from there!
As for OS, if your interest is an RTOS, ARM provides the CMSIS RTOS for it's M series processors
http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php
This book offers an introduction to the generations of ARM processors. Then focuses on cortex M3. It covers its ISA with lots of assembly code. It also addresses the built-in peripherals and how to start-up with C.
http://www.amazon.ca/Definitive-Guide-ARM-Cortex-M3/dp/185617963X/ref=sr_1_1?ie=UTF8&qid=1352506616&sr=8-1
good luck
infocenter.arm.com and look at the various ARM ARMs (architectural reference manuals) and TRM's (technical reference manuals) for the various architectures and cores. these manuals are better than most other companies documentation. except for the new 64 bit stuff, the difference from one architecture to the next is somewhat subtle as far as the instruction set goes. the major differences have to do with the peripherals, the mmu is a slow changing thing, the interrupt manager has taken big steps and the fpu has been replaced at least once if not twice wholesale (if you even have an fpu which, having one is the exception not the rule it consumes a huge real estate for such little return).
I am confused with your question. I think it is important to draw the line between learning the architecture/instruction set and learning the operating system calls, these are two separate things. Operating system stuff you rarely need to look beyond the source code (C/C++), and the limited asm is for hand tuned C libraries or boostrap code, and interrupt wrappers. Likewise the architecture, registers, instructions, etc vs the peripherals (the cores from arm generally have very very few peripherals, the bulk are in the vendor specific stuff) which I would separate as a separate learning curve, has little to do with asm and the instruction set so no different than learning a peripheral on any other platform, just some addresses you read and write.
If you are looking for non-operating system bare metal the stm32f0 discovery is $10, I highly recommend it. Looks like ti has a stellaris launchpad for just a little more (waiting for mine to arrive so I cant talk much about them, and shipping is free from ti so the cost is basically the same as the stm32 boards) the stm32f4 discovery is about $20 and I would barely call a microcontroller with all the stuff the cortex-m4 has.
Moving up to linux capable or designed for linux systems there is the raspberry pi, beaglebone and open-rd and on up (pandaboard). Again though you are just writing just another linux C/C++ program so there isnt much excitement there (related to a specific platform, the entertainment is the same for all platforms) and very little arm knowledge required if any. It is very easy to use any of these platforms for bare metal programming giving you race car like performance compared to the ARM based microcontrollers.
I have a thumb simulator which you are probably not interested in. gdb has the armulator which was the cornerstone of the company back in the day. skyeye or something like that has an arm instruction set simulator as does qemu, none of them will give you great visibility other than what gdb can provide. opencores has the amber project an armv2 clone, which you can see the close relationship to the armv4 and newer that you will not find rtl for without a box full of cash. with my arm and chip experience (No I do not work for arm) I do find the amber project worth looking at, but many folks wont know what to do with it and really are not interested in that level of visibility. (it is instruction compatible, a good design, but dont think you are looking at an arm design, no secrets there). you can learn the basic arm architecture from it and then move on to hardware for example...
With the microcontrollers being cortex-m based, you might find the older microcontrollers a better stepping stone to the upper end arm cores. ARM7tdmi based stuff like the sam7s and others from nxp, st, atmel, etc which you can still find at sparkfun and microcontroller pros and other places for arduino like prices.
Related
Good day everyone,
Please be kind an encouraging, as I am beginner in Embedded Programming, even if I have strong knowledge in C/C++.
Michael Barr, in his book, Programming Embedded Systems, writes, page 17, that "this function is specific to Arcom's Target188EB board.
I have Keil uVision 5 installed on my machine with Windows.
And I went in package installer to see if I can find , at least, the installer for simulating programs of the book. But I did not find the installer.
Why?
In particular, there is a special piece of code :
asm{
mov dx, P2LTCH
in a1, dx
....
}
which is special for this board.
So, I guess I should have the hardware, or at least the possibility ton download the package that fits to this board to be able to make the simulation.
Do you know why I don't find Arcom's Target188EB board in the package installer list ?
Thank you for your help
The board you refer to is an obsolete antique with an equally obsolete Intel 80188 processor on board. Keil do not produce a tool chain to target that.
Assembler code is architecture specific - that code is meaningless on anything that is not an 16 bit 8086 based processor.
In-line assembler syntax is compiler specific - you'd need the tool chain used for the original code to be sure it would compile in any case. Borland C++ 3.1 apparently (also an antique).
The code you are referring to uses the GPIO I/O port referred to by P2LTCH to control an LED. On other more modern and readily available boards, the method of accessing GPIO to flash an LED will differ. That is not fundamental perhaps to what the book is trying to teach you, but a more up-to-date book might be in order, or you need to know enough to be able to apply the content of the book to other systems - that is you need to be able to generalise the information using other resources perhaps.
Any board directly supported by the Keil tools generally has a "Blinky" app - the embedded world's answer to "Hello, World!", which does exactly what this exercise in Barr's book is exemplifying. Its purpose is to flash an LED to verify that you can build, load and execute code that can access the hardware.
I suggest you obtain a modern board directly supported by your toolchain, and supported by a broad community. Any number of ARM based microcontroller boards are available for very low cost, and much higher performance that the Arcom board and a broader peripheral set than
I'm not crazy, just reinventing the wheel :D
I wrote boot-loaders, mouse & keyboard mini-drivers, mini OS and so on.
I'm always trying to avoid DOS interrupts, using BIOS ones only, trying to go forward a unity mini OS, but suddenly I decided to write my own BIOS :)
The Legend said :
I was high-level programmer, then low-level one. One day I'll be machine-language programmer!
Is a BIOS written in assembly? How can I flash it? What's the mechanism? Can I start editing my current BIOS?
A BIOS can be written in assembly but doesn't have to be, some parts need to be to get the parameters for the system call since they don't match the compilers calling convention.
How do you flash it? Varies from motherboard to motherboard, I would start with an open source virtual machine and write a bios for that. Or create a virtual machine where you have written the bios. The mechanism varies from vendor to vendor, generally you boot dos (dos is not dead, it is very much alive in the PC world, esp motherboard development and embedded systems). I wouldn't mess around with a real motherboard, if you don't already know the answers to all of these questions you are going to brick a number of motherboards if you take that path.
You can try to take a bios upgrade for your mother board and reverse engineer it (although there is probably a click through agreement that says that you wont). If you figure it out you can both load it and hack at at. I wouldn't go there, you will brick your system before you figure it out.
Is writing a bios really what you are after? Fairly old school, would be like writing 6502 code for fun. There are many low level problems that are more useful and as interesting.
If you can write asm the writing machine code is not that difficult at all, you could just go do that for fun. x86 is dreadful, you should spend some time learning other systems and their asm and machine code (and writing operating systems for them). ARM dominates the world and doesn't rely on a bios. I have been told that to get a video card up on a non-x86 system you still have to fiddle something in x86 on the x86 bios, could figure out how to bring up a mainstream video card without the need to run the x86 bios. watch an emulator run the bios and see what it does, figure it out replace that power on init without the bios doing it...Writing an instruction set simulator or disassembler is the next step beyond writing machine code, I wouldn't waste even a second of time on x86 though, I can suggest a list of alternatives (or you could just play with the simulators I have written or collected).
If an x86 bios is the way you want to go, your best path is to write, replace, or hack on a bios for a virtual machine being qemu, virtualbox, or other. Replacing that bios with yours would likely be replacing a file in some directory or using a command line option to specify an alternate bios. Once you are well experienced in that then if there are still motherboards with legacy bioses on them perhaps you can hack your way into programming one (need to buy several of each type of motherboard as you WILL brick some). With so many embedded systems out there that can be had for $20 to $200 with the same level of experience gained, it doesn't make sense to hack on a pc motherboard without decent schematics and documentation. You could dig up an original PC with the schematic and bios listing being documented, and the bios being socketed so if yours doesn't boot (and doesn't destroy the motherboard) it isn't a brick you can reprogram or replace the bios chip. Probably want to use a microcontroller to stand in as a fake bios, as finding the right hardware to reprogram more bios chips is perhaps harder to find that working original PC's...There is an amiga community that is likely a lot more fun and would be happy to have you improving/tweaking their bios, say putting modern hardware behind the legacy system calls.
BIOS can be written in any of your favorite language, although lower level languages give you more control. Assembly and machine code are almost the same, the difference being microcode interface and what you type, eg. for machine code you'd only type 2 characters, and assembly give you alphanumerics. My hunt for custom BIOS began when I needed computer to boot up every few hours and haven't found any BIOS that does that.
To flash BIOS, follow manufacturer guidelines. BIOS has now been replaced with UEFI (for added security).
Checkout: https://www.pcworld.com/article/187437/how-to-update-your-bios.html
x86 and amd64 instruction reference: https://www.felixcloutier.com/x86/
x86 instructions with extensions: https://en.wikipedia.org/wiki/X86_instruction_listings
i386 instruction ref: https://css.csail.mit.edu/6.858/2014/readings/i386.pdf
x86 Assembly Guide: https://www.cs.virginia.edu/~evans/cs216/guides/x86.html
Intel Instruction Set Ref: https://software.intel.com/sites/default/files/managed/a4/60/325383-sdm-vol-2abcd.pdf
If you want to write a BIOS for an IBM PC Compatible computer (which is what the majority of desktop PCs are today, albeit with more extensions to the CPU instruction set, and some different BUS interfaces), then I suggest you look through the IBM PC, IBM PC XT, and IBM PC AT Technical Reference Manuals. Particularly the IBM PC AT manual, as that is what the de-facto standard is.
These manuals have a program listing of the complete BIOS that IBM used on their computers, and they are in assembly language. You might have to hunt through those manuals a little bit (especially the IBM PC AT one) to find them, as some aren't directly listed in the table of contents, but they are there. Hopefully those BIOSs can get you started.
There are ways to flash the bios other than to have the pc running perhaps. But it requires some hardware. Shouldn't be very expensive though.
You could try something like this kind of tecnique:
http://hackaday.com/2010/11/18/build-your-own-soic-progamming-clip/
This talk i saw today:
https://conference.hitb.org/hitbsecconf2015ams/sessions/how-many-million-bioses-would-you-like-to-infect/
It explained it in more detail, though you might not be looking for infection, some tecniques for getting to the bios are covered, where the programming clip is one of them.
FWIW Modbin is a DOS program that as the name suggests MODifies BIN images especially for the purpose of both simple qnd fairly extreme changes to existing BIOS code.
If you can obtain an old mobo (many are thrown away still working) I would encourage you to play around with the BIOS. It's informative and fun, if one is so inclined and you seem to be :) There was a time that I downloaded BIOS images from mobos that had the same or similar enough chipsets though made by a different manufacturer...sometimes to considerable advantage including such simple ones as continuing to get BIOS updates after the original mobo manufacturer dropped the ball or went belly up, but also features and performance oriented options and alterations.
This led to "HOT Flashing" which is pulling up a socketed BIOS chip so that the pins just barely made contact and once booted up, pulling that one and substituting a bad one (often one I had fuxored) while still running and flashing it employing the cached BIOS feature that kept the system active. Fun stuff for those of us of the geek persuasion and gave me the confidence to write device drivers for OS/2
I am reading a primer text on embedded C programming (it is: Barr & Massa, 2007). For companion hardware board to run examples, they recommend Arcom VIPER-Lite. But I do already have Beaglebone Black (BBB) board and I don't want to buy a new board.
The two boards have same architecture, namely, ARM but BBB uses TI AM3358BZCZ100 processor, clocked at 1GHz, whereas VIPER-Lite uses Intel's PXA255 processor, clocked at 200MHz. The BBB board has more memory and basically more of everything.
My question is, can I follow and execute embedded C code examples given in this book on my BBB board? Does embedded C code depend on processors or architecture or something else? I understand that very specific examples addressing particular peripherals/drivers may not be portable from one platform to next but is entire embedded code like this? I am hope I am making sense.
Intel X-Scale is not the same as Cortex-A8 - ARM architecture has been through a number of versions since then, and Intel implemented some proprietary features too. Moreover ARM licencees are free to implement proprietary peripheral sets and subsets of the core architecture.
In particular for board bring-up the PLL and SDRAM controller will be entirely different between different vendor's devices and even between different generations of device from the same vendor.
If you are running code on an already implemented OS (BeagleBone is delivered with Linux already installed), then you will not need to worry about board bring up and peripheral support; but you will also miss out in learning a great deal about embedded systems (other than perhaps embedded systems that run pre-installed or vendor supplied Linux distros, which is a small subset or all embedded systems).
Beyond board bring up the boards will have entirely different peripheral sets, different on-board devices, and differing I/O at different addresses and with different register sets - no code that directly accesses the I/O is will work. Code accessing devices through a standard Linus device driver interface may well work because an abstraction to a common interface is provided by the OS and board vendor or third party device drivers.
If you are not running the code on Linux - or are implementing low-level device drivers, then the programming environment in terms of memory map, MMU, PLL, I/O control, peripherals, and even instruction set will be different and any code will require adaptation, and you will need to get familiar with the corresponding data sheets or reference manuals and also the ARM technical reference.
So the answer is that it depends largely on where you are starting from; bare-metal or Linux.
There are resources related to "bare-metal" development on BeagleBone Black in particular TI's own bare-metal StarterWare library.
The concept you learn from most good text books can be applied any microprocessor or micro controller at a very high level. But if you want learn embedded system programming using Beagle Bone Black I suggest the following youtube links from Prof Derek Molloy. Prof Molloy does a fantastic job of teaching embedded System programming using BBB. Here are few links for you to get started.
The Beaglebone - Unboxing, Introduction Tutorial and First Example
Beaglebone: C/C++ Programming Introduction for ARM Embedded Linux Development using Eclipse CDT
Beaglebone: GPIO Programming on ARM Embedded Linux
The one problem you might want to be aware is that the video were based on Angstrom Distribution. The current BBB is shipped with Debian Distribution.
Also if you want to learn bare-metal embedded system program you might want check out
Embedded Systems - Shape The World
You might also want to take look at the following link for more material.
Beginning with programming microcontrollers
The xscale although ARM instruction set derived is not ARM in the sense that you want to use it. For some reason the native mode is big endian and normal ARM native mode is little endian. But more important the core processor is not insignificant, but not the bulk if the porting effort, most of not all of the peripherals are expected to differ between those two chips, most of the code would need a re-write unless it is a purely portable C program that runs on any say linux, then arm, xscale, x86 are completely irrelevant to the discussion. I suspect you are not in that situation. Even compiled as a generic command line linux app would still have problems in this situation with the endianness.
Basically you are saying I have two fords and I want to take the wheels off of one and put them on the other, without understanding that one is a ford festiva and the other is lets say an F350 pickup. Just because they have the same looking tiny ford badge on them, doesnt mean that the entirety of their components are identical.
If you are desperate to re-use these binaries, you are better off finding or making a simulator for the prior platform and then you can run that on anything.
I do apologize if this is a duplicate even though I did search around here for a similar question, I only found one.
So my programming team in my Engineering class currently use a 32-bit 72MHz ARM Cortex-M3 microprocessor. We're all seniors in high school, and we're struggling to use the libraries and whatnot, mostly due to poor docs from the manufacturer of the Bioloid Premium we're using. However we are about to purchase an 8-bit 16MHz AVR microcontroller because it has a wider range of support online and an easier-to-use library + more documentation. My question here is, would the decreased bit-count as well as the lower processor speed really matter to us? We're not going to be doing a lot of process-intensive programming, but more like a basic robotics class.
So, main differences between an 8-bit 16MHz AVR microprocessor and a 32-bit 72MHz ARM Cortex-M3 microprocessor?
Also, (if it holds any relevancy):
We're using a Bioloid Premium by Robotis w/ CM530 (ARM), about to switch to CM510 (AVR).
We'll be using Embedded C instead of Robotis' RoboPlus IDE as our instruction set.
I have googled around, found out what a bit-count was, and more about it's impact on processor speed, but not a lot of documents about it give a clear and concise answer and that's why I came here, because it's for clear and concise answers. (So please don't tell me to Google it when I've spent the past twenty minutes doing so.)
We're using a Bioloid Premium by Robotis w/ CM530 (ARM), about to
switch to CM510 (AVR). We'll be using Embedded C instead of Robotis'
RoboPlus IDE as our instruction set.
I looked around at the products you refer to, and your question seems to be missing the issues you should really be concerned with.
The Bioloid Premium kit looks pretty sweet, with all the parts put together and configured for you already. Much of robotics courses are usually concerned with designing the hardware. You are not going to be doing any of that. So your tasks really come down to programming the hardware you are given.
That said, there is a world of difference between the RoboPlus IDE, which seems similar to the Lego Mindstorms drag and drop interface, and writing code in C using AVR Studio!
I have used AVR Studio before, but there was a major change in versions recently. You might need to modify the example programs to work in the latest version, and you will probably need some help with that.
It looks like they supply you with enough example code to use the periperpherals, but I don't see right away how to write a main() function to do something like follow a plan. Perhaps, there are some examples online.
But to answer your question, you are probably not going to run into any limitations in terms of processor capacity. They switched to a cheaper and more powerful processor to write the newer version of their control software, but the old hardware will be great, too. Working in C, you will become familiar with how to actually use an MCU, and that knowledge will transfer to other chips. The AVR family is a great one to start with. It has lots of features and is pretty sensible in how it works, with lots of documentation and third-party support. Definitely download the datasheet from Atmel for the chip you are using, although it is a dense and difficult read. You will only need to read parts of it. Also, check out the AVR Freaks forums.
This sounds like a fantastic high school course. Have fun with it!
My question here is, would the decreased bit-count as well as the lower processor speed really matter to us? [...] So, main differences between an 8-bit 16MHz AVR microprocessor and a 32-bit 72MHz ARM Cortex-M3 microprocessor?
What a cool project! This is a great opportunity to learn a bit about how processors work and what bit-width and clock speed mean.
Clock speed is conceptually the easiest to understand. Microcontrollers like the AVR and ARM use a clock crystal that sets the speed the circuitry operates at. With a faster clock, the processor can execute more instructions in the same amount of time. The 72MHz clock is more than 4x the 16MHz one, so the ARM processor is going to be able to run 4x faster than the AVR. But what does "run faster" really mean? Processors execute instructions. At the basic level, these are instructions like "add two numbers" and "make the voltage on this pin high". The ARM processor is going to be a lot faster here, but consider what hardware it's going to be talking to: servos. Servo motors listen to a fairly low-speed PWM signal, so at that speed the difference between 72MHz and 16MHz isn't going to become that relevant.
But what about bit-width? This one is a bit more tricky. It doesn't really affect the speed at which your processor runs, but it affects the complexity of the instructions it executes. Let's say that you want to add two really big numbers together. Numbers like 100,000 and 200,000. When we add those together on paper, it's just one step. But an 8-bit processor like the AVR can only operate on numbers as large as 65,536. So in order to operate on numbers that large it'll need to break up the addition into several smaller steps. The 32-bit ARM, on the other hand, can work on numbers that large. So it does the addition in one step. I hope that makes sense.
Anyway, I've done a lot of work with servos on even slower processors than your 16MHz AVR. It'll most likely be just fine for what you want to do, and like you found it has a much more active hobbyist community. And if you're looking for quick examples of code, the Cornell 4760 page has some great projects that you could learn from.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I have to choose a thesis topic soon and I was considering implementing an operating system for an architecture that is not x86 (I'm leaning towards ARM or AVR). The reason I am avoiding x86 is because I would like to gain some experience with embedded platforms and I (possibly incorrectly) believe that the task may be easier when carried out on a smaller scale. Does anyone have any pointers to websites or resources where there are some examples of this. I have read through most if not all of the OSDev questions on stack overflow, and I am also aware of AvrFreaks and OSDev. Additionally if anyone has had experience in this area and wanted to offer some advice in regards to approach or platform it would be much appreciated.
Thanks
Developing an (RT)OS is not a trivial task. It is very educational though. My advice to you is to start hardware independent. PC is a good starting point as it comes with plenty of I/O possibilities and good debugging. If you create a kind-of-virtual machine application, you can create something with simple platform capabilities (console output, some buttons/indicators are a good start). Also, you can use files for instance, to output timing (schedules) If you start on 'bare metal' you'll have to start from scratch. Debugging on a LED (on/off/blinking) is very hard and time consuming. My second advice is to define your scope early: is it the scheduler, the communication mechanisms or the file systems you're interested at... ? Doing all can easily end up in a life long project.
Samek, Miro, Practical UML Statecharts in C/C++ contains some interesting sections on a microkernel. It's one of my favorite books.
Advanced PIC Microcontroller Projects in C: From USB to RTOS with the PIC 18F Series
seems to cover some of your interests; I haven't read it yet though. Operating Systems: Internals and Design Principles may also bring good insights. It covers all aspects from scheduler to network stack. Good luck!
Seems like you should get a copy of Jean Labrosse's book MicroC/OS.
It looks like he may have just updated it too.
http://micrium.com/page/press_room/news/id:40
http://micrium.com/page/home
This is a well documented book describing the inner workings of an RTOS written in C and ported to many embedded processors. You could also run it on a x86, and then cross compile to another processor.
Contiki might be a good thing to research. It's very small, runs on microcontrollers, and is open source. It has a heavy bias towards networking and communications, but perhaps you can skip those parts and focus on the kernel.
If you choose ARM, pick up a copy of the ARM System Developer's Guide (Sloss, Symes, Wright). Link to Amazon
Chapter 11 discusses the implementation of a simple embedded operating system, with great explanations and sample code.
ARM and AVR are chalk and cheese - you've scoped this very wide!
You could produce a very different and more sophisticated OS for ARM than AVR (unless you are talking about AVR32 perhaps - which is a completely different architecture?).
AVR would be far more constraining to the point that the task may be just to trivial for the scope of your thesis. Even specifying ARM does not narrow it down much; low-end ARM parts have small on-chip memories, no MMU and simple peripherals; higher end parts have an MMU, data/instruction caches, often a GPU, sometimes an FPU, hardware Java bytecode execution, and many other complex peripherals. The term 'ARM' covers ARM7, ARM9, ARM11, Cortex M3, Cortex M8, plus a number of architectures intended for use on ASICs and FPGAs - so you need to narrow it down a bit perhaps?
If you choose ARM, take a look at these resources. Especially the Insider's Guides from Hitex, and the "Building bare-metal ARM with GNU", they will help you get your board 'up' and form starting point for your OS.
Silly as it may sound, I was recently interested in the Arduino platform to learn some hacking tricks with the help of more experienced friends. There was also this thread for a guy interested in writing an OS for it (although not his primary intention).
I think the Arduino is very basic and straightforward as an educational tool for such endeavors. It may worth the try checking it out if it fits the bill.
The first thing I recommend is to narrow your thesis topic considerably. OSs are ubiquitous, well researched and developed. What novel idea do you hope to pursue?
That said, the AvrX is a very small microkernel that I've used professionally on AVR microcontrollers. It is written in assembly. One person started to port it to C, but hasn't finished the port. Either finalizing the port to C and/or making a C port to the AVR32 architecture would be valuable.
An OS shall not be tightly coupled to any processor so ARM or x86 doesn't matter.
It will be a bigger topic, if we start discussing if ARM is embedded and x86 is not. Anyway, there are many many places in which x86 processors are used for embedded software development.
I guess most of the kernel code will be just plain C lanugage. There are many free OS that are already available, like for example, embedded linux, Free version of Itron, minix, etc ... It will be a daunting task.
But on the other hand, what you can try is, port embedded linux to platforms in which it is not yet working. This will be really useful to the world.
An RTOS is almost never architecture specific. Refer to any RTOS architecture available on the net and you will notice that a CPU/Hardware abstraction layer abstracts out the CPU. The board specific portions (that deal with peripherals such as com ports, timers etc.) are abstracted by a board support package.
To begin with, get an understanding of how multi-threading works in a RTOS try implementing a simple context switch code for the CPU of your choice; this will involve code for creating a thread context, saving a context and restoring a saved context. This code will form the basis of your hardware abstraction layer. The initial development can easily be accomplished using a software simulator for the selected CPU.
I agree with the poster who suggested reading the book, uCOS-II by Jean Labrosse. Samples of context switch code, especially for x86, should be just a google search away!
http://www.amazon.com/Operating-Systems-Design-Implementation-3rd/dp/0131429388
Pretty solid stuff.