UBW32 / General HWDev -- Adding inputs?

USB PICs and the UBW

Moderator: phalanx

Re: UBW32 / General HWDev -- Adding inputs?

Postby alandsidel » Wed Mar 30, 2011 4:27 pm

rtestardi wrote:You might also consider some i2c i/o multiplexors:

16 bit: http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en537375

8 bit: http://www.nxp.com/documents/data_sheet/PCA8574_PCA8574A.pdf

These seem super flexible...


Indeed, thanks for the tip! I've been looking around at different i2c or spi modules, but I have a ton of these 165s now, and they do work perfectly if you control them the way they're meant to be controlled. Still only 4 wires so I may keep using them until I run out, and find some other fun things to hook up to the SPI and I2C instead.

As SPI devices they're just a "no go" it seems. I suppose I could try putting the SPI in slave mode instead, ground out nSS and SDO, and clock it with one of the frequency capable pins -- or something along those lines. Seems like it might be fun to try even if it's silly.
alandsidel
 
Posts: 47
Joined: Thu Sep 23, 2010 10:54 pm

Re: UBW32 / General HWDev -- Adding inputs?

Postby alandsidel » Thu Mar 31, 2011 12:01 pm

One last (maybe) update for those that are interested. Underlined pin names substitute for overlines on actual chips.

Using the 74x165 as an SPI device is possible, but imperfect. Wired as follows, 165 on the left, PIC (SPI master, frame master) on the right:
CP <- SCK : clock
Q7 (output) -> SDI (input)
CE (clock enable) <- SDO (data output)
PL (parallel load) <- SS : (chip select / frame pulse)

  • You cannot define the 'inactive' state of SDO. The LSB you write must be 1 to keep CE high when not reading. Transition to high = the 165 stops shifting, so you will lose the first LSB from the 165.
  • You cannot tell the PIC to send the frame pulse early enough, so the MSB must also be high in SDO. This delays the 165 from shifting for a clock, so you lose the next LSB.

Workaround 1:
You can get all the bits from up to three 165s, daisy chained. You need to set the SPI transaction width "one higher" than you are actually using; Set it to 16 bits for a single (8 bit) 165, or set it to 32 bits for two (16 bits) or three (24 bits) 165s.

The data you read in will be rotated and will contain repeated bits; e.g. reading from a single 165 with SPI set to 16 bits will give you a 16 bit value that needs to have bit 8 copied to bit 0, and then needs to be bitwise ANDed by 0xFF. The bit you copy into bit 0 will change for 16 and 32bit SPI modes, but it will always need copied over the LSB.

Workaround 2:
Use your own pin for PL, and tie SS on the PIC low. Set your pin to be idle high. To read, first toggle your pin low and back to high for at least one clock cycle. Next, wait at least one full clock cycle before issuing the SPI transaction, and write 0x1 in the transaction.

Your data will not be shifted, but the LSB will be lost; the data you read will have the state of D6 in both bit 0 and bit 1.

In both of the above cases, since SDO will be initialized low by SPI, the 165 will be continually shifting its output until you write the first 0x1 and the first read performed will be garbage. You might also need to clear the buffer overflow bit.

Disclaimer: I haven't tried either of these workarounds yet, but I have successfully read from a single 165 by using all 4 SPI wires and writing 0x81. This gives only 6 of the inputs as the MSB is prematurely shifted out by the frame pulse going low immediately before SDO goes low, and the LSB is never shifted out since the SDO LSB being set to 1 stops shifting. With this in mind, both of the workarounds should actually work.

On the good news front, of course the 74x165 works flawlessly if you drive all the pins yourself and don't use SPI.

Here are two scope traces of a read with 0x3B is present on the 74x165 inputs. First, how it looks under software (non SPI) control. This is all correct.
Image

Here is what the logic looks like when using SPI as I described. 0x3B is simply 0x77 shifted right by one. The LSB was lost. The MSB looks right, but is actually unusable as it's the unshifted LSB from the last transaction.

Image
alandsidel
 
Posts: 47
Joined: Thu Sep 23, 2010 10:54 pm

Re: UBW32 / General HWDev -- Adding inputs?

Postby alandsidel » Sun Apr 08, 2012 6:43 pm

Just pinging here in the hopes that Rich is still subscribed to the thread.. I registered a few days ago at the cpustick forums but changed my mind about a post before making it, little did I know I'd be locked as a 'spam' account for not posting! I'll be back that way eventually, but for now.. still here.

I haven't seen anything in the release notes for StickOS indicating that the "configure qspi ..." command has been implemented, or that (perhaps?) you intend to stop qspi_transfer() from always calling qspi_initialize(), which was blowing away the custom SPI config I'd set on the PIC whenever I used the qspi command to write or read. Has this been addressed yet in the latest stickOS and just forgot mention in the release notes, or is it off the radar now?

Also, an additional command to set the clock interval to something other than 250us would really be helpful. If there's an address for that I can poke at to change/set the interval or divider you're using to shorten the duration, I'd really appreciate it. The higher the clock speeds on the bus get, the harder it is to see multi-byte commands separated by long delays.

Again, thanks a ton for all the hard work you've put into the project! All is working now with SPI using the MCP23S08's. I ordered some MCP23008's (I2C) a while ago too, but can't find them now.. :oops: but no problem, I have 16bit versions of both on order for the next step in my development testing, as well as an MX7 pic so I can see the wonders of the MSSEN config flag in SPI. I still have a bunch of the 74xxx shift registers, and while they are nice parts on their own, just the fact that the MCP's have internal pullups is saving a lot of breadboard (and potential silk screen) space.
alandsidel
 
Posts: 47
Joined: Thu Sep 23, 2010 10:54 pm

Re: UBW32 / General HWDev -- Adding inputs?

Postby rtestardi » Mon Apr 09, 2012 3:38 pm

Hi,

I'm still subscribed here and I removed your deactivated account from cpustick.com forum, so you can recreate it (you can also always pick a new username, though I know that is less ideal).

I haven't seen anything in the release notes for StickOS indicating that the "configure qspi ..." command has been implemented, or that (perhaps?) you intend to stop qspi_transfer() from always calling qspi_initialize(), which was blowing away the custom SPI config I'd set on the PIC whenever I used the qspi command to write or read. Has this been addressed yet in the latest stickOS and just forgot mention in the release notes, or is it off the radar now?

That's still on the todo list -- I've been swamped with other (day job) tasks recently, unfortunately, so things are slow.

-- Rich
Embedded Systems Made Easy: http://www.cpustick.com
User avatar
rtestardi
 
Posts: 59
Joined: Tue Feb 17, 2009 3:01 pm
Location: Boulder, Colorado, USA

Previous

Return to USB Development

Who is online

Users browsing this forum: No registered users and 3 guests