A Guide to Approximations
Most embedded processors don’t know how to compute trig and other complex functions. Programming in C we’re content to call a library routine that does all of the work for us. Unhappily this optimistic approach often fails in real time systems where size, speed and accuracy are all important issues. The compiler’s runtime package is a one-size-fits-all proposition. It gives a reasonable trade-off of speed and precision. But every embedded system is different, with different requirements. In some cases it makes sense to write our own approximation routines. Why?
Consistent Overhead Byte Stuffing
Byte stuffing is a process that transforms a sequence of data bytes that may contain ‘illegal’ or ‘reserved’ values into a potentially longer sequence that contains no occurrences of those values. The extra length is referred to in this paper as the overhead of the algorithm. To date, byte stuffing algorithms, such as those used by SLIP [RFC1055], PPP [RFC1662] and AX.25 [ARRL84], have been designed to incur low average overhead but have made little effort to minimize worst case overhead. Some increasingly popular network devices, however, care more about the worst case. For example, the transmission time for ISM-band packet radio transmitters is strictly limited by FCC regulation. To adhere to this regulation, the practice is to set the maximum packet size artificially low so that no packet, even after worst case overhead, can exceed the transmission time limit. This paper presents a new byte stuffing algorithm, called Consistent Overhead Byte Stuffing (COBS), that tightly bounds the worst case overhead. It guarantees in the worst case to add no more than one byte in 254 to any packet. Furthermore, the algorithm is computationally cheap, and its average overhead is very competitive with that of existing algorithms.
An Introduction to programming an Atmega microcontroller
This document an introduction into the programming of an Atmega microcontroller. It is separated into the fi rst part guiding like a tutorial for beginners and a second part which is a reference book to the functions provided in the basis. The examples and explanations provided are neither exhaustive nor complete. The only aim of this document is to lower the burden of getting started. Only a basic knowledge in C is required.
Design and Implementation of the lwIP Stack
LwIP is an implementation of the TCP/IP protocol stack. The focus of the lwIP stack is to reduce memory usage and code size, making lwIP suitable for use in small clients with very limited resources such as embedded systems. In order to reduce processing and memory demands, lwIP uses a tailor made API that does not require any data copying. This report describes the design and implementation of lwIP. The algorithms and data struc- tures used both in the protocol implementations and in the sub systems such as the memory and bu®er management systems are described. Also included in this report is a reference manual for the lwIP API and some code examples of using lwIP.
Embedded Touchscreen Handbook
I want to add a touchscreen to my embedded product. Where do I start? That question is common nowadays. Most manufacturing companies are seeing the value – maybe the necessity – of touch screen technology. Many of them don’t have a long-term or close association with the technology, yet they expect their embedded engineers to handle the project successfully and on a tight schedule. These engineers often have questions... - How much am I going to have to learn to get the job done? - I’ve heard that LCD suppliers were not like other suppliers. But, how so? - What don’t I know that could shift the project from “exciting” to “doomed.” You have choices: Probably the three major questions that crop up when you need to add an LCD touch screen to your product are these: - Should I use a full-blown, embedded operating system, like Windows CE, CE Linux or QNX? - How much work does it take to develop an in-house LCD system from scratch? - Do I have other options? The answer to the first two questions is a resounding “maybe,” (depending on what you need to accomplish). The answer to the third question is, probably “yes.” In most cases, there is another option. Who should read this? If you are an embedded engineer who is thinking of adding a touch screen to your product, and if: - You need to know what is involved in adding color touch controls to your product. -You need to understand the risks (both known and hidden) involved in LCD technology. - Your main area of expertise is not LCD technology. - You don’t want to re-focus your time to acquire color LCD technology expertise. If you find that any of the statements above voice your concerns, you may find this paper worth reading.
Interrupt handling in an ARM processor
This document is going to guide you at every step as you sit down to design the interrupt handling in software for an ARM system.
Consistent Overhead Byte Stuffing
Byte stuffing is a process that transforms a sequence of data bytes that may contain ‘illegal’ or ‘reserved’ values into a potentially longer sequence that contains no occurrences of those values. The extra length is referred to in this paper as the overhead of the algorithm. To date, byte stuffing algorithms, such as those used by SLIP [RFC1055], PPP [RFC1662] and AX.25 [ARRL84], have been designed to incur low average overhead but have made little effort to minimize worst case overhead. Some increasingly popular network devices, however, care more about the worst case. For example, the transmission time for ISM-band packet radio transmitters is strictly limited by FCC regulation. To adhere to this regulation, the practice is to set the maximum packet size artificially low so that no packet, even after worst case overhead, can exceed the transmission time limit. This paper presents a new byte stuffing algorithm, called Consistent Overhead Byte Stuffing (COBS), that tightly bounds the worst case overhead. It guarantees in the worst case to add no more than one byte in 254 to any packet. Furthermore, the algorithm is computationally cheap, and its average overhead is very competitive with that of existing algorithms.
Software Development for Parallel and Multi-Core Processing
The embedded software industry wants microprocessors with increased computing functionality that maintains or reduces space, weight, and power (SWaP). Single core processors were the key embedded industry solution between 1980 and 2000 when large performance increases were being achieved on a yearly basis and were fulfilling the prophecy of Moore's Law. Moore's Law states that "the number of transistors that can be placed inexpensively on an integrated circuit doubles approximately every two years." With the increased transistors, came microprocessors with greater computing throughput while space, weight and power were decreasing. However, this 'free lunch' did not last forever. The additional power required for greater performance improvements became too great starting in 2000. Hence, single core microprocessors are no longer an optimal solution.
An Introduction to programming an Atmega microcontroller
This document an introduction into the programming of an Atmega microcontroller. It is separated into the fi rst part guiding like a tutorial for beginners and a second part which is a reference book to the functions provided in the basis. The examples and explanations provided are neither exhaustive nor complete. The only aim of this document is to lower the burden of getting started. Only a basic knowledge in C is required.
Interrupts, Low Power Modes and Timer A
This document contains a lot of what you need to know to get the most out of the MSP430. The MSP430 line is renowned for it's low power usage, and to really utilize it well you have to architect your software to be an interrupt driven device that utilizes the low power modes.
A Guide to Approximations
Most embedded processors don’t know how to compute trig and other complex functions. Programming in C we’re content to call a library routine that does all of the work for us. Unhappily this optimistic approach often fails in real time systems where size, speed and accuracy are all important issues. The compiler’s runtime package is a one-size-fits-all proposition. It gives a reasonable trade-off of speed and precision. But every embedded system is different, with different requirements. In some cases it makes sense to write our own approximation routines. Why?
Embedded Touchscreen Handbook
I want to add a touchscreen to my embedded product. Where do I start? That question is common nowadays. Most manufacturing companies are seeing the value – maybe the necessity – of touch screen technology. Many of them don’t have a long-term or close association with the technology, yet they expect their embedded engineers to handle the project successfully and on a tight schedule. These engineers often have questions... - How much am I going to have to learn to get the job done? - I’ve heard that LCD suppliers were not like other suppliers. But, how so? - What don’t I know that could shift the project from “exciting” to “doomed.” You have choices: Probably the three major questions that crop up when you need to add an LCD touch screen to your product are these: - Should I use a full-blown, embedded operating system, like Windows CE, CE Linux or QNX? - How much work does it take to develop an in-house LCD system from scratch? - Do I have other options? The answer to the first two questions is a resounding “maybe,” (depending on what you need to accomplish). The answer to the third question is, probably “yes.” In most cases, there is another option. Who should read this? If you are an embedded engineer who is thinking of adding a touch screen to your product, and if: - You need to know what is involved in adding color touch controls to your product. -You need to understand the risks (both known and hidden) involved in LCD technology. - Your main area of expertise is not LCD technology. - You don’t want to re-focus your time to acquire color LCD technology expertise. If you find that any of the statements above voice your concerns, you may find this paper worth reading.
