View Single Post
  #102   Spotlight this post!  
Unread 20-11-2013, 23:25
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
BTW, for the propeller, I came up with a nifty idea:
To write a Java interpreter, compiler and kernel to be installed to the propeller. This kernel would fetch instructions from an SD card, parts at a time, allowing a large code. Also, the compiler would convert the code to bytecode to run efficiently on the propeller. I am pretty sure that a 128 MB card will be enough to hold Google's Search Engine Code (Not their database or their other services).

I think there are some practical uses for something like this, as it would allow you to access the inaccessible features on the Propeller!

Also, how can I add more RAM for variable space on the propeller? I would like all the user variables to be in an external RAM of 16Mbit, meaning that they do not need to worry about RAM.

The only thing this may not be able to do is image processing (Or maybe it can).
Let's break this idea into smaller parts.

There is already a stub you can put into a Propeller Cog that will load program and variables from the Hub memory. At the cost of waiting for the round-robin Hub mechanism.

One could load the Hub memory via Cog(s) to contain segments of code and variables interchanged from some of the remaining Cogs then sent back and forth to external memory or devices.

The price you pay for this from the perspective of any single otherwise unassigned Cog is waiting for the Hub mechanism to move data into the shared memory. Waiting for the Hub mechanism to give access to the Cogs that transact the data with the external devices. However let us not underestimate that the greatest delay will be to get the data into and out of the I/O pins on the Propeller to whatever else is out there.

This is no different than the way I created a control system as a network of interconnected Propellers. The greatest delay is at the I/O to the other chips (other Propellers, memory, sidecars...whatever they might be). You can cheat some. You can use more than 1 bit at a time. Making a parallel communications bus. You can make the transactions synchronous eliminating slow asynchronous timing issues. If you do this right you can pump data fast...but still not as fast as what you can do inside the Propeller itself.

The point: ideally you want to avoid moving data external to the Propeller for any purpose where speed is critical. In those cases you are far better off say: consuming 7 Cogs for a purpose, confining the process to those Cogs and then using the left over Cog to spew less critical communications to the rest of the system.

It would be ideal if there was a massive amount of Hub shared memory. Then again that is static memory. Most PCs use dynamic memory which is effectively slower and more tricky because large quantities of static RAM would get expensive. I hesitate to say just what the perfect balance here is. Even x86 CPU pay dearly in performance when they reach outside to access the system RAM. That's why the CPU cache is so important. So think of the shared Hub memory as a shared CPU cache. As most modern CPU are actually running a program you can't alter called microcode there's further similarity there to be explored. The loss created by the external I/O does come at a price but it's a price common to other computing designs as well. The massive difference in favor of the Propeller is that you can control aspects of the cost for the external access (add more bits to the bus, compress data, change the segmentation, alter the timing) something there are very real limits on in other architectures as they are more general purpose oriented (you can be great at one thing or mediocre at lots of things).

Last edited by techhelpbb : 20-11-2013 at 23:44.