Propeller Guts Download

Ken Gracey

Hello friends,

A·new Propeller document·is now available for download below.·This document covers the assembly language and general architecture.

I'd like to point out that all officially released Propeller downloads will be available at http://www.parallax.com/propeller/·- discussion forums will quickly contain dated releases from Parallax. However, I'm·posting·this one·here since our web team won't be able to·post these on the web site·until Friday. ·In the meantime,·you'll have more·material·to review!

Sincerely,

Ken Gracey
Parallax, Inc.

Post Edited (Ken Gracey (Parallax)) : 2/24/2006 6:32:02 AM GMT

Eric R

Thanks Ken

Agent Cobalt

Awesome. Thanks Ken!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truth can be dangerous... Trust can be deadly.

FORD

Thanks Ken,

Gee you must be burning the midnight oil...
1.00 PM here.

Cheers,
Chris - West Oz.

Gadgetman

Groovy!

Probably won't get much work done in the office today...
(Lucky that the boss is away on vacation...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

Gadgetman

A bit of clarification on the LOCKs?

Why 'check-out' a lock?

Why not just use them directly, as I assume that when writing a Multi-COG system, we'd know what each of the locks would be used for?
(And how many we're using... )

The PLL...
In the info about the CLK Register it is mentioned that this ALWAYS runs at 16X, and that its internal frequency must be kept within 64 - 128MHz...
(4 - 8MHz Xtal)
Then you select the Master Clock as an multiplication of the Xin signal with the CLKSEL0 - 2 bits. with a max multiplier of 16...

What would happen if someone actually used an 8MHz Xin signal and the 16X multiplier?
Flaky behaviour, blue smoke, men in Black Armani suits and flashy gadgets coming around, or?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

Bruce Bates

Gadgetman -

Disclaimer: I have no knowledge of the Propellor System other than what's been provided here on this Forum.

With that in mind, I'll take a crack at one of your questions based on the latest documentation provided by Ken, and the Propeller Layout diagrams.

You asked: Why 'check-out' a lock?

"Locks" apply to semaphores, and semaphores are contained in the HUB, thus, by their very definition, they are global in nature. You may well want to check on the status of another process (COG) to make determinations as to what path of logic you should follow within your own COG, based on the status of another COG. This speaks mainly to ordered or sequenced operation I would think.

The PLL question is too deep for me at the moment, so I'll leave that for one of those folks who are better informed.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->

Martin Hebel

We didn't discuss this directly, but a PLL is a tuned circuit, and is used in this case to multiple the incoming signal clock. I imagine it can only lock onto inputs clocks up to a certain frequency, and thus, the limitation.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel

Disclaimer: ANY Propeller statements made by me are subject to my inaccurate understanding of my limited time with it!
Southern Illinois University Carbondale -Electronic Systems Technologies
Personal Links with plenty of BASIC Stamp info
and SelmaWare Solutions - StampPlot - Graphical Data Acquisition and Control

Paul Baker

The reason for checking out locks is the same reason as checking out cogs, by allowing the processor to allocate the resource for you, you can combine any combination of objects written for general purpose tasks (reading a keyboard, displaying NTSC video data, etc) where as long as the resource is availible, you will be provided one. If you instead use a specific semaphore, the propeller cannot allocate properly to those objects using the auto-allocate feature. IOW if you use semaphore0 and don't check it out first, a process asking the propeller to check out a semaphore·would be handed semaphore0 as well because the propeller doesn't know you are already using it. By permitting checking out of semaphores and cogs, you don't need to dig into various objects to determine if there is any conflict of semaphore or cog use.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Post Edited (Paul Baker) : 2/24/2006 1:17:33 PM GMT

Gadgetman

Yes, but that leaves the problem of reliably transferring the information on which LOCK to use to each COG that needs it.
Unless we also have a common way to transfer that information, we will have to update the common objects anyway, to be able to receive it according to your own way of doing that.

As for the PLL, it is obviously capable of producing frequencies up to 128MHz (as stated in the PDF), so what is the most likely problem if we try to run the Propeller at that speed?
(Someone is bound to try... )

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

KenLem

No built in mult or div instruction?

Does anyone know the timing of the multiply, divide and square root routines in the datasheet?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.speechchips.com

Speech & Video IC's for BasicStamps

Kaos Kidd

Awesome docs...
...Geezzzz, and I never thought I'de never go back to the days of WANTING to write in asm again... [noparse]:)[/noparse]

Thanks Ken!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

---

Just tossing my two bits worth into the bit bucket

---

KK
·

Paul Baker

Gadgetman said...
Yes, but that leaves the problem of reliably transferring the information on which LOCK to use to each COG that needs it.
Unless we also have a common way to transfer that information, we will have to update the common objects anyway, to be able to receive it according to your own way of doing that.

Its not as hard as you may think, the use of a particular semaphore under almost all circumstances will be intra-object, as such its a simple task to declare a variable within the object to contain the location of a particular·semaphore. Any·procedure·within the object that wants access to the semaphore, only need to retrieve it's location from the variable. Since the location of the variable is also dynamically allocated, you have a portable system for using semaphores.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

daniel

Paul Baker said...

Gadgetman said...
Yes, but that leaves the problem of reliably transferring the information on which LOCK to use to each COG that needs it.
Unless we also have a common way to transfer that information, we will have to update the common objects anyway, to be able to receive it according to your own way of doing that.

...use of a particular semaphore under almost all circumstances will be intra-object....

I suspect that Gadgetman is considering the harder case of inter-object usage of semaphore, anyway, that is what I'm considering.

I suppose that we are then limited to the MasterCog allocating the necessary inter-COG semaphores, and informing the other COGs of which semaphore is allocated for a specific purpose.·

Since the HUB can update bytes/words/longwords atomically, the semphore is needed (for sequencing data update/access, anyway) only when the data structure exceeds a longword.· Mutex (mutual-exclusion) semaphores for other purposes may be a different story.

Daniel
·

inaki

Paul, I don't get that. According to documentation there is a common pool of eight locks. How can you have a semaphore anywhere in an arbitrary object ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Gadgetman

daniel said...

I suspect that Gadgetman is considering the harder case of inter-object usage of semaphore, anyway, that is what I'm considering.

Bingo!

In fact, I don't see much use for semaphores internally in objects at all.

But...

What I would REALLY have liked is Free/Read/Exclusive type Semaphores.
Read: A non-exclusive access to read a resource. Any COG can grab this resource as long as it is either Free, or only Read by other COGs.
Exclusive: A COG can only receive this level if NO COG already has Read or Exclusive access to the resource.

The logics would have to be a bit more complex, though, as it would have to keep track of more than one COG's ownership of the Semaphore at once. (In theory, all eight COGs would be allowed to request a Read lock on the same resource at the same time)
This is similar to what multi-user databases uses...

Of course, that is a bit more difficult to use, and it is easier to get blocks, so...

Now, to sit down and study the ASM listing...
(I have a couple of short programs I like to implement to learn a new processor... And as a rule I only do them on paper... And try to calculate the number of cycles it would use, too... Real masochistic... Real GEEK!)

Edit:
BTW: I can foresee bother incredible advantages and problems in having an Assembly-language where setting and acting on flags is entirely up to what options you specify for each line... Cool...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

Post Edited (Gadgetman) : 2/24/2006 5:11:08 PM GMT

Paul Baker

If you follow the proper programming practice of encapsulation, low level elements of an object such as semaphores should never be visible to higher level objects. Even if all that means is that you provide a routine within the object that provides access to the semaphore to higher level objects, the semaphore itself should not be modified by anthing outside of an object, it violates several principles of object oriented programming.

Inaki, I think you misunderstood, the semaphore itself is not within an object, rather a pointer to the semaphore used is stored within the object.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

inaki

So, what happens if two objects point to the same semaphore ? Is is supposed all objects must agree on the locks they are using ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

inaki

Sorry, I meant two semaphores pointing to the same lock from different objects !

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Paul Baker

Ok, lets say you have a serial object which runs on a cog, it is fed data from another object that has the serial object declared. You want there to be mutually exclusive access to the buffer so that buffer corruption doesn't occur when feeding data (at the same time data to be transmitted is being removed from the buffer). So inside the serial object when intializing the serial routine, you also fetch a semaphore using the check out function, you store the semaphore location in a variable, say BufferMutex. You also define a procedure called Serout which is provided the data to be sent from your higher level object to be transmitted. Within the Serout routine, the checking of the Semaphore, via looking at the pointer BufferMutex is made to ensure the data is added at an acceptable time. Therefore the whole Mutex operation is being performed within the serial object, even though it is a higher level object which initiates the Mutex operation.

Now lets say your higher level object is a USB master you wrote, which has its own buffers (and sends the data received to the serial port run by the serial object). You have two cogs running for the process, one to handle the USB communication, and another to handle the data streams. You use two semaphores, one on the output and one on the input buffer. In the USBMaster object you declare two variables, USBSendBuffMutex and USBRecvBuffMutex, you check out two semaphores and store thier location in the two registers.

Now you have 3 semaphores, each with thier own pointer declaring which of the 8 semaphores it is stored in, they are all unique, and provide access to higher level objects by modifying the semaphore in a procedure located within the object which checked out the semaphore:

PUB GetUSBInputBuffer:OK
·· OK := !LockSet(USBRecvBuffMutex)

This simple procedure provides a higher level object to the USB input buffer through the semaphore, if OK == FALSE then the higher level object does not have mutual exclusive access to the buffer, if OK == TRUE the the higher level object now has mutual exclusive access to the buffer.

Does this example help you understand how to encapsulate arbitrarily checked out semaphore and provide access across objects?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Post Edited (Paul Baker) : 2/24/2006 5:49:57 PM GMT

cgracey

Guys,

Don't get so freaked out about LOCKs. I've written lots of objects which instantiate extra COGs that talk with Spin-level variable constructs and I haven't ever had to resort to using a LOCK in a single case, yet.

The reason is this: almost all 'contracts' for shared data call for one party to write certain memory locations that the other party reads, and vice-versa. In a buffered serial object for example, the COG that performs the actual I/O (in assembly language) has to transmit bytes that are deposited by Spin-level routines. The Spin code drops bytes into a circular buffer and increments the 'head' pointer. Meanwhile, the COG running the assembly code checks to see when the 'tail' is different from the head. When it is, it picks up the byte pointed to by the 'tail' and then increments the 'tail'. By the way, before the Spin code can drop a byte into the circular buffer, it must make sure that the 'head' is not going to bump into the 'tail' (because the transmit buffer is full). So, both processes read both the 'head' and the 'tail', but each variable is written by only one process. This is how most things are made to work, and it's quite simple. If it seems NOT simple, you just have to try it - you'll see. It's totally fun to play with.

A LOCK might be the most convenient way to share a buffer resource, say, which spans multiple bytes/words/longs. If you notice in the example cited above, only atomic read/write operations were occuring on a singular byte/word/long variables in main memory. When you must share many bytes/words/longs, a LOCK can come in handy.

- Chip

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Paul Baker

Thanks Chip for clarifying the issue, and welcome to the forums [noparse]:)[/noparse]. I admit my example was lacking in demonstratably showing the need for locks, I was trying to think of an example of a read-modify-write being performed by two seperate cogs, but couldn't immediately come up with one, so I settled on using the buffer example.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Post Edited (Paul Baker) : 2/24/2006 9:43:28 PM GMT

nick bernard

wow, what an example.
in this case the spin code enqueues to the buffer & sets the head as long as the head and tail dont point to the same location.
the cog performing the i/o dequeues the buffer & sets the tail as long as the head and tail dont point to the same location.
locks arent required because setting the head and tail are mutually exclusive between the two operations.

right?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
engineer, fireman, bowler, father, WoW addict [noparse];)[/noparse]

