One aspect of using the Propeller chip is that there is a lot more software simulation of communication than with other microcontrollers. In the Propeller there is no USART, no SPI or I2C hardware. We have to do all of this in software. There are rudimentary proof-of-concept objects available for Spin (the propeller programming language) but they do not get near the speeds (in bytes per second throughput) that we need. How do I know what I need? Let's look at the CAN bus traffic to determine this.
This USB to CAN controller is for general CAN use but is being created so we can control or interact with a "constellation" of "Widgets" on the CAN Bus. See http://can-do.moraco.info/ for a description of the "Widget" including full user manual and Programmer's Guide. This Widget is designed to be the point of integration for each payload to the satellite's house-keeping computer. This "constellation" of "Widgets" is really the collection of payloads in the satellite all communicating with the house-keeping computer over the CAN Bus.
The protocol for communication with these Widgets is a small subset of the possible range of CAN messages. The actual messages used are called out in full detail in the appendix of the User's Guide at the aforementioned web-site.
In order to "run the numbers" I had to select the most useful way to view the traffic. That is CAN messages consist of a header and an optional payload followed by a few more fields (checksum, ack, etc.). The data portion of the message contains "Stuff bits" which are bits injected by the transmitter into the message so that there is never more than 5 consecutive ones or zeros. This facilitates clock recovery from the serial data stream. You can read in more detail in the CAN spec. but the important part for us is that there is a minimum bit length and a maximum for each payload size (0-8 bytes). For performance measurement then I chose to use the minimum (which we mostly can't attain) so that we'd get best saturation of the CAN Bus.
We have 0-byte, 2-byte and 8-byte payloads in the AMSAT protocol so my numbers yield the following as goals:
AMSAT CAN Bus rate: 800k bps (800,000 Hz)
Minimum bits lengths for CAN Messages:
- 0-byte payload: 47 bits for a max rate of 17,021 messages/sec
- 2-byte payload: 63 bits for a max rate of 12,698 messages/sec
- 8-byte payload: 111 bits for a max rate of 7,207 messages/sec
- Max Serial Tx rate: 1.51 Mbits/sec (10bit characters at 22 chars/message)
- Max SPI rate: 1.8 Mbits/sec (17,021 messages per second at 14 bytes per message)
[actually this might be slightly higher based on SPI transactions used]
So, there we are. We have pretty high maximum data rates for both Serial Tx and SPI.
Now, let's move on to discussing the first firmware functional organization.
No comments:
Post a Comment