Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I and my Friends have been trying to custom build a mid-range mobile phone. We are thinking of porting linux to it and modify it as per our requirements.
Now, The problem is that we are unable to decide about which processor to use - weather to use ARM or any other and if ARM then which ARM architecture. It would be great if someone could also suggest which linux variant to port.
OUR AIM: We want to build a device in this category, please please follow the link:
Please Click here
Please give your valuable inputs, it will help a great deal to us youngsters.
Thanks and Regards,
Avi and Co
Are you seriously getting into the phone business or is there some other real goal you are after (learning how something works, wanting to create a phone user interface, etc)? Getting into the phone business means tens to hundreds of millions of dollars, per product, of development money. Armies of lawyers to figure out the dozens of companies you are going to have to pay patent royalties to (do you follow slashdot.org?), etc. With that budget you already have the money to buy each of the popular eval boards and try them out. Likewise the software staff to try each of the linux porting methods.
Not to completely discourage you though.
ARM makes processor cores, but not chips. Other companies take an ARM core, wrap it with something interesting and sell that chip as a product. There are many websites that show the deconstruction/disassembly of quite a few phones and other products. You need to research this, I would be surprised, but if there are phones that use commercially available processors, those are the chips you should look for. I suspect most are going to be custom made for that phone or phone vendor and you are likely not going to be able to even get a datasheet much less a way to buy them on a board (other than buying a phone of course).
ARM is a very good choice for phones, there are many good reasons why ARM is used in phones and most other handheld devices. Go to ARM's website and look at the cores availble. Compare that to what websites claim phones or other similar devices (ipad, kindle, nook) are using. Then search around for companies that have chips with those cores. You will probably just end up looking at the ti omap or the marvell chip in the openrd or plug computer (I dont know its name/model off hand, kirkwood or something like that). The nvidia tegra is the hot new chip for phones, I think they have an eval board.
If you have not already ported linux to ARM then I would actually suggest working on that against QEMU, and wait on purchasing any hardware. As already mentioned a little googling goes a long way. You can even create and test your phone user interface software without needing to purchase any hardware. By surfing around getting a feel for what lcd panels, etc are used by various vendors you can get a feel for what your software is going to be limited to or have to do. It wont cost you anything but time to figure out what you do and dont want or will or wont support without having to spend any money on hardware.
I would compile everything for a generic arm at first (armv4 for example) and worry about tuning for the particular core later, if at all. Sure, ultimately you are going to need to get a feel for the performance of that core and caches and mmu, etc. worry about that later you have a lot of research to do and software ground work first. If you must get a beagleboard or openrd (with all the extras you have to buy to make a beagleboard usable/useful, the openrd is cheaper, faster, etc). (avoid the plug computer, doesnt fit with what you are trying to do anyway).
There are many good reasons why linux is not used on phones, so you need to research that as well and decide if that is the path you really want to take.
You are likely going to end up with an mpcore or cortex-Asomething. So the ti opap, nvidia tegra, marvell sheeva, etc, all fall into that category. You can get the feel for a cortex A series from any one of them.
Related
I am trying to select a particular companies line of ARM Cortex M microprocessors to work with for a project I want to do. Since all the companies license the architecture from ARM Holdings I am wondering how much difference there can be in the hardware between brands? I am thinking the documentation and software productivity and overall experience may be the deciding factor?
I have tried one company and their documentation was lacking! Thousands of pages of fluff about what wonderful stuff they make but very little info on how to use the things.
Mostly I am looking for good documentation. I don't need endless obsolete sample programs that don't compile and use mystery macros and functions! A line that includes a microprocessor with 2 ADC not just multiplexing channels to 1 ADC would be good but I may end up using external ADC.
Would anybody care to say what they recommend and why.
BTW: My history is programming C++, C# in MS Visual Studio for machine tool HMI as well as motion controllers.
Thanks In Advance
Chris
Most of your application has nothing to do with ARM and the cortex-m. Each chip vendor adds its own peripherals (or sometimes purchased) around the arm core. Most of your code is talking to peripherals. The processor core doesnt make the chip, the things other than the processor core make the chip.
You need to go do your research, stackoverflow is not about doing it for you. You should be able to find a list of parts with the number of peripherals you want, independent of processor core used. While a particular chip vendor may have different uarts across their product line or different gpios, adcs, etc, you can still get a feel for a vendor without having to look at every part on that list as you narrow in.
No vendor has great docs, some do have bad docs, that is part of the exercise. All of them provide libraries, same deal nobody has great libraries, some have bad ones, but the point of the libraries is to hide the details. You need to do your homework and look at the docs, look at that code, can you live with it can you replace it or repair it, or is it better to move on to another vendor or same vendor and an alternate library.
1% of the job is writing the application the other 99% is reading docs and doing experiments to make the peripherals do what you want them to do.
Same brand or different brands with the same name of processor core doesnt mean anything with respect to portability. If you read the arm docs as you should read any of the processor core docs for whatever parts you are evaluating or choosing, you will see that even if 7 vendors have products with the cortex-m0, that core has compile time and runtime options that each vendor could choose from making either the code or the performance incompatible with other chips using a cortex-m0. But the amount of code that would port anyway is a very very small percentage of your project. Most of your project is the not-processor-core stuff.
Note ARM makes a number of cortex-m cores that are not 100% compatible with each other. If you feel the need to go with an ARM core, then narrow in on the one you want, that will narrow your choices as far as available chips goes.
Built in ADCs are there to save on chips, depending on the specs you want, accuracy or performance, you may very well end up with an external ADC which makes the specific microcontroller less important if the ADC and its specs are your primary requirement.
Software productivity, also has little to nothing to do with the processor core. The vendors are going to cobble together an IDE with a compiler and libraries because folks expect that, doesnt make any of them any good nor productive. The text editor alone goes the way of religion and politics with developers, there is no single editor or environment that is perfect for every developer, developers have their ways of doing things and some are compatible and some are not. Some developers can bend some cant. Very rarely do you have to use the tools they provide.
It is not possible for us to choose your part for you nor is it possible for us to choose your development environment. That is not the purpose of stackoverflow.
The time it took to write your question and wait for an answer thus far you could have looked at all the major vendors docs several times over. I hope you didnt stop after the first one.
I am working on a project and my team is responsible for the software stack of the particular hardware.
I only have the instruction set of the processor in my hand and I need to develop the complete software stack with it.
Do I require anything else other than the instruction set for the assembler?
Please note that I am not aware of the organisation of the hardware of that computer
The very short answer is "probably not possible without further information".
At the very least, you will need to know where different types of memory is located, what you need to initialize within the processor itself [this is typically not in the Instruction Set Manual]. Typical examples: interrupt vector, timers, memory controllers, etc that are often part of the processor itself, but not really part of the instruction set.
Obviously, the software stack for a digital wrist-watch is pretty basic. The software stack for a complete Home Entertainment system with the ability to stream encrypted video and also browse the web would be quite large. The software stack for a mobile phone even larger. The requirements for a wrist-watch and building the hardware necessary to do that [not saying you can get it small enough easily, but ignoring that since this is a software, not a hardware question], would probably take a few days at most. A smart-phone that is able to compete with at least some success with the top of the range products on the market today would take a large team of very skilled software developers a couple of years to complete. Obviously, there are a lot of other software based systems somewhere between those relatively extreme examples.
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 2 years ago.
Improve this question
I just watched the Super Mario Bros. -1 World glitch in youtube and I really began wondering about the code behind those games. Which language was used? What about the OS for the video games consoles? Are there any website with resources about this subject? (I am a 90s video gamer so I am particularly interested about the programming behind those games but feel free to make this a wiki and include links to resources about video games programming in general, if you want)
Having somewhat worked on an emulator for the NES (I have it decoding some opcodes, but none of the other hardware is emulated), I can maybe share a few answers.
For most games assembler was used. Optimizing compilers, if available for the CPU were nowhere near as good 20-30 years ago as they are today. To get performance, you needed to write in assembler (This even held true on the PC. Parts of Doom are in ASM). All the more so, since the NES CPU ran at less than 2MHz. Also, memory was more expensive then than it is today. The original Mario was stored in about 40k of memory. 16k of that was the actual code, and the remainder was the graphics and sound resources.
Until the 32 bit console era, any sort of operating system, or even built in utilities, on a console was uncommon (Sega CD was the one of the few in the 16 bit era with an actual BIOS, and there was a small program burned into the Game Boy's processor that was responsible for the Nintendo logo scrolling down on power on). See above about size constraints, as a main reason. When inserting the cartridge, the ROM chip in the car was connected directly to the address bus of the CPU. On power on, the CPU would read from a fixed address to get the actual address the program started at, and then jumped to that location and started execution.
As for resources, the NES Dev Wiki has resources concerning the NES hardware, along with programmming references. Zophar's Domain also has technical documents and public domain ROMs for quite a few console (I don't know if I should link to ZD on this site, just google it)
Most of the older consoles had some kind of BIOS ROM.
Some of the source code for these are online:
You can read the mostly-commented disassembly to the 7800 BIOS: http://atarihq.com/danb/files/7800bios.asm
The Atari 5200's BIOS source is more interesting, since it does more than just initialize the system and display a splash screen: http://atarihq.com/danb/files/5200BIOS.txt
The Colecovision had an 8K (!) BIOS ROM as well; it's source is here: http://xi6.com/code/coleco/coleco29.asm
The Odyssey II BIOS source is here: http://atarihq.com/danb/files/o2romsrc.txt
The Intellivision had an OS called "exec," can't find a disassembly online, though I did find a bunch of info about it: http://www.intellivisiongames.com/bluesky/hardware/intelli_tech.html#exec and http://www.beeslife.com/faq.htm#_Toc140592020 - it had routines to move sprites, read controllers, and calculate square roots!
Most of the glitches in that video are tile based glitches, where there are bugs in the collision detection of the tile maps that make up the levels. All levels are made up of square shaped tiles. If you notice mario is always between tiles where he shouldn't be.
Back in the late 70s, 80s and early 90s, most software (including games) were written in ASM (Assembly). If you are unfamiliar with Assembly, it is practically a very low level programming language that is hardware specific for programming the CPU. This means that you had to control every pixel on screen and recreate libraries for things like physics, graphics, and even sound! You were very limited in memory so recycling was a must. In the original Super Mario Bros you will notice that the clouds are the same as the bushes, the only different is the color. A lot of sprites were recycled and the game physics were limited.
As games became more and more complicated developers moved onto the C language which allowed for software to be written a lot more quickly because it required less lines of code. Nowadays a lot of console and computer games are written in C++ because it allows for faster development but also allows for the software to be close enough to hardware for faster play.
I havn't done research about this, but Super Mario Bros and releated 90's games are available as .nes files instead of cartridge and there opensource emulator are also available.
AFAIK, these are generally written in C++. I don't know about legality of these nes files and emulator, but they available on internet. you have search with right string!
I'm wondering if anyone knows of a place on the web that I can purchase or download software modules, written in C or C++, for the interaction between microprocessors and other components, like DACs, ADCs, or UARTs. Sort of like a git-hub for embedded C software. Does this place exist?
You're possibly looking for something called a 'board support package' or BSP. For a given operating system it will have a collection of drivers / libraries to help you communicate with the hardware component.
Saying that, some standard hardware interfaces for e.g. 16550 Uart might have drivers that come with the OS.
You might also want to take a look at Jean Labrosse's "Embedded Systems Building Blocks" book. It has some straight C libraries for dealing with UARTs, Analog I/O, timers, etc.
Of course, you do still need to wire them up to the actual chip's hardware implementation (as other answers have indicated, you can usually get libs to help with that from the chip vendors), but they can be a convenient wrapper to let you more easily move your higher level software from one device to another. There's no earth-shattering stuff that would be particularly difficult to do on your own, but it's there for the taking, so why not? Even if it's not exactly what you might want, it's a leg up.
Normally the device manufacturer will supply you with a libc that you can use for all the low-level stuff.
first, decide which chip manufacturer to go for... next, go to their official site or contact them, you would get the libs for the supported IO's and other communication stuffs.
Ok what about for TI? BSPs are something I'm aware of, but they dont' really exist for software that exists below the O/S level.
2nd, lets say I wanted to wanted software to make the TI MSP430 Microcontroller talk to DAC7565. I realy can't find software that relates those two in any reliable way.
I'm talking about a complete software package, something equivalent to a gem in Ruby, where I could call functions like "OutputVoltage(unsigned int voltage, unsinged int channel)" and be oblivious to the hardware implementation.
#nobugz Yes, I agree, but that is awfully restraining. C should be like Ruby where you can only focus on what you want to do, not having to spend time restricting yourself because of the availability of software...
#Shaihi
I'm not, I am a software engineer with an engineering firm who custom design their own boards. I just can't believe that across the entire world and the entire history of software engineering that I am the first person who needs to interface this microcontroller and this DAC. SO therefore it must exist someplace. Maybe I can't get my hands on it but someone, somewhere has done it before.
I'm a very young engineer, but it just seems like there are hundreds or thousands of guys who end up writing the same software again and again. And on top of that, since there are plenty of software engineers who are terribly good at abstraction and reuse, I'm willing to bet there are plenty of engineers who end up re-writing the same software time and time again because the software they write is way too tightly coupled to that specific application.
Just seems like a giant waste of engineering hours.
Did you check the application notes on the A/D vendor's web site? They very often have C code. The problem with assembly language code is that there are so many different ADC and microprocessor vendors and so many different ways to wire up the chip that they can't provide a general purpose library. Also, a programmer may want to poll the end-of-conversion flag or allow the chip to interrupt when the conversion is complete. It is very application specific. Your best hope is that the vendor has some example code that will serve as a guide for how to use the chip. The good news is that user's manuals for these peripherals are a lot better than they were 20 years ago.
Also, the vendor probably has application engineers who will help you with your design.
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.