?Issue with transmitters?

[csBlueChip]

I'm confused as to whether this is an issue, or my failure to understand...

https://github.com/collin80/due_can/blob/master/src/due_can.cpp#L1391
shows "consumer" grouped with "receiver"

...A few lines later
https://github.com/collin80/due_can/blob/master/src/due_can.cpp#L1430
shows "producer" separated from "transmitter"

The way I read it, "producers" can never send any data!?
Should the case 5 line be moved to pair up with the case 3 line?
...and thus 'enable' "producers"

[collin80]

To tell you the truth, I put the consumer and producer parts in there just because the chip supports them. I don't know how to use that functionality properly and I've never tried. But, I do think that case 5 should have been above case 3 such that they both do the same thing. But, like I said, I don't use the consumer/producer system nor have I ever. So, your guess is as good as mine.

[csBlueChip]

Thanks Collin.
I'll leave this issue open as an aide memoire for the case 3.
But I guess if that's the (current) extent of Transmitter support, then it's probably moot.

[csBlueChip]

This is the best I can make out of the SAM documentation:
The working example is potentially unrealistic ["theory & practice"] ...but I'm more than happy to be corrected if you/anyone feels I have misinterpreted the manual.

Reference
---------
http://ww1.microchip.com/downloads/en/devicedoc/atmel-11057-32-bit-cortex-m3-microcontroller-sam3x-sam3a_datasheet.pdf
Page 1205, Section 40.8.3.3 

Scenario
--------
In this example we have two devices,
each is sending data to the other
EG. The Dash-Computer wants to make sure the Dash Display accurately reflects the state of the Lamps
	Dash-Computer queries the state of the Lamps
		Lamp-Computer receives the query
		Lamp-Computer sends Lamp Status
	Dash-Computer receives the reply
	...Dash-Computer updates the Dash Display

Push Model
----------
We are used to operating in the "Push Model" 
...AKA. "Broadcast Model" 
...AKA. "!RTR" [!"Remote Transmission Request"]:

In the Push Model
	A "Producer" Broadcasts a frame
	A "Consumer" receives a frame
	
So, for our simple sceanrio, BOTH the Dash-Computer AND the Lamp-Computer require:
	1 @ Mailbox as Tx
	1 @ Mailbox as Rx

I should guess it's all pretty obvious from there.  In brevity:
	Dash-Computer:
		send_lights(query_state) ;
		if (frame_received())  setDashState(frame.data) ;
	Lamp-Computer:
		if (frame_received(query_state)) send_dash(lamps_state) ;

We have a total of EIGHT Mailboxes (in each Controller)
So we can replicate this scenario FOUR times within a single controller.
Eg.  Dash -1-> Lights ... 0=Rx, 1=Tx
          -2-> Doors  ... 2=Rx, 3=Tx
          -3-> Seats  ... 4=Rx, 5=Tx
          -4-> AirCon ... 6=Rx, 7=Tx
          -5-> Radio  ... Sorry, we're out of Mailboxes. Please add more Controllers!

Bad Jargon
----------
If I ask for a coffee, and you supply one - I am the Consumer and you are the Producer.
Here, the Dash-Computer makes a request of the Lamp-Computer, and is suitably patronised.
So the Dash-Computer is the "Consumer" and the Lamp-Computer is the "Producer"
-HOWEVER-
We are running in the Push Model
So really, they are both JUST Transmitting and Receiving frames,
...The *terms* "Producer" and "Consumer" are 'conceptual' at best.

Pull Model
----------
The *words* "Producer" and "Consumer" take on 'proper-noun' value when we consider the "Pull Model"
...AKA. "Producer/Consumer Model" 
...AKA. "RTR" ["Remote Transmission Request"]:

In the Pull Model everything works the same as the Push Model
...with ONE *significant* exception:

We can instruct ONE Mailbox to act as both Transmitter AND Receiver
More specifically, we could set the:
	Dash-Computer:Mailbox[1] to be a Consumer [Transmit-then-Receive]
	Lamp-Computer:Mailbox[1] to be a Producer [Receive-then-Transmit]

The Consumer, will put a frame in a/the "Consumer" Mailbox
...and issue the Transmit command
The Controller will Transmit the [RTR] frame
...and immediately set the Mailbox to be a Receiver
Once the reply has been received, I *think* you just goto 10 - the datasheet doesn't make that clear

For reasons explained in the paragraph over pages 1206/1207
You MAY be wise to ensure your Consumer Mailboxes are ALWAYS the lowest numbered Mailboxes!

The Producer, will put a reply frame in to a/the "Producer" Mailbox
...And put the that Mailbox in Ready/Listen mode
When that Mailbox Receives/Sees a frame
...It will immediately send the pre-prepared frame back to the Consumer

Obviously this will mean careful configuration of the MID and MAM fields
...to make sure mailboxes only respond to appropriate frames

With the Pull Model, we can replicate this scenario EIGHT times within a single controller
...Potentially halving the number of Controllers required for a single Computer