Paul Baker

You've got it on the nose. The critical point to look at is when the buffer is either full or empty when one cog is trying to enqueue and the other is trying to dequeue in a manner that either the head or tail pointer is modified before the actual queueing process occurs, if you map it out you'll see that in one instance the buffer appears full, when by the time it would actually enqueue it's not. The other appears that the queue is empty when by the time it would dequeue the queue has data. In either case the buffer just returns an erroneous BufferFull or BufferEmpty, this just postpones the processing until the next time the queue is checked.

Now say for instance you want a bidirectional queue (push or pop from either end) accessed by multiple cogs. This is an instance where semaphores are needed, but this is a pretty esoteric data structure that you likely won't need to implement.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Post Edited (Paul Baker) : 2/24/2006 10:28:15 PM GMT

inaki

I wonder, this Chip Gracey that is writing down in the forum is THE Chip Gracey ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Paul Baker

inaki said...
I wonder, this Chip Gracey that is writing down in the forum is THE Chip Gracey ?

yes.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Gadgetman

inaki said...
I wonder, this Chip Gracey that is writing down in the forum is THE Chip Gracey ?

Can't be...

Staring directly at gods tends to instill blindness in the beholder...

Though...
I did have to take off my glasses a minute ago and rub my eyes a bit after reading his post...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

