Accelerometer | ADC | ADXL | Adxl20 | AVR | BasicStamp | BX-35 | BX28 | BX35 | COM3 | Compiler | Downloader | EEPROM | Electromagnet | GetADC | GP2D1 | GPS | I2C | IDE | Keypad | LCD | LCD+ | MIDI | Motors | Multitasking | Netmedia | Networking | PCB | PID | PlaySound | PWM | Relays | RTC | Servo | ShiftOut | SitePlayer | SPI | Stack | Timer | USB

How do you usually go about storing singles?

For efficiency reasons, I'd like to store floating point numbers,
generated by a bx24 and streamed back to my laptop, in a text file that
contains 4 bytes per single...not as many bytes as there are digits:)

You all know how it goes:
And example is 123, which takes 3 string characters to store (asc
("1") & asc("2") & asc("3")), but really only one decimal byte--an
ascii character with a value 123 (chr(123)).

For a random number, like 56789.1234, there will be a similar 32-bit
value, which is 4 ascii characters, not 10 string characters (asc("5")
& asc("6") & ... yuck)

What's the best way to store singles as 4 ascii bytes? I'm sure the
bx language has something efficient. There must be some trick to doing
this with clever type conversions, mid functions, etc.



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "pjc309430" <pjc30943@i...> wrote:
> What's the best way to store singles as 4 ascii bytes? I'm sure
the
> bx language has something efficient. There must be some trick to
doing
> this with clever type conversions, mid functions, etc. Well, I have not tried this exact problem... but.

The idea is to get the address of the starting byte of the 4 byte
variable. Then read the memory byte by byte. You would use VarPtr()
to get the starting address. Then use RamPeek() to get the
sequential byte values.

I forget in what byte order the single is stored: high end first or
low end first. You can try it both ways and see what you get.

I also forget the details of the mantissa and exponent sizes. 2
Bytes each? 3 and 1? It would be "easy" to tell that by storing
1, 10, and 100 as the value and then seeing what changes.

You might need to know these details to reconstruct the actual
values at the receiving end.

Fixed point numbers using longs might be slightly easier to
manipulate, but the details of reading out the bytes is the same.

-Tony





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
> I forget in what byte order the single is stored: high end first or
> low end first.

BasicX is "little-endian", primarily because the AVR, on which it is
based, is also. This means, of course, that the bytes of a multi-byte
value are stored in memory with the less significant bytes at lower
addresses in memory.

> I also forget the details of the mantissa and exponent sizes. 2
> Bytes each? 3 and 1? It would be "easy" to tell that by storing
> 1, 10, and 100 as the value and then seeing what changes.

See this and other references:
http://www.psc.edu/general/software/packages/ieee/ieee.html

Don





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "pjc309430" <pjc30943@i...> wrote:
> What's the best way to store singles as 4 ascii bytes?

Assuming that you want a string having four "characters" that are
actually the 4 bytes of a 32-bit Single, try this:

Dim f as Single

Sub Main()
f = 3.14159
Dim fs as String * 4
Call BlockMove(4, MemAddress(f), MemAddress(fs) + 2)
End Sub

This will result in the fixed-length string having the hexadecimal
character codes:
D0 0F 49 40

The 32-bit IEEE representation of 3.14159 is &H40490FD0.

You could do the same with a "normal" String variable but you'd also
have to set the string length (byte 0).

That said, if what you're trying to do is get the four bytes of the
Single into the output queue, just use this:

Call PutQueue(outQueue, f, 4)

The receiver will get the 32-bit Single in little endian form. If
it uses big endian form, you'll have to reverse the order on one end
or the other.

One other issue you'll have to consider is whether your receiver
uses 32-bit or 64-bit floating point representation.

Don





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Thanks Don for the suggestions. This is exactly what is needed.

> One other issue you'll have to consider is whether your receiver
> uses 32-bit or 64-bit floating point representation.

I'll be both writing to a file, and reading back with the bx, so it
will be consistent... > Dim f as Single
>
> Sub Main()
> f = 3.14159
> Dim fs as String * 4
> Call BlockMove(4, MemAddress(f), MemAddress(fs) + 2)
> End Sub Why is the +2 required? > This will result in the fixed-length string having the hexadecimal
> character codes:
> D0 0F 49 40
>
> The 32-bit IEEE representation of 3.14159 is &H40490FD0.
>
> You could do the same with a "normal" String variable but you'd
also
> have to set the string length (byte 0).

What about a normal, boundedString variable? I was under the
impression that they automatically size the string, and internally
keep track of the pointers and size. They always hold the RAM
hostage, though (I think).



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> Why is the +2 required?

Oh wait, never mind:) String overhead... Blockmove works great. Thanks! Now if only I would noticed the
function, because the example in the docs use it for exactly such
converstion logistics...





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "pjc309430" <pjc30943@i...> wrote:
>> Why is the +2 required?
> Oh wait, never mind:) String overhead...

Exactly. The first byte of string storage gives the current length
of the string. For a fixed-length string as I used in the example,
it will never be changed by BasicX. For a regular string and a
bounded string, it will change depending on the length. If you want
to manipulate strings, you can (carefully) adjust the length as you
see fit.

The second byte of string storage gives the string type - 00 for
regular and bounded strings, FF for fixed-length. The remainder of
the string storage space is for the string's characters.

Note that there is no indication of how much space has been reserved
for the string (except for fixed-length strings as described
earlier). That is why your program can go awry if you assign a
string value with too many characters - it ends up writing over
adjacent memory.

Don




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )