Propeller II update - BLOG

15681011223

Comments

  • Beau SchwabeBeau Schwabe Posts: 6,417
    edited 2010-10-24 - 08:32:15
    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
  • Ahle2Ahle2 Posts: 976
    edited 2010-10-24 - 09:20:47
    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.
    Because of the address alignment (address&0x11111111_11111111_11111111_11111100) we read the SAME address 4 times in a row. :)

    / Ahle2
  • Beau SchwabeBeau Schwabe Posts: 6,417
    edited 2010-10-24 - 09:26:21
    Ahle2,

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

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

    / Ahle2
  • Beau SchwabeBeau Schwabe Posts: 6,417
    edited 2010-10-24 - 09:37:42
    "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.
  • potatoheadpotatohead Posts: 9,957
    edited 2010-10-24 - 11:08:58
    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?
  • Ahle2Ahle2 Posts: 976
    edited 2010-10-24 - 12:49:07
    @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
  • Beau SchwabeBeau Schwabe Posts: 6,417
    edited 2010-10-24 - 13:12:22
    potatohead,

    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
    'w' to write your changes and return to the root prompt.
    
    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.
    
  • Beau SchwabeBeau Schwabe Posts: 6,417
    edited 2010-10-26 - 22:09:01
    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!!!
  • potatoheadpotatohead Posts: 9,957
    edited 2010-10-26 - 22:15:01
    :)

    One big milestone passed!

    How many test chips will be produced?
  • Heater.Heater. Posts: 21,233
    edited 2010-10-26 - 22:18:36
    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?
  • John A. ZoidbergJohn A. Zoidberg Posts: 514
    edited 2010-10-26 - 22:21:19
    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. :)
  • Beau SchwabeBeau Schwabe Posts: 6,417
    edited 2010-10-26 - 22:29:40
    potatohead,

    "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.
  • Cluso99Cluso99 Posts: 15,704
    edited 2010-10-27 - 00:01:30
    Congratulations Beau. Another milestone. Now its fingers crossed that everything runs as planned. :smilewinkgrin:
  • John A. ZoidbergJohn A. Zoidberg Posts: 514
    edited 2010-10-27 - 04:31:02
    Beau, I believe that the Prop is still great and worth every wait, even if it's next year! :D
  • Bill HenningBill Henning Posts: 6,445
    edited 2010-10-27 - 10:02:50
    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!!!
  • lardomlardom Posts: 1,570
    edited 2010-11-29 - 16:55:33
    What happened to this thread? After 10/27/10 it dropped off the radar. I'm sure we're all still interested, right?
  • Dr. MarioDr. Mario Posts: 330
    edited 2010-11-29 - 19:15:04
    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.
  • KaosKiddKaosKidd Posts: 296
    edited 2010-12-16 - 13:33:22
    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
  • jazzedjazzed Posts: 11,803
    edited 2010-12-16 - 15:45:37
    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.
  • KaosKiddKaosKidd Posts: 296
    edited 2010-12-17 - 05:45:47
    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?
  • jazzedjazzed Posts: 11,803
    edited 2010-12-17 - 08:06:09
    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
  • Beau SchwabeBeau Schwabe Posts: 6,417
    edited 2010-12-17 - 09:47:42
    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.

    Wayback link:
    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.
    pdf
    363K
  • KaosKiddKaosKidd Posts: 296
    edited 2010-12-17 - 12:54:13
    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?
  • DaveJensonDaveJenson Posts: 264
    edited 2010-12-17 - 14:16:07
    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?
  • Cluso99Cluso99 Posts: 15,704
    edited 2010-12-17 - 23:03:30
    Beau: Is there any news regarding the shuttle chips?
  • Beau SchwabeBeau Schwabe Posts: 6,417
    edited 2010-12-17 - 23:06:25
    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.
  • Cluso99Cluso99 Posts: 15,704
    edited 2010-12-18 - 02:20:02
    Oooh nice :)
  • Ding-BattyDing-Batty Posts: 252
    edited 2010-12-18 - 12:32:24
  • KaosKiddKaosKidd Posts: 296
    edited 2010-12-20 - 05:51:56
    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
Sign In or Register to comment.