NIOS and ftoa()
in [Embedded]
|
From: David Brown on 18 Nov 2009 15:13 John Speth wrote: > Hi folks- > > I'm in the beginning stages of crafting a high-speed measurement device > which needs to output a floating point value in ASCII string form that > represents the measurement at a rate of 10 kHz. I'm using an Altera FPGA > that runs Nios2. Convenient standard library functions like sprintf() or > ftoa() running as code will be too time-consuming to meet my high throughput > requirements. What I need is an ultrafast float to ASCII conversion > function that can run in code *or* a strategy for implementing a conversion > function in HDL. Altera has a nice tool called C to HDL compiler which I'm > looking at now. > > It seems to me that a fast float to ASCII conversion function would be a > common function of many embedded systems. Rather than me reinventing the > wheel, can anyone point me to a resource (example on the web or a product > for sale) that I can use to achieve my goal? > > Thanks, John Speth. > This is roughly what the others are saying, but in different words. First convert your values into scaled integers of some sort. Then convert these to ASCII - that's just a series of divide-by-ten calculations, and a little care where you put your decimal point and zeros. Also make sure you are using a Nios with fast division, and consider building it with hardware floating point support (though it is better if you can avoid floating point entirely, and stick to scaled integers). Don't bother trying to make hardware (either manually or with C to HDL) to support the entire conversion function. But it might be worth making a special instruction (or C to HDL conversion) for the inner loop.
From: D Yuniskis on 18 Nov 2009 15:59 Grant Edwards wrote: > On 2009-11-18, D Yuniskis <not.going.to.be(a)seen.com> wrote: >> John Speth wrote: >>> I'm in the beginning stages of crafting a high-speed measurement device >>> which needs to output a floating point value in ASCII string form that >>> represents the measurement at a rate of 10 kHz. I'm using an Altera FPGA >>> that runs Nios2. Convenient standard library functions like sprintf() or >>> ftoa() running as code will be too time-consuming to meet my high throughput >>> requirements. What I need is an ultrafast float to ASCII conversion >>> function that can run in code *or* a strategy for implementing a conversion >>> function in HDL. Altera has a nice tool called C to HDL compiler which I'm >>> looking at now. >> What is the source of your data? Surely (?) your "sensor" >> isn't generating floating point data?? > > Even if it is generating floating point (we'll assume IEEE 754 > format), just output the IEEE fp value in binary (or ASCII-hex) > rather than attempting to convert it to base-10 floating point > in ASCII. I assume he knows what he needs (too often, we spend a lot of time with "Why do you want *that*?" instead of just assuming the OP is smart enough -- ? -- to *know* that he truly needs what he is asking for). While it is likely (?) that the device on the other end of his "measurement device" *probably* will convert that ASCII string back into some sort of "numeric" representation (perhaps even floating point!), there is no guarantee that this is the case. E.g., the device on the other end may be nothing more than a data logger that takes the ASCII and records it on some medium. Or, the device might *expect* data in this ASCII format. I am increasingly moving away from "binary" formats to things like ASCII strings because it is so much more portable. When you have to interface lots of heterogeneous systems, its just easier to pick *a* standard interchange format and live with that throughout than to have to deal with various idiosyncrasies of each individual device. E.g., does the FP implementation support subnormal/denormalized values? what range of exponents are supported? does it support signed zeros? It is a big or little Endian representation, etc. Granted, this is a performance hit, often (not always). But, *FOR ME* it seems to be a worthwhile tradeoff (vs. adding complexity to devices so they know about each *other's* characteristics. I have little PIC-based sensor/control devices that emit/accept ASCII commands instead of pushing "proprietary bits" to/from them. So far, it has worked quite well (also makes debugging a multiprocessor system considerably harder when you can just *read* messages as text -- instead of having to "decode them" :> ) >> I.e., can you deal with the data in some other form that is >> more readily converted to ASCII? (e.g., if you have to >> manipulate the data somehow before "output", use decimal math >> -- this is trivial to implement unless you start getting into >> the transcendental functions, etc.) >> >>> It seems to me that a fast float to ASCII conversion function >>> would be a common function of many embedded systems. > > Nope. Reduce/process/buffer the data _then_ convert it to > human-readible ASCII form. I was advocating a middle-ground; get the data into a form that is *relatively* easy to process (decimal) and *much* easier to convert to that human readable form at the end. E.g., there are times I will resort to using decimal counters in a piece of hardware (vs. binary counters) as it can eliminate the overhead of doing the conversion (in software) at the expense of a few gates in the feedback paths to the various stages of the counters. >>> Rather than me reinventing the wheel, can anyone point me to a >>> resource (example on the web or a product for sale) that I can >>> use to achieve my goal
From: John Speth on 18 Nov 2009 17:43 (I'm to OP) Thanks for all the good suggestions that have come forth so far. Some will be useful and some won't be. I can envision considerable execution savings if I use some sort of fixed point math and special-purpose custom formatting instead of using the standard C library functions and built in floating-point math. I'll try to further explain my application: As another respondent mentioned, we require ASCII because of its portability, simplicity in decoding, and immediate readability with simple tools (like hyperterminal). The sensor will communicate via USB CDC to a PC. While the PC will be swamped with continuous 10 kHz measurement transmission, we will typically see finite bursts of measurement transmissions, which is manageable. But we've need to be prepared to handle the extreme case in which the burst length may be functionally infinite (continuous 10 kHz). John Speth "John Speth" <johnspeth(a)yahoo.com> wrote in message news:he1ad9$bm2$1(a)adenine.netfront.net... > Hi folks- > > I'm in the beginning stages of crafting a high-speed measurement device > which needs to output a floating point value in ASCII string form that > represents the measurement at a rate of 10 kHz. I'm using an Altera FPGA > that runs Nios2. Convenient standard library functions like sprintf() or > ftoa() running as code will be too time-consuming to meet my high > throughput > requirements. What I need is an ultrafast float to ASCII conversion > function that can run in code *or* a strategy for implementing a > conversion > function in HDL. Altera has a nice tool called C to HDL compiler which > I'm > looking at now. > > It seems to me that a fast float to ASCII conversion function would be a > common function of many embedded systems. Rather than me reinventing the > wheel, can anyone point me to a resource (example on the web or a product > for sale) that I can use to achieve my goal? > > Thanks, John Speth. > > >
From: Chris Burrows on 18 Nov 2009 19:34 "John Speth" <johnspeth(a)yahoo.com> wrote in message news:he1ta9$1852$1(a)adenine.netfront.net... > (I'm to OP) > > Thanks for all the good suggestions that have come forth so far. Some > will be useful and some won't be. I can envision considerable execution > savings if I use some sort of fixed point math and special-purpose custom > formatting instead of using the standard C library functions and built in > floating-point math. > Niklaus Wirth recently wrote "A Note on Division" describing strategies for implementing integer and real division on processors which lack a division instruction. While not providing a complete solution to your problem the ideas might contribute towards one. The article can be downloaded from: http://www.inf.ethz.ch/personal/wirth/Articles/Miscellaneous/index.html -- Chris Burrows CFB Software Armaide: ARM Oberon-07 Development System http://www.armaide.com
From: Hans-Bernhard Bröker on 19 Nov 2009 09:34 John Speth wrote: > As another respondent mentioned, we require ASCII because of its > portability, simplicity in decoding, and immediate readability with simple > tools (like hyperterminal). So use hexadecimal ASCII floating point format (C99 *printf("%a",...) style) It's ASCII, standardized, human-readable of sorts, and way faster to construct than decimal. > The sensor will communicate via USB CDC to a > PC. While the PC will be swamped with continuous 10 kHz measurement > transmission, Sorry, but that makes no sense at all. To what limited extent it's even possible to "swamp" a current PC with 10000 data records per second, the only effect coding FP data to decimal and back can possibly have on that problem is making it _worse_. ASCII decimal notation consumes both more CPU power on both ends, and more bandwidth on the way. It's completely wasteful. >> It seems to me that a fast float to ASCII conversion function would be a >> common function of many embedded systems. I would think that the most common function of this sort in embedded systems is "don't do it", closely followed by "if you really have to, at least do it on the high CPU power side of things".
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Compact Flash IDE PIO Write Size Issues Next: Possible Solution |