hi,
here my 2 simple spinApps for intercommunications between PropC3 (master, sendDummyDatas)
to PropProtoBoard (PPB) as Slave (receive dummyDatas)
in the moment i work with my own QuadCopterSystem with C3+PPB.
if somebody interesting on it ....
its possible:
1) start: ppb send a number to c3
2) c3 response with ACK (5)
3) ppb command a specific number to receive differentDatas
( gps, laser-range-finder, heartbeat, gps-steaty etc)
I suspect the initial cut is for two topics --- same board versus over wire. Subtopic - rather vast....
Propeller to Propeller for same board appeals to users and developers than want bigger parallel systems than one chip can provide. The fastest possible bit rates related buffering apply. While parallel communication is possible, the gain of about 8x speed is traded away in have 8 or more pins required to exchange data. Can we limit the AN to serial, or do we need to cover parallel bus exchanges as well?
Propeller to Propeller over wire is mostly about distance, but also about protection from noise and protection from various abuses such as ESD . RS232 is a legacy for Propeller to other, but if one is starting from scratch Propeller to Propeller, Rs485 makes far more sense. Do we really need to cover RS232? The communications code is the same, but the RS485 allows greater distance, more noice immunity, and simpler driver chips (none of those additional caps) SPI, I2C, and so on are a group of synchronous methods that start out in a plain vanilla form and evolve into more demanding modes for less wires and bidirectional communication. The more exotic tend to be proprietary and tied to products other than the Propeller. It may be best to cover the fastest of the generics and dismiss the rest.
It seems the postings herein are rapidly evolving into a request to have an AN that covers 'all and everything' that the Propeller will do in terms of commuication and the pro and con of each in terms of construction, speed, noise immunity, economics. Plus we seem to be wandering into issues of network design.
At some point, some limits need to be set, or this is going to become a textbook, not an AN.
~~~~~~~~~~~~~~~~~
On the other hand, Parallax has benefited in the past from publishing textbooks. It may be time to have one on chip to chip communicatins as a 'for sale' item and the AN as focused Propeller-to-Propeller freebie.
"Can master also "provide" the shared memory?" - Sure... the only need for a Master is to initiate the round robin, otherwise there is no difference between the Master and the Slave(s) as far as read/write control over the shared memory block.
I'm sorry, I meant can the master use it's internal memory to emulate shared memory?
I am interested in using the file generated by my Visual Cadd program that contains line segments, circles, arcs, etc. and using a PC program convert the drawing into a file of X and Y coordinate pairs that are sent out a USB port to my Parallax multi-core Propeller control which then drives the X and Y axies for my plasma cutter machine. The plasma cutter machine works fine from (X,Y) coordinate pairs that I enter into the Propeller COG program. I would like to make an upgrade to tie in my CADD output to minimize any coordinate pair errors.
Comments
here my 2 simple spinApps for intercommunications between PropC3 (master, sendDummyDatas)
to PropProtoBoard (PPB) as Slave (receive dummyDatas)
in the moment i work with my own QuadCopterSystem with C3+PPB.
if somebody interesting on it ....
its possible:
1) start: ppb send a number to c3
2) c3 response with ACK (5)
3) ppb command a specific number to receive differentDatas
( gps, laser-range-finder, heartbeat, gps-steaty etc)
attachments:
masterCom1.spin (c3)
slaveCom1.spin (ppb)
regards
nomad
Propeller to Propeller for same board appeals to users and developers than want bigger parallel systems than one chip can provide. The fastest possible bit rates related buffering apply. While parallel communication is possible, the gain of about 8x speed is traded away in have 8 or more pins required to exchange data. Can we limit the AN to serial, or do we need to cover parallel bus exchanges as well?
Propeller to Propeller over wire is mostly about distance, but also about protection from noise and protection from various abuses such as ESD . RS232 is a legacy for Propeller to other, but if one is starting from scratch Propeller to Propeller, Rs485 makes far more sense. Do we really need to cover RS232? The communications code is the same, but the RS485 allows greater distance, more noice immunity, and simpler driver chips (none of those additional caps) SPI, I2C, and so on are a group of synchronous methods that start out in a plain vanilla form and evolve into more demanding modes for less wires and bidirectional communication. The more exotic tend to be proprietary and tied to products other than the Propeller. It may be best to cover the fastest of the generics and dismiss the rest.
It seems the postings herein are rapidly evolving into a request to have an AN that covers 'all and everything' that the Propeller will do in terms of commuication and the pro and con of each in terms of construction, speed, noise immunity, economics. Plus we seem to be wandering into issues of network design.
At some point, some limits need to be set, or this is going to become a textbook, not an AN.
~~~~~~~~~~~~~~~~~
On the other hand, Parallax has benefited in the past from publishing textbooks. It may be time to have one on chip to chip communicatins as a 'for sale' item and the AN as focused Propeller-to-Propeller freebie.
I'm sorry, I meant can the master use it's internal memory to emulate shared memory?
An ap note on this would be very beneficial.
Discovery
http://www.parallax.com/downloads/an018-communication-pc-application