Propeller II update - BLOG - Page 8 — Parallax Forums

# Propeller II update - BLOG

• Posts: 6,544
edited 2010-10-24 08:32
Ahle2,

"the values at the ROM location just happens to contain the same value for 4 longs in a row"

Thanks for looking at this. The "F"/"0" scenario happens throughout the entire ROM pick a row any row. ... If that indeed is the case, then the entire ROM could be represented in 1/4 of the current size substituting every "F" with a "1". I would be extremely surprised if that were the case.

I can 'trick' the output into reporting something other than "F" or "0" by adding a random element after the ROM read. So that sort of rules out reading the 'ROM_Word' improperly
```        PropellerROM := long[ Base + WordLineOffset + ROM_Longs ]   'Read LONG value from Propeller's ROM
If ROM_Longs == 0 or ROM_Longs == 1 or ROM_Longs == 5
PropellerROM?
```

...but because it's pseudo random and the Seed relies on the current value, a simple line of...
```        PropellerROM := long[ Base + WordLineOffset + ROM_Longs ]   'Read LONG value from Propeller's ROM
PropellerROM?
```

...at the same location results also in "F"/"0" output

Suppose the sanity check would be to take the output and apply it in reverse to see if I can generate the original Propeller ROM code
• Posts: 1,178
edited 2010-10-24 09:20
Mystery solved!!!

Change:
PropellerROM := long[ Base + WordLineOffset + ROM_Longs ] 'Read LONG value from Propeller's ROM

To:
PropellerROM := long[ Base + ((WordLineOffset + ROM_Longs)<<2) ] 'Read LONG value from Propeller's ROM

Remember we are reading LONGS from the memory and the offset must incremented by FOUR steps each time.

/ Ahle2
• Posts: 6,544
edited 2010-10-24 09:26
Ahle2,

Wow thanks!... can't believe I didn't see that.

This really helps!
• Posts: 1,178
edited 2010-10-24 09:29
What did I win? (Please be a propeller2 dev board or at least a C3 !! )

/ Ahle2
• Posts: 6,544
edited 2010-10-24 09:37
"What did I win" - The gain of my sanity :smilewinkgrin:

... Since we don't have a Propeller II yet, what I can do is put you on my radar for any pre-release beta testing when that becomes available.
• Posts: 10,253
edited 2010-10-24 11:08
Beau, thanks for the resource check.

That big SSD, configured as RAM comes into play how then? Do you also have a RAM filesystem, for loading lots of stuff, saving states, blocks?

Or was it just really cool to have that much headroom, or maybe it's needed for the real Prop II?
• Posts: 1,178
edited 2010-10-24 12:49
@Beau Schwabe
"Since we don't have a Propeller II yet, what I can do is put you on my radar for any pre-release beta testing when that becomes available."
I would LOVE that.
Then I would make some awesome demos for the prop2 to showcase the power of the chip. I do already have some ideas of what could be done.
Of course running SIDcog in 33100 x 8 = 264800Hz (or even more thanks to the multiplication instructions) for "aliasing free" sound generation would be cool as well.

/ Ahle2
• Posts: 6,544
edited 2010-10-24 13:12

The SSD is configured as a swap drive, but since it's solid state, it doesn't suffer the speed impact that a mechanical hard drive would, nor the hashing/thrashing that would take place.

The SSD only used about %7 of it's capacity ... The final Prop II design will be about 2.5 times larger than the test DIE so maybe %20 or so will be used then.

It's just nice to have the 'overflow' that goes to the SSD rather than to the Hard Drive.

