Welcome, Guest. Please login or register.

Login with username, password and session length
ArdweeNET forum

 
Pages: [1]
  Print  
Author Topic: 32-bit point values  (Read 3987 times)
0 Members and 1 Guest are viewing this topic.
Graynomad
Administrator
Jr. Member
*****
Posts: 55



View Profile WWW
« on: January 31, 2011, 02:41:30 AM »

Is there any reason to accomodate 32-bit point values?

Three examples I can think of are PT_COUNT, PT_PERIOD and PT_FREQ, all of which could theoretically return values > 65k. But in the intended environment are we really going to be counting 10,000,000 events or high frequencies?

The flags field in a frame could possibly be used to indicate the data lenght, but I'm reluctant to do this unless there is a good reason.
Logged

Rob, aka the GRAYnomad
garylcamp
Newbie
*
Posts: 10


View Profile WWW
« Reply #1 on: February 11, 2011, 04:30:45 AM »

This is another case of leave it open to change, until you need it, then use the flag. Similar to my Time stamp suggestion, keep it simple but expandable later. In fact you should put some note in the documentation to allow for future expansion with out breaking existing environment.
Logged
Graynomad
Administrator
Jr. Member
*****
Posts: 55



View Profile WWW
« Reply #2 on: February 11, 2011, 10:40:49 AM »

Yes as there are four free flags in the frame so we can wait until it's needed. No current Node types need 32 bits and if one is designed then a flag can be used at that point.

The only issue is that the MCU has to know about this, still that code can be retro fitted at a later date.
Logged

Rob, aka the GRAYnomad
captcha
Newbie
*
Posts: 7


View Profile
« Reply #3 on: March 18, 2011, 11:18:50 AM »

Sorry for perhaps not interpreting the offered solution correctly, but instead of using a spare field in the header to indicate the length of the number, would it be possible to construct something like a 'data continues in frame xyz? That way you're not limited to what goes into one frame.

Someone once said: "640K ought to be enough for anybody."

As Gary mentioned, keeping it expandable is definitely the way to go.

Cheers,
marcel
Logged
Graynomad
Administrator
Jr. Member
*****
Posts: 55



View Profile WWW
« Reply #4 on: March 18, 2011, 11:53:09 PM »

This is actually one of the things I've done some work on lately. Any value returned by a Point is returned in what's known as a Point Data Unit (PDU). A PDU has the following format

ADDR - The address this data comes from.
POINT - The Point this data comes from.
CNTRL - A control byte indicating the format and length of the data in this PDU.
TS0-3 - A 4-byte timestamp.
DATA - N bytes being the Point's data.
CRC - A CRC covering all the previous bytes.

Note that this PDU is inside a BUSnet frame.

The CNTRL byte has two fields, LEN and FMT and these describe the enclosed data. So LEN can be used for data of any reasonable size, up to 32 bytes.

So if I have got it right any data format and size is handled at least for input Points. Just how to handle output Points I haven't decided yet. Maybe the same format should be used but with a null timestamp.

The reason for such a large structure that may only report the value of a single switch is that I want an atomic data structure that carries all the information required to re construct an event. So later, when the data arrives say at an Excel spreadsheet, it has everything required to draw a graph or whatever.

EDIT: If the data is > 32 bytes then we may have to look at a continuation flag or something. This is already an issue with the Bulk Data Transfer (BDT) command. It can send 255 bytes but what if we need even more?

EDIT2: The PDU is partly covered in the current docs, but this needs more work.

« Last Edit: March 19, 2011, 12:03:55 AM by Graynomad » Logged

Rob, aka the GRAYnomad
Pages: [1]
  Print  
 
Jump to: