Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
I followed these instructions and was successfully transmitting IEEE 802.15.4 frames on a GINA Mote. I know it was working because I have a packet sniffer that captured transmitted packets.
Here is the source code: https://github.com/openwsn-berkeley/openwsn-fw/tree/d1ec9982fbc101061b4bc70bde239e54cd1367c4/firmware/openos/bsp/boards/gina
I'm a little confused how and why it's working though. Is this code loading an operating system (like RTOS) on the Gina mote or is this project OS-less ?
I'm looking for a solution that does not require an OS / bootloader.
I would appreciate if one of the experts in the community could weigh in on this.
The JTAG adapter rams the executable image up the MSP430 processor's butt, sets up the MSP430 to start executing at the image's start address, and lets 'er rip. That's it. There ain't no OS, and there's no code onboard the little processor board required for loading the executable image. Your program is the only code it ever knows. (And the JTAG adapter probably burns the code into the processor's flash, so it stays resident even when the JTAG adapter is removed.... and starts executing again any time the processor is reset.)
Now, you may wonder... There may be C runtime facilities available that you might think are associated with an operating system... perhaps printf(), malloc(), new, etc. Those are part of the C runtime & I/O subsystem, and can of course be implemented for a custom platform with no OS.
UPDATE: Hmm. What I mentioned above was true when I played around with small MSP430's back in 2008. At that time I only recall IAR, I don't recall there being mspgcc. I believe the IAR solution is as I described above. The mspgcc solution seems to involve a "BSL" (bootstrap loader), per this web page. Or perhaps the BSL is just pre-loaded on the MSP430, and even IAR uses it... I dunno. In any case, with either the IAR or mspgcc toolchain, ultimately you should be able to burn your program into the processor's built-in flash, and once burnt into it, you can remove your JTAG programming/debugging adapter, and from then on, the CPU will automatically run your program every time it boots.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I'd like to run a Debian OS .iso image for ARM processors using QEMU in a host running Ubuntu (over an x86 architecture).
I executed the following line in a terminal:
aaron#aaron-HP-ZBook-14:~/Descargas$ qemu-system-arm -machine sabrelite -cdrom debian-10.7.0-arm64-netinst.iso -m 1024
But then, the following window appears.
https://i.stack.imgur.com/rB2PZ.png
I don't know why Debian OS is not initiating after executing the previous line. Instead, a QEMU command line interface appears waiting for the user to enter some commands.
Thanks in advance!
Aarón.
You're trying to boot a 64-bit Arm CDROM image on a board which is 32-bit only, so this is never going to work.
More generally, most Arm boards will not simply boot from a CDROM image passed via the -cdrom option, because they don't have firmware/BIOS images which will run on QEMU and do the handling of booting from CD. Many boards don't even have an IDE or SCSI interface that a CDROM drive could be plugged into!
You should decide whether you want (a) to boot an image on the sabrelite board, (b) to boot a 32-bit arm image, but you don't care which board (c) to boot an arm64 kernel, and find a suitable tutorial or set of instructions accordingly. Lenna's link is good for option (b); there's a similar tutorial also for option (c). I don't know of any sabrelite specific instructions.
It's worth reading the QEMU documentation section on choosing an Arm board model -- unless you have a strong reason why you want to use a particular board model and a kernel that you know works on that board model, then 'virt' is usually a better choice. Even 'virt' won't boot directly off a cdrom, though, unless you also pass it a suitable UEFI bios image.
Generally if you try to run qemu and only see the monitor there is likely something wrong with your image.
In this case you are attempting to boot "debian-netinst" which is the debian network-install image. If you want to emulate a debian-arm image I would recommend following this tutorial to get debian-arm up and running.
Here is a script that will automate the process in that tutorial
The script runs two QEMU commands. The first is a lengthy install process that should extract a debian initrd/kernel. The second QEMU command will boot the actual image. After the second command runs you should see the QEMU monitor open in a window. Use ctrl+alt+(1 or 2) to switch to the terminal/gui display
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I programmed a little code for motion detection device(DA14531 SmartBond TINY module based on a CortexM0+) and I am having some experiments with it. at the end and after debugging and testing, I generated an ISO file and now I want to flash the device. Is the process similar to burning the ISO file on a USB flash or is the process different? I only have one device and I dont want to do something irreversible so I came here for some guidance first.
I looked online for a while but nothing matches my specifique situation, so providing me with the correct links is also helpful
The ISO 9660 format was designed for optical disks, using it is likely irrelevant to your use case, since there is IMHO a near to zero chance you will find a tool that will allow you to flash directly your program in a Cortex-M0+ device from a file in ISO 9660 format.
And if you may flash the ISO file as is in your Cortex-M0+ flash memory, your device will likely be unable to boot since it does rely on very specific information (stack pointer, first instruction to be executed) to be flashed in a verify specific location, not mentioning the waste of flash memory space this would cause.
That is, if Dialog documentation does not specifically mention the possibility of flashing a file in ISO 9660 format, this is likely (and not surprising) that this is not possible using Dialog software and hardware support tools.
So when you read the documentation for this product you noticed there is an SWD interface which is certainly one way into the part. When you further examined the pro kit and other solutions from them you see they mention segger jlink interfaces for debugging etc. Further reinforcing SWD as at least one interface into the part. Through that interface (SWD is ARM) you access the flash controller (has nothing whatsoever to do with arm it is chip specific) and through that you write your application binary that the part will run (the machine code and data that the processor uses, your application).
ISO is closely related to PC's with a BIOS/EFI which also means x86, and has nothing whatsoever to do with a microcontroller much less a non x86, non BIOS/EFI PC/Laptop. It is extremely unlikely that you can get enough software on a cortex-m0(+) based platform that if you had an interface to media that can hold it that you could parse it and extract anything useful, and then have resources left to load and execute any programs in ram. No way whatsoever in any part I have heard of that you could do this in ram such that you could extract something you could load to the flash on the part. Plus you have to get that program into the part before you can then later support ISO, if you could, which you can't.
The only remote way an ISO makes any sense at all or has any context is if on your PC you boot off of an ISO image and that ISO image for the PC (not the mcu) contains a development system. For example a pre-prepared Linux operating system distro with the tools from the vendor for this part so that you don't have to install the development system on your computer you can run it off a ramdisk using a live image on an ISO. That development system would not use ISO files but the proper file formats to develop binaries and load them to the board via SWD or some other chip/board specific interface.
Beyond that there is no further reason to talk about ISO's and microcontrollers.
Some chip vendors (not arm, the chip vendor) may also provide a factory bootloader or logic that supports for example a uart, maybe spi, maybe i2c, maybe usb interface that you can use chip (not arm) specific software to talk to software running on that chip (the bootloader) that can then write to the flash. You can also write your own bootloader if there are enough resources in the system. The (arm based) mcu world is moving away from these bootloaders, two of the three main companies that used to always have them have started to remove them or disable them as a default feature.
Other companies provide no other interface than SWD to program the part, SWD or nothing. Certainly in the cortex-m0+ market where every penny counts and the extra flash for a bootloader and extra chip real estate, etc add to the overall cost for a legacy feature that is becoming less important because developers can now easily obtain SWD interface modules for a few dollars. It is not like the old days where a JTAG board cost $2000. At this time all cortex-m parts support SWD, making it the most useful interface and reminding developers that having tools that can access that interface being worth the ($5, plus time to learn to use it) investment.
The tools used to write the flash dictate what file formats are supported, these days a raw binary image or an elf file format are the main two. The old days included file formats like Intel hex and Motorola s-record but it is only old timers like me that favor those file formats, even though an elf is trivial to parse, and a raw binary image even simpler, about four lines of code.
Some chip vendors do not provide enough information to roll your own, but most often they do. Arm long ago released the SWD interface information, so it is technically possible to roll your own and then support whatever file format you want. But you would have to distribute this tool along with the ISO file, so you would what use a second ISO file to distribute the tools to read the first one. Based on your question and comments you are a long long way from writing tools like these. Especially when working tools like openocd exist that support the main file formats (elf and raw binary) and can speak SWD into the current line of cortex-m cores.
Again if you are suggesting using an ISO to distribute tools along with your binary to be loaded and run on a PC that might make sense, but it is easier for the end user to simply download the tools from the chip vendor or tools vendor and then download the binary file from you, rather than put in the extra work to deal with an ISO.
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 7 years ago.
Improve this question
I know that a loader loads a program into memory. But how can I implement it using a program? Using assembly or C. This might be very useful. Or atleat a reference.
Maybe you already understand this, not sure. A program loader at a high level simply reads/downloads/accepts the program, parses the file format if required. Places the program in memory, and jumps/branches to it.
Now if you get more specific, say a bootloader for a processor you generally dont have a file system yet or such things so maybe you can only accept programs that are already on the flash, one of your main use cases, or allow developers to download test versions, destined to be the program on the flash, xmodem, ymodem, or other protocols. Maybe if there is ethernet then that way or usb if available and makes sense or removable media (sd cards, etc). At the end of the day you still support some type of format be it just the raw memory image of the program or some other formats (intel hex, motorola srecord, maybe elf, etc).
An operating system has a lot more work to do, because take windows or linux or mac right now, write a simple application that reads and parses a simple program, read that program into your applications memory space or malloc some, whatever, then try to branch to it. The operating system stops you, there are ways around this, but that is not the point, you are an application you are not the operating system. But if you were the operating system loader, then you simply have more permissions, being the operating system you have designed what your file format is, what the agreed entry point address is, what the system interface is for applications making calls, etc. Programs have to conform to your rules, you would then read the binary, parse it (perhaps you only support .elf file formats for example), allocate memory for the program per your rules and the programs desired allocation of resources (ideally, initially, part of the file format), per your operating systems rules you setup the virtual address space and point it where the program has been loaded, and then branch to the program changing from super user to user mode on the way.
Your question is extremely vague though, cant understand if you understand the basics and want detail (an application is not a loader on an os with protection, so simply go read the source for linux or bsd, etc), or dont understand the basics (make a little bootloader for a microcontroller or use an instruction set simulator if you dont want to buy a microcontroller).
I feel as if the best manner of doing what I think you are trying to do is fork a process off, and create a process running within it? This is, if it's what you're asking best done with the unistd.h library, in both C and C++, and if you want to get a bit more direct the PThreads library. However if you don't at the moment know how these things are called, I recommend heavy reading before you mistakenly create a fork bomb, and crash your system.Look into the openpub documentation if needed. However I heavily recommend cleaning up this question, and I also feel that it's been asked a bit often on this site as well.
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!
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.