Here are the notes I used to create the swap drive on my Linux system:
```Creating / Adding Swap Partition to system:

First find a partition you wish to use as a swap partition.

Next access the drive we want to make a swap partition on.
i.e.

fdisk /dev/hdb

if the partition already exists, then you may skip this step, otherwise,
you need to create a partition. Type 'n' (for create New), choose the
partition type as primary

Once the partition is created, make sure it is a type 82 - Linux SWAP partition.

To check/change the partition type, type 't', enter, then the partition number
(if more than one), and then the code for the desired type. the 'L' command
displays a huge list of known types.

after double checking that you were editing the proper drive (/dev/hda, /dev/hdb,
/dev/sdc, etc), and using the 'p' command to verify your work is correct, type

now, in this example we created /dev/hdb1 as a swap partition, so it is 'tagged'
as a swap (type 82), but isn't formatted' as a swap.

Type 'mkswap /dev/hdb1' and the partition will have the proper magic numbers
placed in it to signal it is a valid swap partition. BE CAREFUL, MISTYPING THIS
COMMAND CAN BE VERY VERY BAD IF YOU HAVE EXISTING DATA AND SPECIFY THE WRONG
DRIVE/PARTITION!!!!!

now the swap partition is created. We have to add it to the /etc/fstab file so
it will be seen during boot and added to the system.

edit /etc/fstab with a text editor and add this line:

/dev/hdb1 swap swap defaults 0 0

location in the file doesn't matter, although style points are awarded for
keeping the fstab file sorted by drive and partition number.

after you've saved that, type 'swapon -a' and the swap partition should be
added to the system virtual ram cache.  Verify it was added by using the 'free'
command. The value under 'total' and 'swap' should be the same as the size of
the partition you created.
```
• Posts: 6,544
edited 2010-10-26 22:09
Update: 10-26-2010

As of today, the Propeller Test DIE Database is "FROZEN"! ... This is a good thing :smilewinkgrin: ... it means that the data is fixed and can't be touched.

There are just a few paper work items that need to be addressed the remainder of this week, but the November 3rd tape-out date looks to be a GO!!!
• Posts: 10,253
edited 2010-10-26 22:15

One big milestone passed!

How many test chips will be produced?
• Posts: 21,230
edited 2010-10-26 22:18
Beau,

Sounds like excellent news.

Are there some steps we are missing out on here. Like, given this test die seems to be one third of the finished device surely there has been a lot of simulation of the logic going on at some point to verify operation?
• Posts: 514
edited 2010-10-26 22:21
Update: 10-26-2010

As of today, the Propeller Test DIE Database is "FROZEN"! ... This is a good thing :smilewinkgrin: ... it means that the data is fixed and can't be touched.

There are just a few paper work items that need to be addressed the remainder of this week, but the November 3rd tape-out date looks to be a GO!!!

Wooho! I'm looking forward to this special processor! Please keep us updated!

Must be another one of the great stuff in Christmas season.
• Posts: 6,544
edited 2010-10-26 22:29

"How many test chips will be produced?" - I think minimum is 40 die, but I'm not positive on that.

Heater,

"Are there some steps we are missing out on here. Like, given this test die seems to be one third of the finished device surely there has been a lot of simulation of the logic going on at some point to verify operation?" - I leave most of the simulation to Chip, and insert some constructive criticism where I feel that it is appropriate.

John A. Zoidberg,

"Must be another one of the great stuff in Christmas season." - We should know the outcome of the Test Die results by Christmas, but there still is a nice road in front of us... The Test Die will help determine how bumpy of a road it might be though. ... If things go as planned, we could realistically have Propeller II silicon by this time next year.
• Posts: 18,066
edited 2010-10-27 00:01
Congratulations Beau. Another milestone. Now its fingers crossed that everything runs as planned. :smilewinkgrin:
• Posts: 514
edited 2010-10-27 04:31
Beau, I believe that the Prop is still great and worth every wait, even if it's next year!
• Posts: 6,445
edited 2010-10-27 10:02
Excellent news! Congrats!
Update: 10-26-2010

As of today, the Propeller Test DIE Database is "FROZEN"! ... This is a good thing :smilewinkgrin: ... it means that the data is fixed and can't be touched.

There are just a few paper work items that need to be addressed the remainder of this week, but the November 3rd tape-out date looks to be a GO!!!
• Posts: 1,659
edited 2010-11-29 16:55
What happened to this thread? After 10/27/10 it dropped off the radar. I'm sure we're all still interested, right?
• Posts: 331
edited 2010-11-29 19:15
Yea. We're still on the same boat - it's just that fabrication of propeller II test die takes time to be done with. It's basically arts, which is pretty difficult even to predict, leave alone in Beau's capable hands. it may be few more weeks or months before we hear a peep from the test shuttle guys or even Beau himself.
• Posts: 296
edited 2010-12-16 13:33
I have a suggestion for the Prop II spin code or the next release of SPIN.
We all know the Propeller can preform as a I2C master. It's software. But there are some issues with this configuration:
#1: There are dozens of drivers, all of which work for their intended device, but not general enough to work with all devices.
#2: It takes a COG or two and additional resources to setup and use.
#3: The Propeller can't become a slave I2C device.

