should take up 10 bytes in memory due to the tokenization that occurs, even though the text is 14 chars long. The format in memory is something like <0xE0 + length byte>,<line no high byte>,<line no low byte>, <line data>... So the above REM line would look like the following in memory:
You haven't really given any detail of how things are connected, nor what you're trying to do. Those would be useful. You may also be better off using their IRC or email address than posting here.
You don't want to be feeding 20v into the bus pirate. RS-485 and RS-422 are both balanced line, so they both have a pair of wires for TX. These two wires alternate polarity to indicate the signal level. Neither RS-485 nor RS-422 specify anything other than the physical layer, so don't be surprised if it's not a standard serial protocol. (on the other hand, it's not uncommon for a UART to be used, so you may still have joy)
If you don't have a suitable line receiver for this, you might be better off trying to tap the signal at a line driver or receiver and using that instead - at least it's more likely to be at a safer voltage for your bus pirate (5.5v or less!).
On the apparent inversion, don't worry, that's actually normal - if the line was low when idling you'd need to do some inversion. The bus pirate can handle this though.
The bus pirate's transparent mode only shuttles bytes between the two UARTs. There's no handling of flow control, and no handling of break signals.If you feel brave, you could always add a test for a framing error into UART.c and forward that as a break onto UART2.
[quote author="surfrock66"]I'm investigating a video broadcasting device for use of custom bit of code without license attribution; I have reason to believe this should be using a linux OS as firmware and the entire firmware should be <16MB.[/quote]
Given the very low specs of the N79E814AT20, bytes worth of RAM, no MMU, 8bit 8051 core and so on, I think it's highly unlikely to be running any version of Linux to be honest with you. I also doubt that it'll be pulling code over SPI, given the lack of RAM to store it all in.
[quote author="Couin"]a wire from the pin 3 (TX) of a DB9 connector, to RX hole of the module. [/quote]
You connected an RS232 serial port directly to the RX of the module? If that is the case, you may have killed your module, as RS232 voltage levels are too large for the module. The module only accepts 5V serial which is 0v for one and 5v for zero. RS232 is between -3 and -25v to send a one, and +3v to +25v to send a zero!
It looks like buspirate_port only appears in buspirate.c. There's a COMMAND_HANDLER buspirate_handle_port_command that appears to extract it, and a block of configuration that lets the rest of OpenOCD know what commands are supported. If you find buspirate_command_handlers[] in buspirate.c you will see it.
The net result is that the configuration buspirate_port is extracted from configuration commands, and sent to the buspirate JTAG module.
Ok, that is frustrating. Apologies for the misdirection.
A quick look at the source shows that in src/jtag/drivers/buspirate.c all the driver is actually doing is a straight open() of whatever serial port was provided in the config:
static int buspirate_serial_open(char *port) { int fd; fd = open(buspirate_port, O_RDWR | O_NOCTTY | O_NDELAY); return fd; }
The bus pirate driver doesn't appear to go anywhere near anything other than a standard serial port. If you're using only the bus pirate for JTAG, then I'd wonder if you could compile up without the FT2232 driver and save yourself the problems it gives you?
No, I haven't tested this, as I don't have a suitable toolchain on my machine.
To be honest, I always found pulling down Freddy Chopin's Windows OpenOCD build far easier than trying to go through all the hassle of compiling it yourself. Admittedly I've always used a bus blaster for this, not the bus pirate.
It would be nice to be able to simulate a I2C slave, but I don't believe the BP firmware can do this as it stands. The biggest issue is who provides the data to respond to the master, and how does it get to the BP in a timely manner?
When I needed to emulate an I2C device, I ended up using a PIC32 device (chipKit Uno FWIW) and chipKit's MPIDE to prototype it. There's no reason you can't use the BP device itself, as long as you're happy to write your own code to run on it.
You should just be able to send the data in the form "[0xAA 0xBB]", where "[" is assert SS, the two bytes are then transferred and the the "]" de-asserts SS. Admittedly, I confirmed this via a LA on a slightly hacked about 6.3 firmware, but I haven't altered the SPI code.
Are you sure that a 500KHz capture is fast enough? If the signal is I2C, operation speed can be up to 3.4MBit/sec, which I wouldn't want to sample any slower than about 15MHz.
Is there a difference between "hold down Update and press Reset" and "short PGC and PGD and press Reset"?
I understood that "hold down update and press reset" allowed you to update the FPGA bitstream, whereas "short PGC and PGD and press reset" allowed you to update the PIC firmware. The bootloader should turn up as a HID device rather than serial device.
