Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000355FirmwareSerial Commspublic2011-10-27 22:492012-04-05 00:43
Assigned ToFred 
PlatformOSOS Version
Product Version0.2.0-SNAPSHOT 
Target Version0.3.0Fixed in Version 
Summary0000355: Add Two New Calls To Core Protocol
DescriptionProviding community consultation goes well, add the following two calls to the required core protocol:

Request List Of Payload IDs
Request Parameters Of Payload ID, size ranges, affects flash, etc

This will enable some API checking to be done to verify that the PC side tool is compatible and enable safe probing of all payload IDs that don't affect flash etc.

I would argue that for this to be universal it must be part of the core protocol as otherwise you're not guaranteed to be provided with it. And if there is no guarantee you can't base your actions around it.

In the event that we provide a full DDL file from inside the device, this data long with other interrogation style data could be ALSO stored in that file and be checked for consistency against the live data from the running firmware providing another level of checking that the API was stable and consistent.

Or perhaps it's a bad idea. Will review tomorrow.
TagsNo tags attached.
Issue TypeTask
Risk of Breakagemedium
Attached Files

- Relationships

-  Notes
dandruczyk (viewer)
2011-10-28 13:37

I'm all for it..

One thing I WANT to see ENFORCED is no CLASHES of reusing the same core payload ID for different things. (namespace collision). i.e. payload ID 0x0100 should always be REQUEST_UPDATE_BLOCK_IN_RAM, across ALL variants, likewise for all other core functions, if a device doesn't implement that function that ID should remain UNUSED.

i.e. all variants need to meet a core protocol requirement, then each subset should be defined a UNIQUE range of ID's to be used for "custom" functionality.
User avatar (0000505)
Fred (administrator)
2011-10-28 20:15

IRC discussion summary:

1) It would be worthwhile to have the following in the core spec:

core range - MUST be implemented
free range - Up to the specific application
user range - MUST NOT be used by applications

Core range should be small, but big enough to cover some expansion of the core protocol. Current size is excessive at 128 with only 8 in use.
User range should be small too, perhaps the same as core range.
Free range should extend between them with Core starting at zero and extending up and user starting at MAX and extending down.

2) The current two level specification is insufficient for proper consistent operation of a set of related applications. But also that core should be minimal and encompass only transmission and identification and other fundamental always there functionality such as resets.

What is required on top of that foundation is a set of application level commands that are standard in a family of genetically related applications, such as sequential versions of FreeEMS.

On top of the core spec which won't change much there can be an independent application level spec perhaps called "FreeEMS Standard Protocol" which will ALWAYS be implemented IN FreeEMS firmwares, but not necessarily anything else using the core protocol, such as wide bands, digital dashes, etc. Such a standard set would include base functionality with which you could operate on the device in a reasonably complete way. It wouldn't include fancy extra packets such as bench test stuff or exotic log formats, for example.

3) That to make the level specifications more generally accepted and less ambiguous and misleading that the core protocol be renamed to something more generic such as ECP or ESCP or similar Engine * Comms Protocol style acronyms. What that name might be is up for debate and suggestion 100%.

4) In terms of MTX, the family/device layer implementation could do one of two or more things:

A) Upon querying the version strings etc if it's not a recognised option, give up and let the user know what they connected to and call it a day.
B) Consider the FreeEMS family to be the core and have the family be bigger than the real ECPetc protocol.
C) Perhaps other solutions such as extending the plugin arch, though that's not necessary.

Suggestions were also tabled in favour of segregating and partitioning the allowed packet ID values between application families. I strongly dislike this as it has severe limitations for each family that get worse as more families arrive and limit the number of possible families and complexity of each. This also has no place in the core specification which is really just a transmission and identification scheme.

In summary, if the above calls are not added to the core, they WILL be added to the FreeEMS scheme, and if/when a FreeEMS family standard is adopted they will be part of that. Obviously the discussion spiraled wonderfully out of control :-)

If there was anything else that I've missed, feel free to mention it below.

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker