Dangerous Prototypes

-Any requested changes and extension to servo and PWM
-unify the two PWM functions

Any plans for a 16-bit word size SPI sniffer mode?

Sjaak is adding 9+bit I/O in terminal mode (software libraries).

How would it work for the sniffer? What is the difference between a 16bit sniffer and combining 2 8bit bytes from the sniffer?

My idea was to set MODE16 bit in the SPI Control register when running the sniffer. Will combining 2 8bit bytes give the same result?

Yes. We can do it in hardware, but it just combined two 8 bit bytes (0x90 0x80 becomes 0x9080). It is much simpler (thus faster snooping with more features) if you do it on the host computer instead.

I'm working on an SPI sniffer app right now, hopefully it will be working in a few minutes. It could be modded to spit out 16bit (or any number of bit) words if you like.

I did not get to work last time i tried. I will need to test again.

Just to be sure that we talk about the same thing. If you look in the data sheet below on page 10 at the bottom  this is how the bus behaves. It is 16 bits per SELECT transaction.
http://www.hoperf.com/upfile/RF01.pdf (http://http://www.hoperf.com/upfile/RF01.pdf)

Timing diagram attached. 16bits is just 2 8bit bytes, it should work. You could try with the most recently updated firmware. It's possible that the bus is too fast and the Bus Pirate can't keep up.

---

The bus speed is 32kHz so it should work. I will try it during the weekend. Thanks!

To do:
SPI polarity macros
LCD - pins HiZ when not used?
ring buffer return error flag on overflow

In another topic, we discussed how 16-bit SPI is different from two 8-bit SPI transactions because the Chip Select stays constant throughout the 16-bit word but transitions twice for two 8-bit words.

If you're bit-banging, with Chip Select called via subroutine, then you could implement it as "select, send8, send8, deselect" but if you're using hardware SPI then they're not equivalent.

16-bit SPI is different from two 8-bit SPI transactions because the Chip Select stays constant throughout the 16-bit word but transitions twice for two 8-bit words

Isn't that only for auto frame sync on high-speed devices where DMA transfers are involved? The Bus Pirate doesn't use/support auto frame sync (yet). The CS line is controlled manually via the [ and ] commands.

8bit SPI write: [0x00]
16bit SPI write: [0x00 0x00]

[quote author="ian"]The Bus Pirate doesn't use/support auto frame sync (yet). The CS line is controlled manually via the [ and ] commands.

8bit SPI write: [0x00]
16bit SPI write: [0x00 0x00]
[/quote]OK, that sounds like it should work.  Like I said, if you're bit-banging then you can manually control the select and deselect.  Sorry for the distraction.  I don't use the Bus Pirate, but I do code for several SPI chips on various processors, and it seems like every SPI peripheral has a different flavor.  Some require the frame sync even without DMA, but depending upon how the clock is controlled it might not matter.  Just beware that it could be an issue, and you can see how it goes in the real world.  It might even be necessary to add alternate modes to support chips that are a little different, or at least that fits my experience.

No worries! Thank you so much. I always appreciate another set of eyes on the design. I'll so some investigating of the frame sync in the PIC24 and see if we can do something nifty or useful with it.

Just checked in r491:

- fixed bug in basic scripting engine ( http://dangerousprototypes.com/forum/in ... opic=906.0 (http://dangerousprototypes.com/forum/index.php?topic=906.0) )
- updated the nightly builds.

Just checked in r492 into the svn:

- partial read/write are extended to max 16 bit
- only the bits used in partial read/write are displayed
- autoswiching between 8  and 16 bit display
- no need to enter 'NEW' when entering the first program into the scripting engine.
- updated the nighly builts

NB: only raw2wire and raw3wire support partial and 16bit write ATM.

some examples of the altered display:

2WIRE> 0xFFFF
WRITE: 0xFF
2WIRE> 0xFFFF;16
WRITE: 0xFFFF
2WIRE> 0xFFFF;12
WRITE: 0x0FFF;12
2WIRE> 0xAA;8
WRITE: 0xAA
2WIRE> 0x5A;4
WRITE: 0x0A;4

Also updated the wiki to reflect the changes..

I need to look at adding 9bit writes to the UART mode with your new command. It is a config option, but there is no way to do it :)

There wasn't much activity here, so I decided to bump this thread a bit ;)

I added 9 bit comms to the UART library. When 9 bits is selected, the numbits is automatically set.

Shall we also add 8bit, mark (1) and 8bit, space (0) as data/parity option?

Fantastic. We should do a release this week, there's some good updates in the SVN.

Is the 8bit mark and space a way of always setting the 9th bit to the same value?

[quote author="ian"]
Is the 8bit mark and space a way of always setting the 9th bit to the same value?
[/quote]

To my understanding it is. We could do the same for 7 bits.

Hey Sjaak - are your changes documented in the wiki yet?

I added documentation for the new SPI macros and SPI binary flashrom command today. I'll try to add anything you have added too.

the parial write is documented. Fixing the UART is just a bugfix ;)

I didn't add Mark/Space to parity to the firmware

Thanks! I'll compile and release this tomorrow.

Running way late today, but I'm going to compile and release this now.

Here's the changelog I added to the post:

    *  SPI sniffer updates
    * new fast SPI write/read command for flashrom
    * added SPI settings macros to change phase/polarity/clock edge on the fly
    * added continuous binary ADC sampling for oscilloscope
    * fixed bug in basic scripting engine
    * partial read/write are extended to max 16 bit (currently raw2wire, raw3wire only)
    * only the bits used in partial read/write are displayed
    * auto-switching between 8  and 16 bit display
    * no need to enter 'NEW' when entering the first program into the scripting engine
    * added 9 bit coms to the UART library. When 9 bits is selected, the numbits is automatically set

Hi,

It's been a while.

Is the MODE16 for SPI in BP accessible in this firmware version already?

I believe so, though you might want to check the latest firmware for all the updates:
http://dangerousprototypes.com/docs/Bus_Pirate#Download (http://dangerousprototypes.com/docs/Bus_Pirate#Download)