|
|
|
|
|
|
|
|
| Re: Modeling to the bit level [message #529703 is a reply to message #529699] |
Mon, 26 April 2010 19:57   |
 Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Herb,
Comments below.
Herb Miller wrote:
> Here is the whole thing in a nutshell.
>
> The radio operator can initialize the radio by loading in a file with
> the correctly formatted set of 16-bit shorts.
So this comes down to needing a particular serialization format. It
doesn't sound like the file is XML...
>
> However, the operator may need to change a bit field, or even 1 bit,
> so GUIs will have to be provided for each separate cohesive piece of
> data whether it be a whole word, a part of a word or even 1 bit of a
> word (when I say word I mean 16-bit short).
>
> After making changes, the operator may want to save the changes made
> in a new file.
>
> I was hoping to model the bit fields and bits with EMF, generate, then
> got to RCP and all of the GUIs and model data would be generated
> (including serialization).
The serialization sounds highly custom, i.e., it doesn't sound like it's
XML, but I could be wrong about that. Can you show an example of the
serialization?
>
> From what I have gleaned so far, the serialization will have to be
> customized.
It sounds that way.
>
> Does this help?
If you show me the details of the serialization can can likely better
suggest the best approach for customization.
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: Modeling to the bit level [message #529720 is a reply to message #529712] |
Mon, 26 April 2010 22:37 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Herb,
You could specialize ResourceImpl's doLoad and doSave to read and write
your specialized format. I think you'd model many boolean fields, and
perhaps some enums. You'd encode/decode these to/from your specialized
format.
Herb Miller wrote:
> You are so right. The data in the file is definitely NOT XML. It is
> a list (64 to be exact) of 16-bit words, so serialization is
> definitely custom.
>
> It sounds like I will have to serialize the bit fields and bit values
> into EMF objects when reading the file, and convert EMF objects into
> the file format when writing the file, correct?
>
> The details of the serialization are similar to what I sent before
> with the example of the 16-bit short being converted into many
> fields. Some bit fields are 24-bits in length which would be 1 16-bit
> short plus a byte from the next 16-bit short.
>
> Thanks.
>
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
|
| Re: Modeling to the bit level [message #622490 is a reply to message #529114] |
Fri, 23 April 2010 13:10 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Eike,
Yes, that's what I was going to suggest too. The basic premise is that,
if you can do it by hand, you can do it with EMF as well, so most
certainly it's possible to define an EDataType that's an array of short.
Eike Stepper wrote:
> Hi Herb,
>
> Maybe it helps to model your data as a custom EDataType. Then you can
> write your own serialization logic in the generated createFromString()
> and convertToString() methods of the package factory.
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Am 22.04.2010 22:13, schrieb Herb Miller:
>> The encoding is necessary because it represents data in a file that
>> is passed to a radio in order to control different functions of the
>> radio. The bits have to be the right value and in the correct
>> position in order for the radio to function.
>>
>> The radio has an internal buffer that the 64 16-bit words map
>> directly into.
>>
>> Too bad. I would love to have been able to use EMF for that kind of
>> a model.
>>
>> Thanks.
>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: Modeling to the bit level [message #622500 is a reply to message #529644] |
Mon, 26 April 2010 16:08 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Herb,
Comments below.
Herb Miller wrote:
> The EDataType sounds like a definite possibility. I figured something
> special would have to be added for serialization.
>
> i am still not too clear on how to model the bit fields.
I suppose it's not entirely clear either where you need this particular
16-bit short representation. Of course it's always possible to convert
between representations, so you might just model a series boolean
features and write some to code covert them to another representation or
to set them based on that other representation. These might be just
convenience methods.
>
> Let's say the 1st 16-bit short has these bit fields:
>
> Bits 0- 3 = frequency selection
> Bits 4- 6 = interference algorithm
> Bits 7- 9 = power amp level
> Bits 10-13 = noise setting
> Bit 14 = squelch on/off
> Bit 15 = error log on/off
>
> Are you all suggesting I model each of those bit fields as some other
> value, say an integer. Then EMF would generate some representation
> for each of these fields or bits that represent an individual piece of
> information.
There is a GenModel flag you can set that allows you to model these as
boolean features and then EMF will pack them into int flag fields. I
don't know that this directly helps you though.
>
> Then all I would have to do is translate the 16-bit short that is read
> in to these new EMF fields when the model data is fetched, and I would
> have to translate the EMF represenation into the bit fields when the
> model data is saved on the way out.
I think part of the problem in answering your question is it's not
entirely clear where you need the specific representation you describe.
Is this important in the serialized form? Is it important at runtime
when you have the model instance?
>
> Is that correct?
>
> Thanks.
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: Modeling to the bit level [message #622502 is a reply to message #529699] |
Mon, 26 April 2010 19:57 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Herb,
Comments below.
Herb Miller wrote:
> Here is the whole thing in a nutshell.
>
> The radio operator can initialize the radio by loading in a file with
> the correctly formatted set of 16-bit shorts.
So this comes down to needing a particular serialization format. It
doesn't sound like the file is XML...
>
> However, the operator may need to change a bit field, or even 1 bit,
> so GUIs will have to be provided for each separate cohesive piece of
> data whether it be a whole word, a part of a word or even 1 bit of a
> word (when I say word I mean 16-bit short).
>
> After making changes, the operator may want to save the changes made
> in a new file.
>
> I was hoping to model the bit fields and bits with EMF, generate, then
> got to RCP and all of the GUIs and model data would be generated
> (including serialization).
The serialization sounds highly custom, i.e., it doesn't sound like it's
XML, but I could be wrong about that. Can you show an example of the
serialization?
>
> From what I have gleaned so far, the serialization will have to be
> customized.
It sounds that way.
>
> Does this help?
If you show me the details of the serialization can can likely better
suggest the best approach for customization.
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: Modeling to the bit level [message #622506 is a reply to message #529712] |
Mon, 26 April 2010 22:37 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Herb,
You could specialize ResourceImpl's doLoad and doSave to read and write
your specialized format. I think you'd model many boolean fields, and
perhaps some enums. You'd encode/decode these to/from your specialized
format.
Herb Miller wrote:
> You are so right. The data in the file is definitely NOT XML. It is
> a list (64 to be exact) of 16-bit words, so serialization is
> definitely custom.
>
> It sounds like I will have to serialize the bit fields and bit values
> into EMF objects when reading the file, and convert EMF objects into
> the file format when writing the file, correct?
>
> The details of the serialization are similar to what I sent before
> with the example of the 16-bit short being converted into many
> fields. Some bit fields are 24-bits in length which would be 1 16-bit
> short plus a byte from the next 16-bit short.
>
> Thanks.
>
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.04508 seconds
] 
Search
Help
Register
Login
Home
