Shop OBEX P1 Docs P2 Docs Learn Events
Pseudo eeprom possible with second prop? — Parallax Forums

Pseudo eeprom possible with second prop?

P!-RoP!-Ro Posts: 1,189
edited 2010-07-20 05:43 in Propeller 1
I'm asking this out of curiosity, not because I think I'm the one to do it, but would it be possible for a second prop connected to a storage device such as an sd card transfer startup data to a second propeller at faster speeds? The first prop could then choose to load whatever code is needed to the second propeller at faster speeds allowing it to be loaded with only the data necessary at that time, such as a tv driver instead of a vga one, or set it up to play music instead of running games. This would seemingly allow more capabilities to be provided than what can fit on a 32k eeprom, and run time capabilities can change on the fly without the need for reprogramming.

So what do you think, is it possible? I'd certainly like to see it happen, seems like it could radically change how we use the propeller currently and open whole new programming windows.

Comments

  • kuronekokuroneko Posts: 3,623
    edited 2010-07-16 07:03
    So basically you want to boot one prop from another!? Check out this object (OBEX). Also available in the PropellerTool library. It's dog-slow (~18Kb/s @80MHz, i.e. 16KB in ~7sec) but at least it lets you establish a beach-head and then you can/should switch communication channel. I use this to boot a RAMBlade (104MHz) from my DemoBoard (80MHz) and a couple of M-Modules on my SpinStudio mainboard at 5Mb/s.
  • P!-RoP!-Ro Posts: 1,189
    edited 2010-07-16 07:39
    Only problem is the entire code must be turned into a binary. Is it possible that the code could be turned into binary in pieces, then have the first prop choose what parts to combine to program the second propeller with? This seems like it would be a much more useful route to go in my mind. Even if it took extra time for the first prop to change the binary to accommodate attachment of different code it seems it would be worth it. Just an idea, though.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    90 * 2 = Pi
  • kuronekokuroneko Posts: 3,623
    edited 2010-07-16 07:45
    pi'd said...
    Only problem is the entire code must be turned into a binary. Is it possible that the code could be turned into binary in pieces, then have the first prop choose what parts to combine to program the second propeller with?
    Sure, that's certainly an option. But it's your responsibility to re-assemble those pieces to make a working program on the other end. Once you established the high-speed link you can do what you want [noparse]:)[/noparse]
  • Cluso99Cluso99 Posts: 18,069
    edited 2010-07-16 10:33
    I don't see why you need 2 props for this unless you are doing something else. It's certainly possible to load alternative binaries from SD card, but they need to be compiled first. Sphinx can actually compile on the prop.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
    · Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
  • P!-RoP!-Ro Posts: 1,189
    edited 2010-07-16 17:26
    The reason for the two props is to allow the second prop to be slave to the first, completing tasks the first prop can't complete do to lack of space. Then, depending on the tasks the first prop needs to get done, it can reset the second prop and load the required programs into ram for it to run. I can see a number of tasks where this could be useful, which is why I posted the question here out of curiosity.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    90 * 2 = Pi
  • Cluso99Cluso99 Posts: 18,069
    edited 2010-07-17 11:38
    Ok, resetting the second prop will always be slow just because of the cycle time for reset. Why cannot you have the second prop terminate all other cogs and go into a load loop and wait for the next code set. What has to happen can be gleaned from the SD loaders. You just run a FDX type object that firstly receives the length (important because then you only need to transfer the code required) and then receives the code placing this into hub starting at $0 up. When the length has completed, zero the remaining hub and restart the cog (see the SD loader again).

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
    · Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
  • P!-RoP!-Ro Posts: 1,189
    edited 2010-07-20 05:17
    That just gave me a great idea, since pasm is loaded into a cog through variable space, can individual pasm objects be turned into binary and saved to an sd card? Then perhaps it can be loaded into a single cog without stopping the other functions and reducing the load time. This would allow anyone to switch games the prop is running on the fly, or change the abilities of a complex robot. Could this more feasible method be done instead?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    90 * 2 = Pi
  • heaterheater Posts: 3,370
    edited 2010-07-20 05:43
    pi'd said...
    can individual pasm objects be turned into binary and saved to an sd card"

    Yes they can.

    You may have heard of the BST Propeller tool clone from BradC. There is also a command line compiler from BradC called BSTC. That has the option to compile a Spin module and then write out only the binary obtained from the DAT section (The PASM code) to a file. All the Spin part is discarded.

    So its:

    bstc -c somesource.spin

    Gives a file soumesource.dat which the PASM binary code for a COG.

    I have used this in the Zog project where I am extracting the compiled PASM code form Spin modules an using it with the C++ language. So far I don't save the cog "blobs" to SD card but that is certainly possible.

    You have to be careful though. If a PASM program or part of an object gets all its initialization information from a parameter block in PAR it's quite easy to fetch it from SD card to HUB, set up the required parameters and start it.

    BUT many times PASM code in objects requires certain values to be set into LONGS in the DAT section which is loaded into COG when running it. This works OK when the Spin and PASM are linked together in an object but if you just fetch the binary from SD then you have to know where within that binary you should write the start up information before starting it.

    I had to make a small change to FullDuplexSerial to remove this problem. Other objects might be harder to adapt to that usage.










    http://forums.parallax.com/forums/default.aspx?f=25&m=423939

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
Sign In or Register to comment.