Question about EEPROM

[gmatocha]

Wow, look like I'll be the first person in a while to post here. Here's my total newbie question:

I'm using a PropSX (for the first time) that I picked up a couple of years ago but never got around to using in a project. I'm using an SX Key, and the SX-Key v3.3.0 software, all coding in SX/B. So far so good - my program is working great. My program is largely table driven, and now my tables have outgrown the 2k of flash memory in the SX and need to expand to the EEPROM. I found the "prop-sx_template.sxb" file that has code that reads/writes to the EEPROM via I2C. Great.

My question is, what's the recommended way of loading up the EEPROM with my tables? I could write a "loader" program that loads blocks of data from memory into the EEPROM, but they would be limited to <2k per run, so loading the full 32K would require over 16 runs!
I've done a lot of searching, but haven't run across an answer. This makes me think there's something very simple I've overlooked. Any suggestions?


Thanks,
Gene

[JonnyMac]

If you're comfortable with PC coding you could create data on that end and send it through the serial port to the SX for storage in the EEPROM.  This process is used in our EZ-8 which has a 32K eeprom.  It's a little bit of work because you need to have a mechanism for receiving a block of bytes in the SX, writing them to your EEPROM, and then letting the PC know you're ready for more.  For obvious reasons I cannot release the full source code of the EZ-8, but I can show you a small portion of code that handles the exchange from the PC. 

Download_Show:
  eeStart_LSB = RX_BYTE                         ' receive block address
  eeStart_MSB = RX_BYTE
  FOR idx = 0 TO 15                             ' recieve block
    eeBuf(idx) = RX_BYTE
  NEXT
  WR_BLOCK eeStart, @eeBuf                      ' write to eeprom
  EE_WAIT                                       ' let write finish
  TX_BYTE ">"                                   ' ready for another block
  GOTO Main

This is the WR_BLOCK routine:

' Use: WR_BLOCK address, @array
' -- "array" is 16-byte array to write

SUB WR_BLOCK
  wbAddr        VAR     tmpW1
  wbPntr        VAR     tmpB1
  wbIdx         VAR     tmpB2
  wbTemp        VAR     tmpB3

  wbAddr = __WPARAM12                           ' address to start from
  wbPntr = __PARAM3                             ' first element of array

  EE_WAIT
  I2C_OUT SlaveWr
  I2C_OUT wbAddr_MSB
  I2C_OUT wbAddr_LSB
  FOR wbIdx = 1 TO 16
    I2C_OUT __RAM(wbPntr)
    INC wbPntr
  NEXT
  I2C_STOP
  ENDSUB

[gmatocha]

What took so long to respond? ;)

Appreciate it - Thanks!

Any plans for a Propeller Prop product? The PropProp board?

[JonnyMac]

We have in our plans a board called the Prop-Pro, but that's still in planning as we update the rest of the line to Propeller chips (HC-8+ replaced the DC-16 and Prop-SX), the FC-4+ prototype is working well, the FC-4+ is in development).  We have a couple other goodies in the works, too, but I'm not going to talk about them until they're ready.

The HC-8+ is what I'm using for prop control for advanced projects.  If you look in that forum you'll see I've been posting some interesting stuff (I think so, anyway).

BTW... the HC-8+ has a 64K EEPROM; 32K for program and 32K for user storage.  You'd still have to create a downloader program for the PC side, but you'd have a heck of a lot more data.  Or.... if you plug the optional microSD card adapter into the HC-8+ you could read files directly (I'll be showing how you can do that in the HC-8+ forum as soon as the uSD adapters are in).

[gmatocha]

Wow...I've never looked closely at the HC-8 since it wasn't listed under the "Controllers" section of your web site. The price seemed high for an "IO Enhancement". But after looking more closely, it looks like it IS already a Propeller based Prop board - plus beefy drive capability. Neat! Dude, that thing is a controller - list it there too! :)

Gene

[JonnyMac]

As with the AP-16+ we tend to seek guidance from customers and pack in what we can.  What started as a replacement for the DC-16 is certainly that and a whole lot more. 

We're particularly excited about the built-in RS-485 networking which can be used for DMX and other protocols (e.g., MODBUS, Rendard [popular in Christmas lighting], etc.).  I created a simple text-based protocol called HFCP (Human Friendly Control Protocol) that one of our customers is using in a system of networked HC-8s.  And a mouse-friendly amusement park used a custom program with DMX input to control lights and servos in a prop that resided in a big spooky house on the property last Halloween season.

Unlike our other controllers, the HC-8+ comes with application code loaded.  For those that want to experiment you can always restore the HC-8+ to its out-of-the-box state by downloading the pre-compiled application (it's on the HC-8+ page of our normal web site).