Martin Hebel

It is a rare and wonderful event [noparse]:)[/noparse]
-Martin

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel

Disclaimer: ANY Propeller statements made by me are subject to my inaccurate understanding of my limited time with it!
Southern Illinois University Carbondale -Electronic Systems Technologies
Personal Links with plenty of BASIC Stamp info
and SelmaWare Solutions - StampPlot - Graphical Data Acquisition and Control

Chris Savage

inaki,

·· No he's a stunt double we hired to feed propaganda to the mobs!· Of course it's THE Chip Gracey!· LOL

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com

LoopyByteloose

Wonderful stuff about semaphores, very challenging.

There really are two Gracey's?

I was beginning to believe that it was the old, 'That wasn't me, that was my twin brother' line.

I knew that Ken is Chip's brother, but after a while, one really begins to wonder if Ken just has mutiple personalities or an alias or whatever.

Setting aside all the kidding, I did read the 15 pages of documentation and it really gives a better impression of what this can do. The EEPROM data pretty much declares the intentions of this to be a substantial number cruncher with video output. Having LOGS, ANTI-LOGS, and SINE tables with video/printer character output will allow it to provide a degree of precise control with Real time output.

I am not sure what I need it for, but I bet you could fly a rock with it if you could just find the right thing to push it and the right things to change direction. [noparse][[/noparse]I cannot afford those kind of toys.]

Now I am wondering about the '6 degrees of freedom' and what this would be like if you had three gyros and three accelerometers attached. You could put this inside a rough and tumble robot as its 'inner ear'. You would have 6 Cogs for sensors and 2 left over for converting data to navigation and response.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)

······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Post Edited (Kramer) : 2/25/2006 4:30:41 PM GMT

Tracy Allen

And in the Gracey mix don't forget Chip and Ken's dad, who sometimes pipes up here in the forum, but under a pseudonym. Its not hard to decode if you know what to look for! To Chuck we owe much, including the family of SX based Stamps.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com