Embedded Electronic Systems Blog

I came across a nice article on real - time systems. This article is short and easy reading. This paper addresses some of the differences between real-time and general operating systems including an analysis of several common misconceptions including performance issues, latency, hard vs. soft real-time systems, programming, APIs and the software kernel. I have provided the link to the article below, in the interim lets review some Real-time Operating systems essentials. A real-time system needs to be implemented to insure determinism. For real-time systems determinism is defined as knowing (determining) the worst case latency for a response to complete from the start of the associated input stimulus. Determinism is the main characteristic of a real-time system and not the average latency speed performance. An embedded system can be implemented with a very fast designed system, that on average, can perform faster with less latency than a real-time designed system. But the key here is "on average". To qualify as a deterministic system, the system is required to operate below a defined latency response. If a you plot a system's response (latency) on a statistical bell curve, you may find for non-real-time fast systems, there is on average a very fast response, but on the edge of the curve there are points of very poor performance (latency). When plotting a real-time system, the performance (latency) distribution will be contained within a lower limit (higher limit for latency). Many embedded systems today do not implement real-time OSs but rather depend on the raw speed of the system to achieve the desire outcome. For systems application as with automotive braking, a developer may not want to depend on this raw speed but opt for a deterministic real-time OS. Hence the myth that real-time OSs are faster performance is just not always true - they are deterministic! Hard Real-time systems achieves real-time determinism thru implementations that assures deterministic responses. Soft Real-time systems achieves try to achieve real-time determinism thru brute force with fast average system responses. As we just reviewed, real-time is defined around the term deterministic. Deterministic, for real-time systems, is quantifying the longest latency for a given response. The latency of a real-time system can be further divided into categories. Before doing this, we need to understand the nature of multiprocessing systems. Multi-processing systems service multiple tasks or processes by two methods or a combination of the two methods. The first method assigns a time slice to each task, the task will execute until the time slice expires. An internal OS timer will expire causing an interrupt allowing the next task on the task list to execute. The second method is pre-emption where tasks are assigned a priority. A task with a higher priority can pre-empt a task with a lower priority by moving up in the task list and start to execute before the the lower priority task has completed. read original article

Introduction

Communications, Tele-communications, Hi-tech product and service companies give away nearly 30% of their technical support services on average. This is caused, simply by the lack of understanding and defining what are the customer’s insights to good customer service, Accenture (NYSE: ACN) survey has found.

Methodology

Accenture commissioned Lightspeed Research to conduct two online surveys. One survey queried providers of 115 executives at the vice president level or above at communications products and services companies. The second survey queried customers or 542  executives at the manager level and above for product and service companies.  Countries represented in the surveys included Canada, China, Finland, France, Germany, Great Britain, India, Italy, Japan, Sweden and the United States.

Story

Hi-Tech product provider who provides customer service need to create a balance with customer satisfaction while adhering to a customer service business model which does not give away services. There are situations that providers are tempted to give away services to their largest accounts for free. But lacking the customer insight of what service customers should receive and when to charge may create decisions just based on single parameter as customer size. Having the proper customer insight to make more informed decisions about to whom, when, and why they should charge or not charge for these services, will provide superior customer services.

Although many providers are giving away services, this approach is not necessarily maintaining the optimum customer retention. Nearly 30 percent of business customers surveyed are considering switching to another provider because they are dissatisfied with the quality of customer service they receive.

The challenges providers face in delivering superior service fall into 3 most often categories:  1) their lack of supporting technology (selected by 30 percent of respondents), 2) a lack of trained resources (29 percent), and 3) non-existent definitions of support processes (22 percent).

Survey respondents were asked to explain what they considered to be the main characteristics of a superior, differentiated customer experience. The top three characteristics were:  1) knowledgeable staff and accessible support (32 percent); 2) efficient and timely problem resolution (26 percent); and 3)  proactive, personalized solutions (21 percent).

According to both the providers and the customers, the most important metric to rank service is : 1) quality and competency of service agents and 2) the ability to address customer concerns on the first phone call or e-mail.

The survey also discovered that, compared with customers in Europe or Asia, those in North America are more loyal to their providers and less likely to have switched providers or considered doing so. Furthermore, the research found that if North American communications and high-tech companies deliver a distinguished and superior customer experience, they have a 20 percent better chance than European and Asian companies of generating more customer service revenues from the same customers.

The article continues by listing the surveys top actions of delivering high quality customer service.

– Enhance the content on the service and support portal;

– Invest more in training and developing customer service agents;

