View Single Post
  #104   Spotlight this post!  
Unread 21-11-2013, 13:31
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,624
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Driver station power

Quote:
Originally Posted by yash101 View Post
So, could I add a memory buffer method to create a variable in the Built-in RAM, and use that for high speed access? That way, the variable is copied into the internal RAM. The hub can then access the ram quickly
I think this might be beneficial to read:
http://propeller.wikispaces.com/Large+Memory+Model
That assembly code not just copies data from the Hub RAM, that data is actually executable code.
Just data is by comparison pretty simple.

Basically you want to move the private performance critical variables into the internal Cog RAM (not to be confused with internal to the Propeller chip) for the highest speed.

Public performance critical variables within a Cog need to get that Cog to 'export' them into the Hub shared RAM and anything in the Hub shared RAM needs to get a Cog to import it.

The difference between private and public here is important and differs slightly from the way those terms are often used, so I will explain:

A private variable rarely needs to be exposed to the Hub at all so it gets maximum performance.
A public variable is probably being often exchanged with the Hub.
(Who decided on the names public and private in this context? I just did it's part of some code I already wrote.)
To make things easy to see you should group your private variables together within the Cog. The same with the public variables.
Then you can code an 'export' function to periodically take the public variables that are grouped together and move it as a segment sequentially into the Hub (if you think about this these grouped variables are effectively what assembler programmers refer to as a stack so you have multiple stacks being copied as segment to the Hub shared memory at time intervals dictated either by a timer or loop execution).
One might need to have some of the public segment more frequently update than others so if that is desired group the public variables together based on update frequency. The key is to keep the variables together to keep the operations sequential (making the loops simple increments).

This is a software imposed version of memory management for the < 500 longs of memory within each Cog. You pay for it in the performance of each Cog the instant you make anything public (because something has to steal Cog processing time to move the data). However once you design the system you can clone it over and over for each Cog.
This sounds complicated but even in straight assembler it is short.

The highest performance can be demanded from a Cog that never interacts with the Hub round-robin mechanism.
The more the Cog interacts with the Hub the more performance you loose to that interaction.
So if you are setting aside time to move 20 longs to the Hub shared memory: what I described can be done really fast at each opportunity without missing any opportunity, or setup interleaved into other timing critical operations and still be understandable if you need to debug it.

Last edited by techhelpbb : 21-11-2013 at 13:48.