NIOS and ftoa()
in [Embedded]
|
From: Mark Borgerson on 19 Nov 2009 10:35 In article <008e1700$0$26888$c3e8da3(a)news.astraweb.com>, cfbsoftware(a)hotmail.com says... > "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 > If the data being sent out starts as a 16-bit binary value from a sensor, you might be able to skip all the floating point math when sending the data: If the processor has decimal addition instructions, this problem could be broken down into a combination of table lookups and decimal additions. For a 16-bit binary value, set up four tables of 16 entries, each with the BCD value corresponding to the decimal weights within that particular nybble. Start with the most significant nybble, and add up the BCD values for each of the subsequent table entries for the other nybbles: unsigned int data; BCDValue = TableHH[data >> 12]; BCDAdd(&BCDValue, &TableHL[(data >> 8) & 0x0007]); BCDAdd(&BCDValue, &TableLH[(data 4) & 0x0007]); BCDAdd(&BCDValue, &TableLL[data & 0x0007]); After these steps, BCDValue should have the appropriate binary-coded decimal value and conversion to a string is simply a matter of adding the 0x30 character offset and inserting a decimal point at the appropriate place while sending the string. If the data varies slowly, you could optimize the heck out of this algorithm, by caching the last weights of the upper nybbles and only doing the addition for the lowest nybble. Setting up the tables would be a one-time operation based on the required decimal precision and the calibration coefficients for the sensor. You could also modify this approach to use a single 16-entry table where each entry is the BCD weight corresponding to that bit in the input data. If the input data is well distributed over the 16-bit space, you will do 16 bit tests and about 8 BCD additions for each output. This is all 7AM pre-caffeine pseudocode, so there is no guarantee that the algorithm is either correct or suitable for the OPs problem. Mark Borgerson
From: Marc Jet on 19 Nov 2009 12:02 don ha escrito: > Thats 320Kbits or 480Kbits per second. > > Will USB CDC handle this data rate (with all the overhead) ? Sure. Those HSDPA 3G mobile internet sticks are CDC, and promise rates up to 3,6 mbps.
From: don on 19 Nov 2009 14:31
Marc Jet wrote: > don ha escrito: >> Thats 320Kbits or 480Kbits per second. >> >> Will USB CDC handle this data rate (with all the overhead) ? > > Sure. Those HSDPA 3G mobile internet sticks are CDC, and promise > rates up to 3,6 mbps. From http://www.wireless.att.com/learn/why/technology/3g-umts.jsp Disclaimer: Referenced speeds require an HSDPA 3.6Mbps / HSUPA capable device with Receive Diversity and/or Equalizer. BroadbandConnect speed claims based on our network tests without compression using 3MB data files. 3G devices not enabled with HSUPA support typical upload speeds of 220-320kbps based on our network tests without compression using 500KB data files for upload. Actual throughput speed varies. I did not see where the OP was using HSDPA !!?? don |