– Enhance the knowledge of each provider’s installed base;

– Improve first-call or email resolution;

– Improve the overall customer experience of self-service, not just reduce costs;

– Implement analytical and diagnostic tools.

Summary

To survive during this current economic crisis, providers have to find ways to improve ther customer support and services to their customers without giving it away for free. Knowing the insight of the customers with what they expect from support and service will help providers define proper metrics, actions, processes and pricing models.

Additional details about the research, titled “Achieving High Performance Through Customer Service and Support: What Communications and High-Tech Business Customers Want, What They Get and How to Bridge the Gap,” can be found at: http://www.accenture.com/Global/Research_and_Insights/By_Industry/Electronics_and_High_Tech/AccentureGap.htm. To access Accenture’s customer service home page, go to www.accenture.com/customerservice.

Technorati Profile

I read an article provided by a life cycle management software provider on the topic of revision control. The article started with explaining how a development company came into a  disaster. The disaster was caused by poor revision control techniques. The explanation of the disaster focused on a supply chain nightmare during the  product early manufacturing run. The disaster still manifested although the company had a very creative staff, a well defined product and markets.

Since I am also a stickler for implementing revision control on R&D projects, I also have many of my own thoughts on the subject. I believe a R&D organization can be 2 -4  times more productive just by following good revision control with archiving practices.  These practices  are much over looked in the favor of focusing on creativity, technology and schedules. If engineering development productivity is defined as the effort and time to bring an engineering product to market for mass production rather than bring a single  prototype to a lab bench, then one must consider strong revision control with archiving practices.

Controlling your IP

A revision of a product’s design or of a single object in a design defines a snap shot of the state of design. By controlling your designs or your IP,  means you know the state of the design at any particular time. Thus, you can rebuild copies of the design, reference test records and all documentation for the state of the design.

To implement revision control on a project’s objects/components, one must assume that the project team has control over the objects/components  intellectual property (IP).  Hence the team must be able to fully identify the state of the design so to tag it a revision. This may sound obvious, but for  many situations,  designs go unfinished,  handed-over uncoordinately to a  factory engineering group or the IP for an object is out-sourced** but the IP is not 100% fully brought back in house. In these situations the state of the design is not well known and a revision tag does not capture the true state of the design.

**out sourcing IP is different then out-sourcing a component to be build and supplied by the out-sourcing entity, the latter assumes the out-sourcing entity controls the design and is responsible for the processes including revision control - they are controlling the IP.

Traceability and Revision Control

Revision control with hierarchy, encapsulates all the sub-objects of an assembly (parent object) allowing for traceability.The traceability allows one to identify the revision of sub-objects for a particular higher level assembly revision.

A well revision control process with proper part numbers provides traceability within all documentation. Document items include  BOMs, Schematics, Drawings, Component description and Software source.  Thus, as an example, to allow a schematic revision to be traced to an associated  BOM revision.

Traceability allows for the linking all documentation for an assembly with their proper revision. Tracing which test plan revision was used with which build BOM revision is an example of producing productivity. Testing a build of an assembly with the associated test plan eliminates wasting resources by not testing with an out of revision plan.

Revision Control and a Central Repository

A sound revision control implementation must depend on a single centralized data base for repository achieving or storing of the documentation material. If not centralized, then when documentation is updated to a newer revision, it may not be seen by all parties and subsequent updates may not be done on the most up-to-date document revision.

The central repository is essential for all disciplines to work from, fincluding Engineering, Testing, Purchasing, Manufacturing and the external Supply Chain.

Proper Classification of objects in the Archive Repository -Reuse

To properly revision any object in a design, the object in the repository must be properly identified. This ensures that when a change occurs the proper object is revision-ed. Similarly, as when having multiple copies in multiple repositories creates situations of revision mistakes on an active design, also, having multiple part numbers for the same design objects / components within a single repository creates situations of incorrectly selecting  an object / component for a design.

Rigorous class / category definition, parameter definitions, and vendor identifications are required for each object / component in the repository. This eliminates multiple part numbers for a single component, thus eliminates error in selecting an object or creating a new component when a suitable component exist but is not well classified to identify.

Having multiple part numbers for a single object can create tremendous inefficiencies. These inefficiencies manifest by having  multiple excessive factory inventory, decreased purchasing volume leverage, and multiple design documentations (component symbol, component decal, component support documentation). The latter contributing to the lack of reuse.

