Skip to main content
Topic: Firmware v5.9 (Read 10400 times) previous topic - next topic

Firmware v5.9

-do some fixes to the PWM functions I didn't do last time
-make a v4 hardware port with microchip USB stack, abstract everything so we are ready for v4 hardware
Got a question? Please ask in the forum for the fastest answers.

Re: Firmware v5.9

Reply #1
I hope to finally implement a binmode for programming pic10/12/16.

Re: Firmware v5.9

Reply #2
Is it possible to add new function "Skip first N bytes" for buffer ?  N can be power of two.
eg. I run SPI sniffer, skip N is set to 256, byte 257 and more will be put in to buffer and display, it can be helpful with high speed transmission.

Re: Firmware v5.9

Reply #3
I'll take a look, but every addition to the sniffer loop reduces the maximum speed so it would need to be non-intrusive.
Got a question? Please ask in the forum for the fastest answers.

Re: Firmware v5.9

Reply #4
possibly the way to implement "skip-n", would be to buffer content internally,  just before it is sent via usb then have a "buffer" pointer which kicks in as it is sent over the usb.

Since currently the USARt is the bottle neck,  you could add a lot more processing before it would be noticed.

so to re-cap , spool from the chip into  round-robin ram,  then have a  round-robin pointer to feed the USB, at the start just load the "offset" into the pointer, automatically discarding the bits you do not want.

Re: Firmware v5.9

Reply #5
[quote author="hardcore"]
possibly the way to implement "skip-n", would be to buffer content internally,  just before it is sent via usb then have a "buffer" pointer which kicks in as it is sent over the usb.

Since currently the USARt is the bottle neck,  you could add a lot more processing before it would be noticed.

so to re-cap , spool from the chip into  round-robin ram,  then have a  round-robin pointer to feed the USB, at the start just load the "offset" into the pointer, automatically discarding the bits you do not want.
[/quote]

I do not think this would accomplish the desired result.  You would still be limited to the depth of the internal memory.  I believe the intent is basically to delay triggering until after a certain number of bytes.  I forget how big the buffer in the Bus Pirate is but, if it is N bytes long you might want to skip the first N or 2N or 3N, etc. bytes to capture all of a very long but fast repetitive data transfer.

I am not saying this would or would not be worth the time penalty to add to the sniffer loop, I was just trying to clarify what I think the intent was.

A more general solution might be to create a trigger loop that spins looking at each incoming byte until a trigger condition such as byte = X, X bytes received,  byte in range X,Y, etc.  Once this loop detects the trigger condition it could kick off the current sniffer loop.  This way there would be little to no additional delay added to the current sniffer loop.

I have only used the sniffer a few times but I recall that when it can't keep up it stops and gives an error.  What does it do if the buffer fills up?  Will it transfer everything in the buffer and then announce the buffer overrun or will it give an error as soon as the buffer overflows and stop there?  I think the desired behavior, especially when combined with a trigger condition would be to stop capturing as soon as the buffer overflows but before any old data in the buffer is overwritten.  This way if you had a data stream 5N bytes long you could capture the whole thing in N byte chunks without loosing any data (assuming the transfer was the same every time).

-Eric

Re: Firmware v5.9

Reply #6
Quote
What does it do if the buffer fills up?

If it can't keep up, or the buffer fills, it first dumps the valid data, then gives the error.
Got a question? Please ask in the forum for the fastest answers.

Re: Firmware v5.9

Reply #7
. I checked a new nightly into SVN, it includes a new digital IO mode that uses the same format as the bitbang mode. I've been using it to test the programming adapter because it has something connected to MISO:

WRITE: 0x00
DIO> v
Pinstates:
1.(BR)  2.(RD)  3.(OR)  4.(YW)  5.(GN)  6.(BL)  7.(PU)  8.(GR)  9.(WT)  0.(Blk)
GND     3.3V    5.0V    ADC     VPU     AUX     CLK     MOSI    CS      MISO
P       P       P       I       I       O       O       O       O       O
GND     3.34V   4.97V   4.36V   4.62V   L       L       L       L       H
DIO> 0b0000010
WRITE: 0x02
DIO> v
Pinstates:
1.(BR)  2.(RD)  3.(OR)  4.(YW)  5.(GN)  6.(BL)  7.(PU)  8.(GR)  9.(WT)  0.(Blk)
GND     3.3V    5.0V    ADC     VPU     AUX     CLK     MOSI    CS      MISO
P       P       P       I       I       O       O       O       O       I
GND     3.35V   4.98V   4.36V   0.00V   L       L       L       L       H
DIO>
Got a question? Please ask in the forum for the fastest answers.

Re: Firmware v5.9

Reply #8
Quote
[left arrow]            ^B             Moves the cursor left one character
   [right arrow]   ^F   Moves the cursor right one character
      ^A   Moves the cursor to the beginning of the line
      ^E   Moves the cursor to the end of the line
   [backspace]   ^H   Erases the character to the left of the cursor and moves the cursor left one character
   [delete]   ^D   Erases the character under (or to the right of) the cursor and moves the cursor left one character
Got a question? Please ask in the forum for the fastest answers.

Re: Firmware v5.9

Reply #9
I think I fixed the basic bugs Mike has reported in the support forum: http://dangerousprototypes.com/forum/in ... pic=1016.0

There were also a couple of other bugs around which are also fixed. However it doesn't fit anymore in flash, so I remove all but the basic protocols. I also made a firmware that has the addons protocols. Find both in the svn in the nightly folder.

Also remove the commandhistory command to make more room (still need to adjust the help) and fixed some errors in lcd protocol when compiled without spi.

Re: Firmware v5.9

Reply #10
*added I2C write/read command
*I fixed a silly mistake inthe buffer error int he SPI and I2C write/read commands
*cleaned some code (optimized mask statements)

To do:
*Check SPI bin mode speed settings (http://dangerousprototypes.com/forum/in ... 9#msg10759)
[s:]*integrate these changes: http://dangerousprototypes.com/forum/in ... 7#msg10767[/s:]
Got a question? Please ask in the forum for the fastest answers.

Re: Firmware v5.9

Reply #11
I was reworking the main to include the LCD mode, and I got confused on the MAXproto. It should be the included protocols +1 right, +1 for hiz?

Here's an updated compile with the extra changes:
http://the-bus-pirate.googlecode.com/sv ... e-v5.9.hex
Got a question? Please ask in the forum for the fastest answers.

Re: Firmware v5.9

Reply #12
yes, the hiz is also an mode. ;)

Re: Firmware v5.9

Reply #13
The binary mode ADC doesn't give the correct value. It does if you go into the terminal and do d/D first, but then it it wrong again on the next reset.
Got a question? Please ask in the forum for the fastest answers.

Re: Firmware v5.9

Reply #14
I'm porting v5.9 to the v4 hardware today, maybe the next release can support v4 too. Most of the immediate changes are complete, I
'll start debugging it soon.
Got a question? Please ask in the forum for the fastest answers.