Hello,

I have an arduino uno with me which has an atmega32 on it. Since the code is compiled for a previous version with atmega16, how to I get the hex for Uno?

Some devices (Nokia 5110) require one more output line (Code/Data) in SPI mode.

Could some extra commands (parentheses?) please be added to Bus-ninja to handle this?

Example:

initialize (command)

[ ( 0x21 0x14 0xaf 0x20 0x0e 0x43 0x8f )

draw (data)

0x55 0xaa

deactivate SS

]

Once I got bus-ninja more or less working on Arduino, I proceeded to look if something like that is available for Launchpad, because I'd like to do experimentation/rapid prototyping with RF modules, and I have 1 Arduino and 1 Launchpad. Well, I immediately came to http://blog.hodgepig.org/2010/09/10/575/ by yourself ;-). I guess, it would be nice to mention that a Launchpad port/work-alike exists right at the http://blog.hodgepig.org/busninja/ , it would for sure add value. Also, could you please import Launchpad code to github?

Thanks!

You just add library.properties file and fill request at arduino github page, so this will pop up in arduino IDE for easy automatic installation by people.

Eg.: This project did just that: https://github.com/chatelao/MiniPirate

this project looks like just what I need but current master fails to compile.

There was a warning about an unused variable which got promoted to an error. Easily fixed.

Then I hit this :

led.c:89:23: error: variable 'led_sequences' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
 static const uint8_t *led_sequences[] PROGMEM =

now I could start trying to work it all out but presumably master should actually compile. So I'm wondering what is wrong here.

Adding support for either of the Bus Pirate protocols (binary or ASCII) will allow for Bus-ninja to be used as a AVR programmer, along with Avrdude.

It seems there's confusion in how bus-ninja handles SPI_SS and SPI_CS signals. SPI_SS is the native AVR SPI Slave Select signal. The issue, it is driven automatically by MCU only in slave mode. In master mode it is, well, just a GPIO, which is described in ATmega168 datasheet:

page 79:
SS: Slave Select input. When the SPI is enabled as a Slave, this pin is configured as an input
regardless of the setting of DDB2. As a Slave, the SPI is activated when this pin is driven low.
When the SPI is enabled as a Master, the data direction of this pin is controlled by DDB2.

page 162:
When configured as a Master, the SPI interface has no automatic control of the SS line. This
must be handled by user software before communication can start.

So, essentially, it is a convention that master will use the same SS signal, it could use any other GPIO (and in case of multiple slaves it will have to use different GPIOs as Slave Selects). But nonetheless, it is good convention to follow.

So, what's SPI_CS then? Answer: there's no such thing in SPI, and so its presence in bus-ninja is likely result of confusion, and leads to even more confusion for its users (took me some time to wade thru this stuff).

Suggested fix:

1. Remove SPI_CS defiinition.
2. Make hw_spi_cs_assert() & hw_spi_cs_deassert() to operate on SPI_SS.

After that, there may be feature request:
3. Make SPI_SS pin configurable, with default still being native MCU SS pin per datasheet.

Having some fairly arbitrary process running in the background possibly without user even knowing about it (for example, Arduino's led pin is apparently not correct) may lead to hard to understand failures and non-deterministic results. For example, it does interfere with SPI querying in my case, see below. With commented out calls to hw_led_* it all works reliably. Suggested fix: remove the hw_led_init() call during startup and hw_led_tick() in ISR.

[0x10 r:5]
CS ENABLED
WRITE: 0x10
READ: 0x0xE7
READ: 0x0xE7
READ: 0x0xE7
READ: 0x0xE7
READ: 0x0xE7
CS DISABLED
[0x10 r:5]
CS ENABLED
WRITE: 0x10
READ: 0x0xE0
READ: 0x0x00
READ: 0x0x00
READ: 0x0x00
READ: 0x0x00
CS DISABLED
[0x10 r:5]
CS ENABLED
WRITE: 0x10
READ: 0x0x0F
READ: 0x0x80
READ: 0x0x00
READ: 0x0x00
READ: 0x0x00
CS DISABLED
[0x10 r:5]
CS ENABLED
WRITE: 0x10
READ: 0x0xEF
READ: 0x0xFF
READ: 0x0xFF
READ: 0x0xFF
READ: 0x0xFF
CS DISABLED
[0x10 r:5]
CS ENABLED
WRITE: 0x10
READ: 0x0xF3
READ: 0x0xF3
READ: 0x0xFF
READ: 0x0x9F
READ: 0x0xE0
CS DISABLED
[0x10 r:5]
CS ENABLED
WRITE: 0x10
READ: 0x0xE7
READ: 0x0xE7
READ: 0x0xE7
READ: 0x0xE7
READ: 0x0xE7
CS DISABLED
[0x10 r:5]
CS ENABLED
WRITE: 0x10
READ: 0x0xFE
READ: 0x0x01
READ: 0x0xFF
READ: 0x0xFF
READ: 0x0x07
CS DISABLED

Can i use this for snooping on 3-wire SPI traffic?

In README there is SPI mentioned, but that is typicaly 4-wire. 3-wire SPI has MISO and MOSI combined in single wire, while using both falling and rising edges to trigger transfer of data in both directions...

... which are never pleasant to look at ;-).

Adding support for the cheaper ATmega8 MCU is easy. I have a patch, which I hope to test and send shortly.