Embedded system engineering magazine 2006.01,02

</Feature>

ESE Magazine Jan/Feb 06

46

Continuous time delta sigma ADCs

<Written by> Heribert Geib, Xignal Technologies AG </W>

Continuous time delta sigma analog-to-digital converters provide new design opportunities.

UNTIL NOW, designers have with a trade-off in their selection log-to-digital converters (ADCs) converters offer high resolution

dynamic range but at the expense of power consumption. Discrete time converters don’t need nearly as much are severely limited in terms of speed. uous time delta sigma (CTΔΣ) technology oped by Xignal bridges the gap and

announced products operate at 40 MSPS (equivalent to 50-60 MSPS in pipeline parts), 12 or 14-bits of resolution, high levels of functional integration including an accurate on-chip clock source, and all this with a power consumption of just 70mW. An added advantage of the technology is a resistive input stage that’s easy to drive without resorting to power-hungry buffer amplifiers. Figure 1 shows the relative performance of these ADCs compared with pipeline converters based on the IEEE’s accepted measurement of Figure of Merit (FOM). FOM is a measure of the energy per conversion. It also shows that as process architectures scale in the future, continuous time delta sigma devices will follow the roadmap to deliver higher levels of performance. Figure 2 looks at a complete analog-

Figure 1: ADC conversion power efficiency comparison

Figure 2: Integrating the signal path – enabled by CTΔΣ ADC technology.

sigma implementation removes the need for antialias filtering and the input driver, and Xignal’s implementation of the technology integrates all of the other functions on-chip. The generic benefits of CTΔΣ conversion are clear: faster and simpler system design, lower power consumption, and no compromise in dynamic range or speed. In multichannel applications these benefits are multiplied and can enable designers to adopt new and beneficial system architectures that were not previously possible. Potential applications for the technology are widespread in all sectors of the electronics industry, particularly where analog signals derived from various types of sensors need to be converted to digital signals in a power-efficient manner. Medical ultrasound is just one of these applications.

performance systems with up to 256 channels and portable systems up to 128.

Prior to the development of CDTS technology analog front-ends the pipeline ADCs consumed anything up to 0.5 Watt for each channel. That's 64 Watts for a mid-range (128 channel) system with enough heat being generated to affect the performance of the transducer head and cause significant discomfort to both patient and doctor. By contrast, the CTΔΣ solution in the same system would consume just 8.75 Watts or even less by using a multichannel ADC device sharing some resources like the PLL across multiple channels. With an 8-chan-

Figure 3: xxxx

www.xignal.com

</Feature>

ESE Magazine Jan/Feb 06

48

Flash storage solutions for microcontrollers

<Written by> Dave Hughes, HCC-Embedded </W>

Flash memory provides many advantages, but designers need to take care to extract these benefits.

IN RECENT YEARS flash based microcontrollers have flooded the market all the major players – they are now the norm rather than the exception.

Additionally the arrival of ever larger serial flash devices with small erasable sectors has given the possibility of extending the storage capabilities of micros without the requirement for additional resources.

Many new applications immediately suggest themselves, such as field customisation, field upgrades, dynamic configuration files, data logging, diagnostics and more.

But can this flash be used as more than a masked ROM substitute? Can the flash be used reliably for these new applications? We are paying for the more sophisticated flash solution – but how do we extract the benefits?

broken then the results in the page are unpredictable and it is necessary to be sure whether a page is valid or not.

●Power Management – all flash is sensitive to unstable voltages – if the power drops below the specified level then erase and write operations will have unpredictable results.

It is this collection of characteristics on flash devices which creates the challenge – how to use this flash reliably?

Use a file system

These problems are quite complex to address and there are different rules for every flash device type which have to be taken in to consideration in any design. One method to hide all this complexity from the developer is to use a

from the designer they are free to focus on their core competences.

Connecting to a host

The “standard route” for connecting embedded file systems to a host system would be to add a USB Mass Storage interface and a FAT file system but there are some disadvantages to this approach for embedded systems developers. As the FAT file system is not fail safe there needs to be a check disk available. While this acceptable when a device is connected to the PC, what happens when it is in the field? FAT is space hungry, requiring a minimum of 20K disk space before storing data, which can be a significant overhead for many flash micros. When the host accesses the file system the target must stop access and vice versa, as either system can modify the FAT