Productivity is greatly affected by dedicating resources in creating multiple documentation for a single component, and by the lack of reusing an existing proven, tested component. Even a simple electrical component, has a  schematic symbol with verified pin-outs, a layout decal with verified geometries and verified vendor identifications. When considering the supply chain logistics with purchasing and inventory control it is easily seen how exponential productivity gains are realized.

Life Cycle Management pulling it all together

Life Cycle Management pulls all the above together in a mechanism to orchestrate changes and revisions on a design or design objects / components. This management uses Change Orders (ECO, MCO) and Change Notices (ECN, MCN) to notify the proper persons in all disciplines of changes of the design. It also implements a pre-defined approval process to assure the change orders and notifications are excepted and approved appropriately.

Summary

Increase your productivity by multiple folds by having revision control your friend!

This technical paper provides an overview of Hall-effect sensors, particularly the use of two-wire, Hall-effect digital switches in automotive and industrial applications.

The Hall effect refers to the principle that when a magnetic field is applied perpendicularly to a current-carrying conductor, a difference in potential appears on opposite sides of the conductor through which the electric current is flowing. Based upon this principle, Hall-effect sensors detect changes in the magnet field and provide a proportional output voltage. They thus allow contact less sensing and, consequently, can be deployed in robust packages that protect against environmental elements. Because they provide increased reliability in harsh environments, Hall-effect sensors are used in a wide range of industrial and automotive applications from motor-speed control for window lifters and sunroofs to on-off switch detection for doors and key ignition.

There are a variety of Hall-effect sensors available today such as three-wire and two-wire digital sensors, linear sensors, current sensors, and bipolar or unipolar digital switches. Two-wire sensors have two connections: one for the supply/output and the other for ground, as opposed to three-wire sensors that use an individual connection for the supply and the output. Two-wire, Hall-effect digital switches are commonly used in automotive and industrial applications in which noise immunity is an important consideration and in which the Hall sensor is remote from the associated electronics. This form of current-mode signaling is highly immune to noise and facilitates simple diagnostics, since a working Hall sensor will always draw some current. These sensors provide two distinct levels of current depending on whether the magnetic field is applied or not. While current levels vary depending on the sensor manufacturer, they typically range from 5mA to 8mA for low level (no magnetic field) and 11mA to 14mA for high-level (presence of magnetic field) signals. Continue reading…… A Fully Integrated, Robust Solution for Interfacing with Hall-Effect Sensors

Introduction

This is the second post of an on-going topic on object file systems. Before diving into object file systems, I am reviewing some legacy file systems. The last post was on the topic of the FAT file system and this post, I am dedicating it to EXT2 Unix-Linux file system and an introduction to file metadata. Since this an embedded systems blog, I will also comment on embedded related topics, and hopefully it will be a too much of a diversion.

Linux-Unix and File Systems

Linux supports several different file systems. Some of the most common to access storage devices are:

• Ext2: Came for UNIX file system. It has the concepts of blocks, inodes and directories.
• Ext3: enhanced, supporting journaling capabilities. and POSIX ACL (Access Control Lists).
• ISO 9660, a CDROM file system.
• Linux also supports Microsoft NTFS, VFAT, NFS, and many other file systems.
• JFFS, JFFS2 for FLASH embedded systems

Linux also use file systems to access kernel objects. Since this is outside the context of file systems with storage device it will not be discussed in this post.

Linux and Disk Partitions

Although a Unix-Linux system can use only two/three partitions, boot/root and swap, many Unix systems implement multiple partitions to store different directory data. Each partition requires a separate disk partition. The following are a few of the file systems:

• Root partition -   files under several directories including /dev, /sbin, /tmp etc
• /usr - Stores application programs
• /var - Stores log files, mails and other data
• /tmp - Stores temporary files
• /boot - stores kernel images and boot loader configuration
• /home -stores users home directories
• Swap partition

There are many reasons for creating multiple disk partitions, and these reasons are based on supporting a multi-user system for security, backups and recoveries.

Embedded Flash Partitions and File Systems

Embedded systems have tighter control on the system, typically one application is running and the same resources are available for the application at any given boot.  Hence embedded systems do not typically divide the OS system into multi-number of partitions in FLASH storage. But, embedded systems do use multiple partitions, typically only one of the partitions is accessed by a  high level file system.

An embedded example where there are 4 partitions:

1. bootloader
2. params
3. kernel
4. root file system(JFFS2, JFF or other File system)

File systems such as JFFS2 requires underlining drivers to access the storage devices. Hence, the Linux MTD drivers are implemented. Typically the MTD_Block module is preferred over the MTD_Char to emulate FLASH as disk drive.

The EXT2 File System

The EXT2/3 file system is worth exploring in our quest in understanding object base files systems.

The space in EXT2 file systems split storage into  blocks, which are organized into block groups. This partitioning reduces external fragmentation and minimize the number of disk seeks required to read a large amount of consecutive data.

Each group duplicates information critical to the integrity of the file system as well as holding the files and directories as blocks of data. This duplication is necessary to recovery data in the event of a disk corruption.  Each block group contains a copy of the block group descriptor table,  a block bitmap, an inode bitmap, an inode table and followed by the actual data blocks.

The superblock contains important information about the file system as a whole, and not to any particular group. This information includes the total number of blocks within the file system, the time it was last checked for errors and crucial information for the booting of the operating system. Since if the superblock became corrupted, the file system would not be able to mounted, a copy of the Superblock is kept in every block group.

The group descriptor stores information on each group. The group descriptor stores the location of the block bitmap, inode bitmap and the inode table for every block group (duplication).  An allocation bitmap is simply a list of bits describing which blocks or inodes are in use

Each file in the file system is associated to one inode. The inode stores information about the file including the creation and modify times, the file permissions, the owner and where the file is stored on disk.

The inode points to the location which the file is located on the disk. There are fifteen pointers to data blocks within each inode. Since of the pointers can implement indirect addressing (pointing), thus files larger than 15 block can be supported.

Meta Data and Files Systems

Most file systems keep metadata about files.  This information is stored sperate from the file data. The Linux-Unix EXT file system places metadata in a structure named  inodes. Meta data for EXT2 can range from simple timestamps, ACL, owner, size, and mode.

With more complex and open-ended metadata, it becomes useful to search for files based on the metadata contents. Apple Computer’s Mac OS X operating system supports cataloging and searching for file metadata through a feature known as Spotlight. Microsoft developed the Instant Search system in Windows Vista, Linux implements file metadata using extended file attributes.

Summary

In our quest of understanding object file systems, we first reviewed two legacy files. We reviewed the FAT files system in my previous post : “Part I Object Base File Systems - FAT Legacy File System“, and in this post the EXT2 Unix-Linux files system. We were also introduced to file metadata which is deployed in objec tfiles systems. Stay tuned for more posts on object files systems.

Introduction

A file system is designed for the storage of files and directories on a physical data storage device. Since disk drives were the first and still most prevalent storage device, the terminology Disk File Systems, is widely deployed to refer to file systems. The general computing environment also implements file systems for other storage devices such as CD ROM, Flash Drives and SD cards. Examples of disk file systems include FAT (FAT12, FAT16, FAT32), NTFS, HFS, ISO 9660, and UDF.

Embedded applications typically use FLASH memory ICs as the storage device. Some typical Embedded FLASH file systems are: JFFS, JFFS2, FAT(adapted for embedded applications), cramfs, ramfs and YAFFS.

This post will explore the legacy but still well deployed FAT file system. Future posts will then explore object base file systems and their advantages.

Legacy Files Systems

To start, looking into some well known file legacy systems will help to understand the benefits of a Object File system. The first file system that comes to mind is the FAT file system develop by Microsoft.

FAT File System

FAT is an abbreviation for File Attribute Table. The FAT file system goes back to the days of the DOS OS and and earlier versions of the Window OS. For floppy disks, it has been standardized as ECMA-107 and ISO/IEC 9293. FAT still is the choice for flash drives because of its portability and standardization.

To implement the FAT file system the Hard Drive must first be partitioned.  The partition is formatted into sectors as is depicted in the below table.

Boot Sector

FS Information Sector (FAT32 only)

More reserved sectors (optional)

File Allocation Table #1

File Allocation Table #2

Root Directory (FAT12/16 only)

Data Region (for files and directories) … (To end of partition or disk)

Table provided by Wikipedia

A FAT file system, as a Microsoft document explains, is divided into four regions.  Some of these regions exists in predefined disk sectors.

1. The Reserved Region - Boot sector and BPB, located at the very beginning of the partition. It includes an area called the BIOS Parameter Block and can contain the operating system’s boot loader code if the media is formatted to be boot from. It is always the sector 0, the first sector of the volume or partition. -File System Information Sectors (one sector) for FAT32 file systems only, this sector is used to speed up certain disk operations and is located typically at sector 1 (the BPB provides an entry to relocate). -Backup Boot Sector for redundancy at Sector 6.
2. The FAT Region contains the File Allocation Tables. The table are maps of the Data Region, indicating which clusters are used by files and directories. Two tables are support for redundancy. Multiple sectors are allocated for these tables.
3. The Root Directory Region. - contains a  Directory Table that stores information about the files and directories located only in the root directory. It is only used with FAT12 and FAT16. FAT32 stores the root directory table information within the main directory table in the Data Region with all the other files and other directories on the disk.
4. The Data Region - In this area reside the most sectors, these sectors hold the files and directories for the computer system. The directory table exists in this region.

Sectors and Clusters

A disk media is low-level formatted into sectors. Although older drives can be low-level formatted by the user, the currently sold drives are only formatted by the manufacturer before they ship.  Since sectors are at the drive’s physical level, it is independent of the file system. The disk controller, not the file system, knows how to seek sectors and check for sector errors.

After a storage device is high level formatted for a FAT file system, each disk partition is divided up into small contiguous blocks, typically 2 KB - 32 KB in size called clusters.  Clusters are logical blocks understood by the file system. The cluster size is dependent on FAT file system type and not the physical disk. The files system allocate cluster for file storage and locate files by their cluster location. Larger files may occupy many clusters depending on the file size. Since cluster are  not always allocate contiguously for a file, clusters are linked together by a link list data structure forming a cluster chain.

The File Allocation Table (FAT) is a list with an entry for each cluster on the partition. The table entries include information on the cluster such that is it a good cluster, is the cluster unused and available, it also has an entry as a link to the next cluster in the cluster chain or a tag depicting the end cluster in the cluster chain.

Directory Table

A directory table is a file that represents a directory. Each file or child directory stored within a directory is represented by an entry in the table. Each entry contains the name, file attributes, other file parameters, with the address of the first cluster for the file/child directory within the directory. The Directory Tables are stored in the Data Region and hence are file within the FAT file system.

Conclusion

The FAT files system, as most other non-object base systems, is a very tighly coupled to the storage media they serve.  As we have seen, hard coded physical sectors are implemented to store file system data and tables.  Logical clusters are used to chain the actually user data on the storage device allowing for non-contiguous store.  All file attributes (called meta data in object file systems) are stored as an embedded table on the disk which is known only by file system. This approach is very portable when moving a disk drive to a newer computor running the same OS. Since the file system is self contained within the storage device and tightly linked within boot sector, one can typically plug a drive into a system, boot and you are up and running!.  Object base file systems, as we will explore in future posts, create an abstraction layer that may allow for more flexibility in handling file attributes and portablility between different systems. Stay tuned to explore more file systems in future postings!

NOR FLASH

FLASH is a type of Electrical Erasable Programmable Read-Only-Memory (EEPROM). Well, this sounds as a paradox, a Read-Only-Memory that is programmable!

Reading a FLASH device is much the same as reading Typical semiconductor memory such as SRAM or DRAM. Address and control signals are applied to the IC and data is outputted  on the data lines after the access latency time has expired.

When writing a FLASH device, a series of events must execute creating an algorithm to perform the write operation. The operation to write FLASH devices is referred to as erase/program operations. Since writing a word in FLASH involves a multi-step algorithm the name program is a good description. To write FLASH, the first step of the erase/program process is to insure that the target block for th  write is erased. If not then the entire block of data is required to be erased.  This process is executed by  writing several command sequences to the device. As many as six or more command access cycles may be required for an erase.

The next step is to program your data into the memory locations or cells in an erased block of the FLASH device. This step is also done by a several command access cycles, where the last cycle typically applies the write location address onto the address lines and the write data onto the data lines.

FLASH can be programmed on a PROM programmer before it is populated onto the circuit board or programmed  in-circuit while populated on the board using a JTAG port communicating to the uP or by the embedded application executing on the uP itself.

Clearly, reading a FLASH device can be efficient since one cycle is required to access the device, but writing is definitely not efficient.  Even when assuming a block is already erased, multiple step sequences are required to perform a single write operation. It is effective to have your program data variables reside in another memory type which is easily updated. And copy the variables which are only configuration dependent requiring preservation for the next boot into FLASH.

Previous generation FLASH ICs required a high voltage to program the FLASH Memory. Now, FLASH ICs will accept either a high or low voltage for the programming mode. When the high programming voltage is applied, which is easily provided by an external PROM programmer, the programming time is accelerated allowing for efficient pre-programming at a manufacturing facility. The low programming voltage method, a slower programming method, is typically used after the FLASH IC is populated onto the Printed Circuit Board. Thus, reducing the requirement for the circuit board to support a high voltage. Voltage booster power pump circuits are now available to boost a voltage thus allowng for an easy implementation on a circuit card.

Historically, FLASH Programming Algorithms have been proprietary by each manufacturer creating a supply side sourcing problem with second sources.  In production, with an embedded product, one desires to have alternate sources for components. One method to resolve this sourcing issue is to support multiple algorithms within the embedded firmware. Since FLASH devices support a status register which identifies the component by an ID, the ID is used to determine which algorithm to us to access the FLASH. Today, JDEC has helped to standardize the algorithms and data space with the Common Flash Interface specification.

Some previous generation FLASH memories, after power cycling, required the on board microprocessor to  enable and initialize the FLASH IC. Thus, this routine to perform this enable/initialization task must reside in another non-volatile memory which is ready to be accessed at boot time. FLASH today, power up with read access ready-to-go alleviating the requirement to have the FLASH pre-initialized.

Example of NOR FLASH : ST Electronic’s M29W32OD

The M29W320D is a 32 Mbit (4Mb x8 or 2Mb x16) FLASH memory.  This FLASH IC can support all memory operations with a single low voltage (2.7 to 3.6V) supply. These ICs On power-up the memory defaults to its Read mode where it can be read in the same manner as for a ROM or EPROM.

The memory is divided into blocks that can be erased independently so it is possible to preserve valid data while old data is erased. Each block can be protected independently to prevent accidental Program or Erase commands from modifying the memory block.

Program and Erase commands are written to the Command Interface of the memory device. An on-chip Program/Erase Controller simplifies the process of programming or erasing the memory by taking care of all of the special operations that are required to update the memory contents. The end of a program or erase operation can be detected and any error conditions identified.

The command set required to control the memory is consistent with JEDEC standards. The blocks in the memory are asymmetrically arranged. The first or last 64 Kbytes have been divided into four additional blocks. The 16 Kbyte Boot Block can be used for small initialization code to start the microprocessor, the two 8 Kbyte Parameter Blocks can be used for parameter storage and the remaining 32 Kbyte is a small Main Block where the application may be stored. Chip Enable, Output Enable and Write Enable signals control the bus operation of the memory. They allow simple connection to most microprocessors.

FLASH and embedded Systems

FLASH device will continue to provide the back bone for embedded systems. Smaller systems execute directly out of FLASH, using the uP internal SRAM for data variable space. Thus, in these systems FLASH appears to the system as Memory. Larger embedded systems use FLASH as a storage device much in the same manner as a Disk Drive. Here, the uP MMU (Memory Management Unit) pages into main memory files from FLASH. This may be done dynamically but typically all the files are paged into memory after boot time.  In embedded systems using FLASH as a storage device, a file system is required to access files and directories on the FLASH. There are multiple embedded file system available for FLASH. A FLASH fIle systems should support Wear-leveling which is a technique to relocate areas of the FLASH to be used to write data. Since writing an area of FLASH more than 100K  cycles can limit the area’s integrity, Wear-leveling is required.

Rules 11 through 15 of Netrino's list of bug killers for firmware coding include how to deal with global variables and keywords. -By Michael Barr - Embedded.com In last month's column, I shared a set of 10 practical C coding standard rules for embedded software developers to reduce or eliminate bugs in their firmware. This month's installment provides five more such rules. If you only want the new rules, please jump ahead to the heading More Bug-Killing Coding Rules. First, I need to respond to one of the forum threads posted in response. This also gives me a chance to reiterate a key guiding principle behind the Netrino Embedded C Coding Standard.¹ Continue reading...... More bug-killing standards for firmware coding

BURST MODE FLASH

Similarly as synchronous DRAMs migrated to more mature synchronous designs, FLASH technologies also migrated to synchronous technologies. Burst Mode FLASH uses a clock to clock out data synchronously in a burst fashion. The clock is also used to auto increment address counters inside the FLASH IC.

An example of a  Burst Flash device is a Spansion device that can accept an 80 MHz clock (12.5 ns cycle time). The access time for the first word in the sequence is 80 ns. This is even slower than some asynchronous FLASH devices that operate at 70ns. But the access time for the following words in the sequence is 12.5 ns, with this 80 MHz clock. The total time required to access 16 words (32 bytes) of data is: 80 ns + (12.5 ns *15) = 267.5 ns

This yields an improvement of over 16 asynchronous accesses (80 ns * 16 = 1280 ns). In terms of average access time, a 16-word burst has an average access time of 267.5 ns/16 = 16.7 ns

Burst-mode devices allow the system to access data in 8-word, 16-word, 32-word, and continuous sequences.

SIGNALS IMPLEMENTED FOR BURST TIMING

CLK (Clock) The address and data signals are clocked on the rising edge of CLK.
CE# (Chip Enable) CE# is an active-LOW signal. When CE# is LOW the device can be accessed
by the system.
AVD# (Address Valid) AVD# is asserted LOW when the address is valid. AVD# also resets a burst
sequence.
ADR (Address) The address bus is valid when AVD# is LOW.
DQ (Data) The bi-directional data bus that can only be driven by the Flash device
when OE# is LOW.
OE# (Output Enable) OE# enables the output for read accesses.
RDY (Ready) RDY indicates that the data bus is valid. It can be programmed active-LOW
or active-HIGH. RDY is an open-drain signal to allow bussing.

FLASH BURST MODE TIMING

S29WS256N Flash memory device operating with an 80 MHz clock. At this frequency, the Flash device needs to be configured to insert seven wait states. RDY goes HIGH and DQ becomes valid at the seventh clock cycle. The system sets the starting address by asserting AVD# LOW. In addition, RDY becomes active when AVD# is asserted. RDY goes LOW when OE# is asserted LOW and remains LOW for the pre-programmed number of wait states. As long as RDY is LOW the data on DQ [15:0] is not valid. When RDY goes HIGH, the data word is presentedon DQ [15:0] and the internal read address is incremented on each active clock edge.

A sequence is initiated by the Address Valid signal (AVD#) going LOW and latching the starting address on either the next rising clock edge or the rising edge of AVD#. The Flash device automatically increments the address internally on each clock edge. The initial access time in a sequence is the same as the asynchronous access time (tACC). The data following initial word access is accessed on each clock edge, up to the limit of the burst access time (tBACC).

Summary

Burst Mode flash may not achieve better latency when accessing files in an embedded system. But Burst FLASH can achieve much higher thru-put bandwidth. In many embedded systems FLASH is accessed heaviest at boot up, loading the FLASH image into main memory. For applications which require faster boot up, Burst FLASH can help you achieve this goal. Also, if your design accesses the FLASH file system heavily during run time to directly access files or to load them into memory, burst FLASH can help you gain a performance advantage.

SOAP and acronym for Simple Object Access Protocol, is a communication protocol to communicate between applications ans services by sending formatted messages based on XML via the internet using http.  Since SOAP implements XML and http, communications are platform and language independent. The entrench protocol for communication between applications is the Remote Procedure Call (RPC).  RPC typically uses a distributed object communication protocol as DCOM or DSCOM to communicate between network objects. Some major issues with DCOM and DSCOM are traffic blocking at network firewalls and security vulnerabilities. Soap can be viewed as a transport for RPC.

As embedded systems are becoming more Internet enabled they are providing newer, broader and interesting services.  Systems are required to communicate in a structured and reliable way utilizing standardize technologies with reuse.  SOAP is one technology. Understanding SOAP requires an understanding of XML. So consider starting  with my  Soap Part I - First an Introduction to XML to SOAP.

The two  basic communication protocol mechanisms for communicating between services or applications are message passing and the request-response model.

The message passing mechanism assumes the receiving side implements queuing  allowing a sender or multiple senders to send messages at any time. The sender side must handle the ordering of returned response messages since response messages from different application or different remote locations may return in a different order than which they were requested. Hence message passing is very efficient for multi-process applications  or concurrent applications for  certain inter-processing communications.

The request/response mechanism blocks the communication precession by the sender waiting for the communication completions of request-response pairs.  The request-response is better suited  for single-process application, that must wait (blocking) for a response to continue and initiate the next communication pair.  This makes request/response communications a natural fit for RPC applications.  A messaging passing system mechanism can be built using a lower-level request-response protocol to achieve appropriate results.

Since an administer controls the configuration and environment within a server farm it is common practice to use DCOM or CORBA/DSCOM. Security, fire-wall friendly, and interoperability is achieved by the tightly coupled environment by a single administrator where  the servers co-reside. What is the better communication protocol or client to server or server to remote server for RPCs communications?  It would need to be a  protocol that handles interoperability for security, supporting a request-response mechanism, and is supported easily by most clients and servers.  HTTP is a very RPC-like protocol that is the most ubiquitous protocol seen on the internet, it is widely deployed, it uses HTTP request-response communications mechanism over a TCP/IP  connection, it is firewall manageable and implements a proven security method (HTTPS).  HTTP requests are handled by all web servers and many application servers are also supporting HTTP as a native protocol.

An HTTP client connects to an HTTP server using TCP. The standard port number used in HTTP is port 80. After establishing the TCP/IP connection, a server or client can send an HTTP request message to the server. Following the request, the server then sends an HTTP response message back to the client after processing the request. Both the request and response messages can contain arbitrary payload information. As you may be already thinking, this payload could be in XML format.

Now let’s look into the HTTP header of a simple web page request from a browser.

GET /indexservices HTTP/1.1
Host: www.vasmac.com
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
Accept-Language: Fr
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
Connection: Keep-Alive

Now let’s look into depth the HTTP header for a POST request which us used for RPCs.

POST /post.php HTTP/1.1
HOST: server.vasmac.com
Content-Type: text/plain
Content-Length: 11
Connection: Keep-Alive

The Payload

Since HTTP headers are just plain text, it is easy to resolve HTTP problems using a packet sniffer such as Wire Shark, ease of portability between systems and platforms.

The first line of an HTTP request contains three parameters: the HTTP method, the requesting URI, and the HTTP version.  The second line contains the requesting URL. The third and fourth lines specify the size and type of the request payload. The Content-Type identifier specifies the MIME type of the payload. The Content-Length identifier specifies the number of bytes in the payload.  The connection is kept alive for more transfers. The HTTP  payload is delimited by a carriage return/line feed.

The HTTP server then sends an HTTP response back to the requesting client. The response contains a status code for the request. The following is an HTTP response message for the second example

200 OK
Content-Type: text/plain
Content-Length: 0

Since HTTP provides the connection management, framing, and transmission status it can serve as a good RPC protocol. The next step is to figure out what is a good HTTP Payload format or protocol. In DCOM, the payload format known as Network Data Representation (NDR). In object RPC systems Common Data Representation (CDR) format is implemented. Since XML is standard format and almost as ambiguous as HTTP, it is a good choice as a data format. Thus, XML allows data to be serialized into a transmissible form that is easily decoded on any platform. Consider reviewing XML Name Space and Schema in the post “Soap Part I - First an Introduction to XML“.

SOAP uses of XML as an encoding format for request and response parameters using HTTP as a transport. A SOAP method is simply an HTTP request and response that complies with the SOAP encoding rules.  A SOAP endpoint is simply an HTTP-based URL that identifies a target method.

A SOAP request is simply an HTTP POST request. Since SOAP uses XML as the data format, the requests must use the text/xml content-type. the HTTP Request-URI many be used by implementations to map to an object. A SOAP HTTP request must indicate the desired application-specific invoking method using the SOAPMethodName within the HTTP header.

POST /objectURI HTTP/1.1
Host: www.storeserver.com
SOAPMethodName: urn:onlineshoppingSW-com:IStore#getBalance
Content-Type: text/xml
Content-Length: 100

This HTTP header indicates that the getBalance method which is scoped by the URI urn:onlineshoppinSW-com:IStore should be invoked against the endpoint identified http://www.storeserver.com/objectURI.

The HTTP payload of a SOAP request is an document in XML format (data structure) that contains the information needed to invoke the request. To request your balance from a store the HTTP payload of the request is shown below:

<?xml version='1.0'?>
<SOAP:Envelope
  xmlns:SOAP='urn:schemasxmlsoap.org:soap.v1'>
 <SOAP:Body>
  <p:getBalance
    xmlns:p='urn:onlineshoppingSW-com:IStore'>
   <account>005688</account>
  </p:getBalance>
 </SOAP:Body>
</SOAP:Envelope>

Once the server-side method has executed, an HTTP response message with the method result will be returned. The HTTP payload result is contained an XML formatted document. The results are contained as the values in elements.  the response for the request above is shown below a the value for the element “amount”.:

200 OK
Content-Type: text/xml
Content-Length: xxxx

<?xml version='1.0'?>
<SOAP:Envelope
   xmlns:SOAP='urn:schemasxmlsoap-org:soap.v1'>
 <SOAP:Body>
  <q:getBalanceResponse
     xmlns:i='urn:onlineshoppingSW-com:IStore'>
   <amount>45.21</amount>
  </q:getBalanceResponse>
 </SOAP:Body>
</SOAP:Envelope>

In review, SOAP endpoints are URLs, SOAP methods are a pair of XML element declarations identified by a namespace URI and an NCName.

SOAP is a typed serialization format for RPCs that is implemented with HTTP as a request/response messaging transport and XML as a payload data format. SOAP was designed to work well with the XML Schema specification. Since HTTP and XML are ubiquitous and standardized, SOAP will inter operate in a secure and reliable manner on most all platforms and environments.