POSIX COMPLIANT OPERATING SYSTEM for WIXEL Project Report
Total Page：16
File Type：pdf, Size：1020Kb
POSIX COMPLIANT OPERATING SYSTEM FOR WIXEL Hlynur Hansen T-404-LOKA December 2016 School of Computer Science Reykjavík University Project report ii POSIX compliant operating system for Wixel Hlynur Hansen December 2016 Abstract There did not exist an operating system with threading and scheduler for Wixel, therefore I ported RIOT-OS to the MCS51 architecture featured on the Wixel. I have included a scheduler, threads, and a POSIX compliant API for a subset of the supported functions. We use the SDCC version 3.6.0 toolchain for our implementation, that only fully supports C89 for the MCS51 architecture, whereas RIOT-OS is written for C11 and GCC toolchain. I describe how code is stored in memory and how memory allocations are done. Then I go into how memory size restrictions and the instruction architecture of the Wixel complicated this development. iv v Contents Contents v 1 Introduction 1 1.1 The OS implementation . 1 1.2 Background . 2 2 Methods 3 2.1 Research . 3 2.1.1 The Wixel . 3 2.1.1.1 Memory layout . 3 2.1.2 The Development kits . 5 2.1.2.1 Wixel SDK . 5 2.1.2.2 RIOT-OS . 5 2.2 Tools of the trade . 5 3 Results 7 3.1 Contribution and difficulties . 7 3.1.1 Bricking . 7 3.1.2 C89 standardization and MCS51/SDCC changes . 8 3.1.3 CPU and board specifications . 10 3.1.4 Size restrictions . 10 3.2 Using the Operating System . 11 3.2.1 RIOT-OS using the generic board . 11 3.2.2 Testing and application development . 12 4 Conclusion 15 4.1 Summary . 15 4.2 Future work . 15 Bibliography 17 vi 1 Chapter 1 Introduction Reykjavik University uses a test-bed to research wireless signal propagation[1], which is a network of Wixels[2] that communicates using radio signals in a closed environment in the basement. In this test-bed, each app is written on bare metal, that is without using any software abstraction for accessing devices or services. Providing an operating system with a known API would make it easier to work on this test-bed. The operating system would handle program executions, system failures, and other device specific functions more gracefully and in such manner that the resource limitation becomes less of thought to the programmer, We are talking about things like resource control, memory allocation and all handling. My project was to create an operating system for those devices, the motivation is to make everything more convenient for the programmers to use those devices. The less that they had to implement in resource handling the more they could think about what the program should do, in functionality, speaking. 1.1 The OS implementation The defining features of an OS are a scheduler, interrupt and event handling. After some consideration and meetings with my advisor dr. Marcel Kyas, we decided to port an operat- ing system that is publicly available, possible Operating Systems are Contiki[3], Tiny OS[4], Linux[5], and RIOT-OS[6] we need to have a compiler that targets Wixels, the only com- piler available is SDCC so the operating system must support the c language, that eliminates Contiki and Tiny OS from the consideration. The generated image has to fit into 26 KiB including all applications. Linux image already uses 1 MiB at least which eliminates its use, which leaves only RIOT-OS[7], it offers all features that operating systems need and should have, they claim that their operating system should be able to fit on devices with ROM size as low as 5KiB and RAM size as low as 1.5 KiB. This port will be available for public use on GitHub, under LGPLv2.1[8]. Here I focus on problems or barriers and successes regarding this implementation and whether the 6LoWPAN[9] implementation is a real option for these devices. To summarize the implement and research questions: • Implement an operating system kernel with notation of interrupt and event handling • Implement a Network stack, including 6LoWPAN • Implement a support library modeled after the C standard library and the POSIX spec- ification 2 CHAPTER 1. INTRODUCTION • Test the implementation in a test bed and gather the data of that test on packet delivery, ratio and average round-trip times 1.2 Background The first operating system was LEO[10] I and was created in 1951 for the use on, it was so called single stream batch processing system where programs and/or data were submitted in batches[11], around 1961 CTSS was created and it was for the first a time share operating system was developed. General purpose Operating systems are used by every computer user today, systems like Windows, Linux, and MacOS-X. Those systems are in use to make it more convenient for the user and to interact and make use of their computers, in most cases, the user has no knowledge about the implementation of their operating system and does not need to know. Real-time operating systems, on the other hand, are used for specific tasks and specific systems, they provide the programmer the convenience not to think about how he should handle memory locations, device I/O and other peripherals. RIOT-OS implements a microkernel architecture inherited from FireKernel[12]. It was created for the use on Internet Of Things(IOT) devices, which very often are low resource devices and therefore the size of the operating system matters. It runs on a wide spectrum of devices powered by small MCUs. Devices available include the ARM, ATmega and MSP430 family MCUs. It also includes a native option for testing, where RIOT-OS runs as a process in Linux. RIOT-OS features schedule, multi-threading and real-time capabilities, it is modular and includes support for C and C++ programming languages. The first microprocessor was the 4-bit intel 4004 released in 1971, with intel 8008 ar- chitecture becoming available over the next years[13]. MCUs1 Are used for many pur- poses, from simple calculators to embedded devices like the Wixel. The Wixel uses Texas CC2511F32 chip that contains 8051 architecture, 2.4ghz wireless radio module, and full- speed USB interface. It has very limited resources for storage, more about that in Section 3.2 Difficulties. We use the SDCC compiler which is the only freely available c compiler that supports the MCS51 architecture. It supports the ANSI/C89 programming language, it includes an assembler and linker. 1Micro Controller Units 3 Chapter 2 Methods 2.1 Research For me to be able to implement this project I had to research kernel implementations and what are the standard feature set in operating systems. The research list was as follows: • Operating system implementation • Operating systems on low powered devices • CC2511 diagram and implementation • 8051 architecture, functions and assembly • memory management in low powered devices • C89 standards for SDCC compiler use In this time-frame, I had to a lot of reading in a very limited time, while the best reading was the book Understanding the Linux Kernel[14]. The book explains the implementation of the Linux kernel and was used as a model for our own features. 2.1.1 The Wixel Wixel uses Texas Instrumental CC2511 microcontroller and transceiver. it is a cost effective controller that includes 2.4 GHz transceiver with maximum data rate of 350 Kbps and a wire- less range of about 15 meters. The CC2511 implements the MCS51 architecture, both the processing unit and the accumulator use 8-bit implementation and uses bit-level addressing that is instructions can change individual bits of some registers. There are 88 Special func- tion Registers, 22 radio registers, 15 common USB registers, 10 indexed endpoint registers and 6 endpoint FIFO registers. 2.1.1.1 Memory layout The memory layout was a bit of problem in this project, where the compiler did put the function arguments and variable declarations into the same location on the Wixels paged memory segment. This caused the memory to overflow and the compiler to fail. To be able to align everything in the right place I had to use memory alignment attributes for all of 4 CHAPTER 2. METHODS Figure 2.1: Memory layout my variable declarations. The following attributes define where in the address space the variables should be stored. DATA Direct accessible memory (256 Bytes) Here pointers to the functions are stored. IDATA Indirectly accessible memory segment (128 Bytes) Mostly for storing stack locations of variables passed to functions. PDATA Paged memory segment (first 256 bytes of XDATA) For variables that need to be on the top of the stack, usually something that controls some of the devices periphs. XDATA External memory segment (size 4 KiB) This is the stack segment for all variables that can change and to store stack-frames for functions while they are working. CODE Code segment (Read only) Here in this segment all code and constants that do not change are stored. For memory layout see Figure 2.1 and the Wixel is displayed in Figure 2.2. For the Wixels specification see Table 2.1. 2.2. TOOLS OF THE TRADE 5 Processor CC2511F32 @ 24 mhz Ram size 4096 bytes Program memory size 29 KiB User I/O lines 15 Minimum operating voltage: 2.7V Maximum operating voltage: 6.5V Reverse voltage protection: Y External programmer required: N Table 2.1: Wixel specs Figure 2.2: The Wixel 2.1.2 The Development kits 2.1.2.1 Wixel SDK The Wixels development bundle is available on their homepage https://www.pololu. com/product/1336/resources.