Hello!
For better explanation of bug #2561038 I've raised a question about
TextBuffer insight in SAF.
Interpretation is below.
So, hpi_shell as HPI user application shall not pack/unpack BCD+/ASCII6
data from/to SaHpiBufferT. The data shall be already presented as ASCII8.
Anton Pak
---------------------------- Original Message ----------------------------
Subject: RE: [twg-hardwareplatform] Question about SaHpiTextBufferT (BCD+
and ASCII6)
From: "David McKinley"
Date: Wed, February 4, 2009 2:03 pm
To: [email protected]
--------------------------------------------------------------------------
Anton,
You are correct in your understanding. The reason for the
identification of the data types was basically because IPMI would
identify data that way. Of course in IPMI, it also meant that the data
would be encoded as packed 4-bit or packed 6-bit characters. We wanted
the HPI interface to be easier for users to deal with, so we said HPI
should do the unpacking of the IPMI data into normal 8-bit bytes.
But, when a saHpiTextBufferT is used to write data - like in
saHpiControlSet() for a text control, or in saHpiIdrFieldSet() for
inventory data, the restriction on character sets is important, because
the HPI implementation may need to do a re-packing of the 8-bit
characters into 6-bit or 4-bit packed data to store in the actual
hardware device. Thus, we keep the data tagged as to whether it is
6-bit or 4-bit data so the user will know what character set is valid
for updating, if needed.
David
> -----Original Message-----
> From: Anton Pak
> Sent: Wednesday, February 04, 2009 11:20 AM
> To: [email protected]
> Subject: [twg-hardwareplatform] Question about
> SaHpiTextBufferT (BCD+ and ASCII6)
>
> Hello!
>
> Comment from SaHpi.h says:
>
> ** Note 2: The SAHPI_TL_TYPE_BCDPLUS and SAHPI_TL_TYPE_ASCII6
> encodings use normal ASCII character encodings, but restrict
> the allowed characters to a subset of the entire ASCII
> character set. These encodings are used when the target
> device contains restrictions on which characters it can store
> or display. SAHPI_TL_TYPE_BCDPLUS data may be stored
> externally as 4-bit values, and
> SAHPI_TL_TYPE_ASCII6 may be stored externally as 6-bit values.
> But, regardless of how the data is stored externally, it is
> encoded as 8-bit ASCII in the SaHpiTextBufferT structure
> passed across the HPI.
>
> So, my understanding is:
>
> BCD+ and ASCII6 data are just ASCII8 data.
> SaHpiTextBufferT with DataType = SAHPI_TL_TYPE_BCDPLUS does
> not contain BCD+ data packed into 4 bits per character.
> It only contains a characters( 1 byte - 1 character) from
> susbset of ASCII8.
>
> Am I right? If yes, what were the historical reasons for that
> design topic?
>
> Anton Pak
>
------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
