CANtalope Software Requirements.

This document describes the features that CANtalope should support (it does not talk about the requirements for running CANtalope; see the CantalopeSoftwareManual for that). If there are any features CANtalope doesn't have but should, please edit this page and describe them.

The interface for early revs of Cantalope will be cli. This way the output can be redirected into a file (as a standard unix tool should be). Later, this will be a shiney gui with bells and whistles.

Requirements

each can message will be on its own line.
Each message ID byte will be displayed in both Hex, Decimal, and Binary. This way we can compare different things at different times. It would be nice to be able to (at runtime) change what we were seeing. E.g. we could hit a button and change from all decimal to all binary.
Each Data byte will be displayable in both Hex, Decimal, and Binary. This again allows multiple comparisons.

Here's an example:

|Time Stamp      | CAN ID                     | RTR | DLC | DATA                    |
|----------------|----------------------------|-----|-----|-------------------------|
| 00:00:00.000.1 | 01011101010 / 0x2EA / 746  |  0  |  3  | 00 AF EE                |
| 00:00:00.000.2 | 01011101011 / 0x2EB / 747  |  1  |  0  |                         |
| 00:00:00.001.6 | 01011101100 / 0x2EC / 748  |  0  |  8  | 01 02 03 04 05 06 07 08 |

And an input value should look something like this:

CANtalope> 0x2ec 1 3 0x01 0x02 0x03

where the input is what you expect: 0x implies hex, 0b implies binary, and 0 implies decimal.

GUI features:

If you're interested in the developement of the CANtalope GUI, please examine this list and edit it and/or send email to shark (.At.) centibyte.org. Currently I'm thinking it should look similar to a chat program, with a text field to write messages, a text area to display them, and perhaps some other options.

The GUI frontend will be written in Java, so folks working on java tools like RocketView and LaunchControl will should be familiar enough to start hacking on CANtalope GUI frontend.
text entry field for writing CAN messages, with <enter> or "send" to send to CAN bus. An optional #comment could be added after the message. the UP/Down keys and a drop down menu allow the user to resend any message previously entered.
text area widget which displays CAN messages read from CAN bus, intermixed (chronologically) with CAN msgs we've sent out. Comments on messages sent out would be shown to make the "chat" more human readable.
all messages (and comments) shown in the text area widget (name: "chat view widget"?) can be saved to a log file. Since the messages are mixed together, we may want to separate the msgs we sent from those we received. So, with messages looking like this:

0x3ff 1 0 #optional-comment #WROTE# 0x3ff 0 1 2 #READ#

Then, to send only the messages out that we wrote, we'd do: grep WROTE logfile | cantalope write - . Or something. Note that the "#WROTE#" and "#READ" are put there by the code and not entered by the user.

Messages we sent will be visibly different from recieved messages in the text area (besides the READ/WROTE thing): those we've sent will probably be in bold.
The user could specify mappings between CAN messages and english descriptions, so for example, a message with msgId=0xf00 would be described as "FOO device". Then all messages with msgId=0xf00 would be displayed in the chat pane like: "(time) F00 device: 0xf00 0 3 1 2 3". If the user specified a message fully "msgid=0xf00 rtr=0 dlc=2 data=3,7"=="Shutting down foo", then the chat pane would show any such messages as, "(time) Foo device: Shutting down foo. (0xf00 0 2 3 7)". If this actually gets implemented, life would be good.
The logfile can also be read into the CANtalope frontend from a menu item with the option to send <wrote|read|all> messages out to the CAN bus.
Another menu item will simply read the logfile in and display it on the text area widget, without sending it to CAN bus. If anyone can think of why that would be really useful, say so. Otherwise it will be a non-priority feature (you can just 'vim' a logfile if you only want to look at it) implemented last if at all.
A possibility is to add a "Common/Preset Messages" widget which lists messages you may wish to send frequently. The user could double click on a message (or hit "send") to send it to the CAN bus. There could also be a "Programmed Send" button which sends one or more messages at a given rate (again, this is non priority since you can do the same with the CANtalope backend easily: while true; do cantalope write logfile; sleep 5; done;).
The frontend would take over responsibility for formatting from the backend. The backend will be changed to accept and output only one format, which the frontend would then read and convert to whichever format the frontend user wants to see. At that point, the backend will be as simple as it can be and if we ever have questions about the validity of data we're seeing we should be able to isolate bugs to either the more complicated java frontend or the simple yet functional backend.

Future:

Display the meaning of each message (e.g., map the CAN message ID onto an ASCII phrase: e.g., 0x2EA means "GPS latittude".
Interpret the data, whether it's a long, short, float, ASCII string, or whatever.