But can flash be used as more than a masked ROM substitute? Can it be used reliably for new applications? We are paying for the more sophisticated flash solution – but how do we extract the benefits?

Figure 1: uCDrive.

and erase operations – if a write or erase is

</Standards>

ESE Magazine Jan/Feb 06

A Standard individual:

Engineering Standard, Marketing Release or both?

<Written by> Chris Hills </W>

THIS MONTH I am going back to the root of the colStandards. First a quick round up of where MISRA at. The MISRA-C group has started on the example suite. It is progressing well and we hope to have it

finished for the end of 06. Maybe for ESS06. We are also working on the Technical Corrigendum and by implication MISRA-C. I think we suggested we should have MISRA-C:2009.

The MISRA-C++ team is having fun. They have assembled a team and are sorting out terms of reference in parallel with gathering source material and there is a lot of source material. Interestingly they tell me that most of the C++ subsets and coding standards they have seen have a lot in common. There is also the C++ coding standard from the Joint Strike Fighter project in the US called JSF++, which is “secret” and can only be seen by Security Cleared US Nationals.

The MISRA Autocode is progressing well. The effort is being well supported with a good number of European OEMs and Tier 1s along with a smaller involvement from the USA. The European support is quite wide and not just the German automotive industry as was feared by some. I did enquire about first drafts for review and “mid 06” was vaguely suggested which means it will probably be Christmas 06.

A less well-known MISRA standard is the Software Readiness for Production guide. Sources in MIRA say this document will be published in February 2006.

MISRA Safety Analysis - this gives guidance on the management of functional safety for IEC 61508 lifecycle will be published mid 2006. So MISRA is doing a lot.

New versions of C?

Having covered the MISRA guides it is time to look at the other standards. Now things get vague. For some reason the C panels seem to have veered away from the industry. The industry, compiler writers and others like MISRA have stopped at C 1990 with the amendments up to 1993/4. A part of the standards development process is the publication of Technical Reports. These are exactly what they say and are NOT part of the

Standard though often they form the basis of work that does get into the next version where appropriate. Two that have come through are the Microsoft C and C++ “Safe” Libraries and these may have long term consequences for the future of C.

There is also provision for ECMA the European Computer Manufacturers Association to fast track completed standards to the final stage of ISO voting. Among those that have come through are a standard for C# and for C++/CLI (Common Language Interface). This last actually extends C++ by adding a couple of dozen key words and changing the way some constructs work, which appear to be based on Microsoft implementations and extensions to C++. If these get passed along with the two libraries in the TRs for C, then it appears to me as though MS C, C# & C++ will be the standard, and the Microsoft platform will be the only one that conforms to the ISO standards. I hope I am misunderstanding this.

Ethics

Finally I should like to bring to your attention an item from an IEEE newsletter. It said that: Universities no longer assume that the new engineer will learn ethical practices on the job and are now offering instruction on the subject. The IEEE is also playing a role in highlighting ethical practices by promoting students' awareness of their professional responsibilities as engineers. Find out more at http://boldfish.ieee.org:80/u/1353/41449924

I wonder if they will cover Standards in their ethics classes or if they will run correspondence classes for busy engineers in other parts of the country…

I had a quite a response from last months column! Thanks to all who emailed me, I intend to revisit the subject in a future column. I have received the first notifications of ESS 06. I will be there. Will you? 11 & 12th October at the NEC Birmingham. Stick it in the diary. <End/>

These are not in any way an official statement or committee view, but my own personal views and those of my company PhaedruS SystemS. www.phaedsys.org which is where the full version of this column resides under the Technical Papers button. Any comments, praise or legal documents to [e-mail].

	Optimising	Hardware	The Leader in Embedded
		Debug	Software Development
	Compilers
		Probes
			FREE 30-Day Product Evaluation
	Integrated	Real-Time	register now at www.ghs.com/eval
	Development	Operating
	Environments	Systems
	Debugging &	All	Tel: [phone]
	Performance	Royalty	Fax: [phone]
	Analysis	Free!	Email: [e-mail]