My suggestion is a I2CSLAVE command.
Basically it would place a pin into I2C Slave mode. It would need just a few arguments:
#1: The pin to monitor.
#2: The address to react to.
#3: The same basic parameters found in PBASIC 2.0's I2CIN and I2COUT commands.

This would allow for reduced size in SPIN and PASM programs, Increase it's functionality and reduce the number of custom I2C routines that are in existence. Additionally, this would enable the Propeller to become an accessory to other controllers (like the STAMP's) as a very intelligent I2C device, expanding their functionality as well.

This whole idea came up as I was revisiting my BS2P40 room monitoring project. I need to add additional devices to it, but I can't due to hardware considerations. A Propeller with the ability to respond as a I2C slave on a specified address would add a LOT of functionality at a minor cost to a lot of other devices already in existence; extending functionality where it wasn't able to be extended. This type of expansion would include the Propeller II deep into the realm of smart devices that can be easily embedded into other devices.

The STAMP's I2C commands are much more flexible and functional. If someone could (because it's beyond my ability to) write a I2C routines that could both master and slave an I2C chain(s), and have that fit inside a single COG, then this whole suggestion is mute.

Just a suggestion,

Fred
• Posts: 11,803
edited 2010-12-16 15:45
KaosKidd wrote: »
#3: The Propeller can't become a slave I2C device.
Actually it works pretty good and I'm using it in slave mode in an upcoming product.
• Posts: 296
edited 2010-12-17 05:45
jazzed wrote: »
Actually it works pretty good and I'm using it in slave mode in an upcoming product.

WOW...
Ok... My Sorries...
Jazzed, do you think you can share your code?
• Posts: 11,803
edited 2010-12-17 08:06
KaosKidd wrote: »
Jazzed, do you think you can share your code?
No need to apologize. I could not find it with forum search which seems less useful again ....
Use code from post #18 here http://forums.parallax.com/showthread.php?102839-I2C-Slave
• Posts: 6,544
edited 2010-12-17 09:47
The I2C specs are well known, it's how they are implemented in the current objects that become problematic.

Prior to the release of the Propeller I, Phillips required a license for I2C. By purchasing an I2C device that was considered a 'slave' you were grandfathered in to the license. Which means that in order to implement a 'slave' device on a micro and distribute it, you were required to obtain a specific license from Phillips.

This license requirement was lifted October 1, 2006 as a generic statement from Phillips ... "I2C licenses for standard mode under the remaining patents in the program will be free of any royalties, for any use of the patents after October 1, 2006, without any prejudice to any claims for past use whatsoever."

Some of this information can be found using the 'Wayback Machine' with this address ... http://www.nxp.com/buses/i2c/ ... since this information only seems to have been available between November 2006 and June 2008.

http://web.archive.org/web/*/http://www.nxp.com/buses/i2c/

To the original request... I don't know if there will be an I2C implementation, SLAVE or MASTER, on the Propeller II or not.
I2C.pdf 362.7K
• Posts: 296
edited 2010-12-17 12:54
Thanks everyone...
http://forums.parallax.com/forums/default.aspx?f=25&m=355505 is a I2C slave example using a modified version of hippys code. This code works as a I2C slave with a different processor as the I2C master.

Is there an easy way to convert this into the current forum url message header?
• Posts: 369
edited 2010-12-17 14:16
You just need to add "inc" after ".parallax"

http://forums.parallaxinc.com/forums/default.aspx?f=25&m=355505
KaosKidd wrote: »
Thanks everyone...

Is there an easy way to convert this into the current forum url message header?
• Posts: 18,066
edited 2010-12-17 23:03
Beau: Is there any news regarding the shuttle chips?
• Posts: 6,544
edited 2010-12-17 23:06
I was hoping to have something in hand that we could test before Christmas... as it is, it looks like the 28th of December we will have something to wiggle the bits on. So... first week of January 2011, we should know more information.
• Posts: 18,066
edited 2010-12-18 02:20
Oooh nice
• Posts: 269
edited 2010-12-18 12:32
• Posts: 296
edited 2010-12-20 05:51
Thanks Dave and Ding...
Very interesting code... I can't want for the PII to start to be tested...
Ding-Batty wrote: »

DaveJenson wrote: »
You just need to add "inc" after ".parallax"
http://forums.parallaxinc.com/forums/default.aspx?f=25&m=355505