Dangerous Prototypes

Current todo:

[s:]*Enable OpenOCD[/s:]: Note: OpenOCD currently not available for BPv4 due to lack of new USB system support. Added to Docs here: http://dangerousprototypes.com/docs/Bit ... _JTAG_mode (http://dangerousprototypes.com/docs/Bitbang#00000110_-_Enter_OpenOCD_JTAG_mode)

*A bunch of bug fixes I have flagged in the forum:
[s:]http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=1888[/s:]: Added advanced AUX control to I2C mode, documented here: http://dangerousprototypes.com/docs/I2C ... UX_command (http://dangerousprototypes.com/docs/I2C_%28binary%29#0x09_Extended_AUX_command)
[s:]http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=2275[/s:] : Added frequency counter access to BBIO mode. documented here: http://dangerousprototypes.com/docs/Bit ... on_AUX_pin (http://dangerousprototypes.com/docs/Bitbang#00010110_-_Frequency_measurement_on_AUX_pin)
[s:]http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=2576[/s:]: Vt100 home and end keys patch. Committed.  Thanks to http://code.google.com/p/the-bus-pirate ... tail?id=62 (http://code.google.com/p/the-bus-pirate/issues/detail?id=62)
[s:]http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=2975&p=29257#p29243[/s:]
Updated servo position, no longer disables if value is given. New mode does not show the disabled PWM message unless S is pressed without a value.New mode also loops as requested, enter the value and hit enter to update the servo. Hit x or enter to exit. Documentation updated: http://dangerousprototypes.com/docs/Bus ... de#S_Servo (http://dangerousprototypes.com/docs/Bus_Pirate_menu_options_guide#S_Servo)
New server guide from the feature author (not complete) here:
http://dangerousprototypes.com/docs/Bus ... umentation (http://dangerousprototypes.com/docs/Bus_Pirate_servo_driver_documentation)
[s:]http://dangerousprototypes.com/forum/viewtopic.php?f=41&t=2629[/s:] AVR Dude 40x speed improvement  Documentation: http://dangerousprototypes.com/docs/SPI_(binary (http://dangerousprototypes.com/docs/SPI_(binary))#AVR_Extended_Commands

New features:
[s:]*replace 1-Wire routines[/s:]
[s:]*UART autobaud[/s:]

From Brent:
* Added all UART_GETBAUD functions from static 'bpWline' to BPMSGs
* Reformated base.h a bit (moved the defines to the top) and added BUSPIRATEV2GO that just defines v3 anyways; just for no chance of confusion. and enabled BP_USE_BASIC and keyboard on v4 only.
* Removed the color labels on the 'v'
* fixed the '?' and 'v' glitch
* Added a BPMSG for v4 users who press #, it says no software reset on v4 use button
Edit: a few more
* removed hardwarev4.h its not used and matches hardwarev4a.h with some lines added. so i could tell its just some obsolete file; so removed it from the projects and deleted from SVN (revision excists if it needs to be brought back + I have backups)
* Added k/K to the ? menu (c/C/k/K Aux select (A1/CS/A2/A3)
* Moved the k/K from bpWstring to the v4 translation file (matches c now "a/A/@ now controls AUX2" for example)
More:
*Fixes for UART/SPI mode PPS
*Defined PPS in hardware setup
*Fixes to SPI slave (sniffer) PPS
*AUX1/2/3 fix

Alpha version a6:
*fixed AVRDUDE binmode issues in v4
*Fixed SPI mode issues in all modes in v4
*Fixed UART maybe (untested) in v4
*Fixed HD44780 LCD mode in v4


Need to:
[s:]*move different RPx pins to hardware profile defines[/s:]
[s:]*Check AUXpin freq, PWM, and servo functions[/s:]
[s:]*Uart autobaud to v4 only (size limitations)[/s:]
*Document new v4 stuff

1-wire added and tested. Committing and making firmware now (with video!)

Nice work! Where is the vid??

Btw i saw you uploaded into the regular svn instead of the bp svn. intentional?

30 more minutes to render the video, another 30 to upload. I'm not happy with the first video but I learned a ton and tomorrow's will be better :)

In the Bus Pirate OpenOCD source there is a call to binOpenOCDTapShiftFast but no function. In the history, the last version has binOpenOCDTapShift and there is a function. I'm going to revert to that for now. Maybe that is why it was left out of the v5.10 compile?

OpenOCD re-enabled, but found this bug. Reverted to old code and compiled ok.

[s:]http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=1888[/s:]: Added advanced AUX control to I2C mode, documented here: http://dangerousprototypes.com/docs/I2C ... UX_command (http://dangerousprototypes.com/docs/I2C_%28binary%29#0x09_Extended_AUX_command)
[s:]http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=2275[/s:] : Added frequency counter access to BBIO mode. documented here: http://dangerousprototypes.com/docs/Bit ... on_AUX_pin (http://dangerousprototypes.com/docs/Bitbang#00010110_-_Frequency_measurement_on_AUX_pin)
[s:]http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=2576[/s:]: Vt100 home and end keys patch. Committed.  Thanks to http://code.google.com/p/the-bus-pirate ... tail?id=62 (http://code.google.com/p/the-bus-pirate/issues/detail?id=62)

[s:]http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=2975&p=29257#p29243[/s:]
Updated servo position, no longer disables if value is given. New mode does not show the disabled PWM message unless S is pressed without a value.New mode also loops as requested, enter the value and hit enter to update the servo. Hit x or enter to exit. Documentation updated: http://dangerousprototypes.com/docs/Bus ... de#S_Servo (http://dangerousprototypes.com/docs/Bus_Pirate_menu_options_guide#S_Servo)
New server guide from the feature author (not complete) here:
http://dangerousprototypes.com/docs/Bus ... umentation (http://dangerousprototypes.com/docs/Bus_Pirate_servo_driver_documentation)

I added Brent's baud rate detection, but it seems to hang when run/the exit does not work (unlisted UART macro 4). I have not tried it yet though. It is also not a good idea to poll the PC-side UART directly because it is not compatible with Bus Pirate v4. I will pick up here tomorrow. For now, where is update package for Bus Pirate v3 and v4.

[quote author="ian"]I added Brent's baud rate detection, but it seems to hang when run/the exit does not work (unlisted UART macro 4). I have not tried it yet though. It is also not a good idea to poll the PC-side UART directly because it is not compatible with Bus Pirate v4. I will pick up here tomorrow. For now, where is update package for Bus Pirate v3 and v4.[/quote]

A note on the exit routine; basicly how that works is the MCU will sit in a nothing loop waiting for the MISO pin to have some activity; during that sit it is possible to leave and exit the procedure/macro (seemed to work for me; but I could have used the wrong UART variable or somthing; im still learning the PIC stuff). but once activity happens we exit that loop; from there you cannot exit until the procedure has sampled I think 15 times. The reason I left being able to exit at that point is simply becuase I need as fast as possible (i know ASM ASM... this works) when I had the emergency exit routine on the sample loops; this caused more cycles needed per loop and mind you the LOOP is nothing; its just a waiting loop so it needs to be quick; very quick.

To me the easiest solution is to just tell the user; for an emergency exit; pull the plug or press reset. otherwise we could adjust the super simple formula and make it work; but then you also lose higher sample speeds (higher bauds will no longer be able to be detected; even though we are already cut off at 20m)

edit: Oh you know; you didnt test it with actual UART data on the MISO line did you; im guessing your MISO line was hanging? Yeah; i never thought of that... During my testing i was always hooked up to a UART line (no data or data; but thats naturally high; so my starting wait loop is waiting for it to go low; this mean if your hanging pin is low you skip the loop that allows exiting and jump straight into the next wait which is waiting for a high again; which wont come...

ok i understand, so simply put; your floating pin is subverting my 'activity wait' because its expecting a UART line which is high; but that floating pin is most likely low. so you basicly jump bast the loop that allows exiting straight into the sample stage that doees NOT allow exiting and get hung waiting for the pin to do somthing.

I know how I can fix that; I will send you an updated routine in a minute. As for this happening again for whatever reason; perhaps I can add a quick check that sees how far the timers gotten and its gotten to far exit the routine due to lack of activity; though again this is a very time sensitive routine.. i dont know how bad that IF and COMPARE statment will slow down the sampling....

Edit2: Does the MISO line have an external interrupt? I think perhaps some point in the near future a major overhaul of that function should be performed utilizing an external interrupt instead of just wait loops; this will allow for smarter routines and emergency exiting no problem...

I think the easiest fix would be to have two waits; wait for a high then a low. Which should work fine; and allow exiting on both those waits. this will assure even if the pin is in an unwanted or unknown state; we can exit.

        while(BP_MISO==0 && U1STAbits.URXDA==0) {       // Wait for activity (stabilize)
                asm( "nop" );                                                   // you can exit by hitting any key at this point.
        }

        while(BP_MISO==1 && U1STAbits.URXDA==0) {       // Wait for activity (stabilize)
                asm( "nop" );                                                   // you can exit by hitting any key at this point.
        }
        
        if (U1STAbits.URXDA==1) {                                       // Emergency Exit.
                i=U1RXREG;                                                              // Get rid of the char from queue
                UARTgetbaud_clrTimer();
                bpWline("nr** Early Exit...nr");
                return 0;
        }
        

That should work.. for now.

let me know if the miso line has an external interrupt and if its possible for me to use it...


so just add

       while(BP_MISO==0 && U1STAbits.URXDA==0) {       // Wait for activity (stabilize)
                asm( "nop" );                                                   // you can exit by hitting any key at this point.
        }

right below the IF(dataonly)==0{then say:"Awaiting Activity"}

right above its brother (only one char changed)

BTW: I got like 5 boxes today.. digikey, my itead gift, even my TI 5$ dev board.. I was so hoping one of those boxes was the BP but it wasnt :( soon though im sure)

Ok i just got back home from work and compiled that little update and tested; yep that floating pin sure did cause it to fall into the sample loop and get stuck. So with this little update its fixed; its acutally good because it gives the user time to connect the MISO pin if he has not already..

unsigned long UARTgetbaud(int DataOnly)
{
	unsigned int i=0;
	unsigned long CurrentSample=0,BitSample=0;

	// CalculatedBaud define just for readability
	#define CalculatedBaud BitSample

	UART2Disable();	//Disable UART
	BP_MISO=0;
	BP_MISO_DIR=1;


	if(DataOnly==0) {
		bpWline("Awaiting Activity...nr(Notice: Any key to exit at this point only...)nr");
	}
	
	while(BP_MISO==0 && U1STAbits.URXDA==0) {	// This first wait is incase the user has not yet connected the MISO pin to a UART
		asm( "nop" );							// bus. If the user HAS connected it; then this wait will be skipped (miso=1)
	}
	
	while(BP_MISO==1 && U1STAbits.URXDA==0) {	// Wait for activity (stabilize)
		asm( "nop" );							// you can exit by hitting any key at this point.
	}
	
	if (U1STAbits.URXDA==1) {					// Emergency Exit.
		i=U1RXREG;								// Get rid of the char from queue
		UARTgetbaud_clrTimer();
		bpWline("nr** Early Exit...nr");
		return 0;
	}

and you can  easily exit before the sampling stage by pressing any key. Now the strings just need to be setup in the translation ability way..

This function actually works pretty well

UART>(60)
Awaiting Activity...
(Notice: Any key to exit at this point only...)


Actual Calculated Baud Rate:    115942 bps (Estimated)
Nearest Common Baud Rate:      115200 bps

End of Function. Good bye.

UART>(60)
Awaiting Activity...
(Notice: Any key to exit at this point only...)


Actual Calculated Baud Rate:    115942 bps (Estimated)
Nearest Common Baud Rate:      115200 bps

End of Function. Good bye.

UART>(60)
Awaiting Activity...
(Notice: Any key to exit at this point only...)


Actual Calculated Baud Rate:    115942 bps (Estimated)
Nearest Common Baud Rate:      115200 bps

End of Function. Good bye.

I will forsure keep looking on ways to improve it and updated it as more ideas and ability appear. Perhaps I will test and see if I can get AutoBaud to work on bridge mode...

Also a small glitch upon reset; you get some scrabled chars

UART>#
REÿ
Bus Pirate v3b
Firmware v6.0-a4  Bootloader v4.4
DEVID:0x0447 REVID:0x3043 (24FJ64GA002 B5)
http://dangerousprototypes.com (http://dangerousprototypes.com)
HiZ>$

So I think that BPMSG1093; is not pointing to anyhting (I couldnt find the string attached to 1572 i think it was. So I commented that out and built it again to see if it went away; and the RE did (is RE supposed to be there?) but it still leaves the 'y'

HiZ>#ÿ
Bus Pirate v3b
Firmware v6.0-a4  Bootloader v4.4
DEVID:0x0447 REVID:0x3043 (24FJ64GA002 B5)
http://dangerousprototypes.com (http://dangerousprototypes.com)

Also why is 1wire_lib.c and m_1_wire_213.c there? Cant you delete the m_1_wire now?

Thanks for the update. I'll roll it in today and test out the code.

RE should be RESET, seems like a bug.

Yes, the old 1-wire can be deleted.

Woo; I stepped outside at work when I got back in a little box was on my desk from SEEED! My BP v4 is here! So not to bad; just over 10 days. Thats not that bad.. I also got some other goodies but the BP4 was the main guy.

Yeah! Now you can join me on BPv4 duties ;) Give me a shout if you need any help with v4.

roger. :D im still at work; but as soon as i get home (and my dog calms down; gets his walk and some dinner) then I shall begin... :D

Question; What about this EEPROM? Any code written for it yet? What procol does it use (pin count looks i2c)?

Also can the user yet connect to it? Or what are your ideas for connecting to it? Are i2c already available on the pins its connected too? or will software i2c be needed?

Whats going on here

#define BP_MAIN
//#define BP_ADDONS

#if defined(BP_MAIN)
#define BP_USE_1WIRE
//#ifndef BUSPIRATEV4
#define BP_USE_HWUART //hardware uart (now also MIDI)
//#endif
#define BP_USE_I2C
//#define BP_USE_I2C_HW
#define BP_USE_HWSPI //hardware spi
#define BP_USE_RAW2WIRE
#define BP_USE_RAW3WIRE
//#define BP_USE_PCATKB
#define BP_USE_LCD // include HD44780 LCD library
//#define BP_USE_PIC
#define BP_USE_DIO //binary mode
#elif defined(BP_ADDONS)
// most used protos
//#define BP_USE_1WIRE
//#define BP_USE_HWUART //hardware uart (now also MIDI)
//#define BP_USE_I2C
//#define BP_USE_I2C_HW
//#define BP_USE_HWSPI //hardware spi
#define BP_USE_RAW2WIRE
#define BP_USE_RAW3WIRE
#define BP_USE_PCATKB
#define BP_USE_LCD // include HD44780 LCD library
#define BP_USE_PIC
#define BP_USE_DIO //binary mode
#else
#error "No Bus Pirate configuration defined."
#endif

Shouldnt V4 allow all of these not the same as v3?

[quote author="BrentBXR"]Question; What about this EEPROM? Any code written for it yet? What procol does it use (pin count looks i2c)?

Also can the user yet connect to it? Or what are your ideas for connecting to it? Are i2c already available on the pins its connected too? or will software i2c be needed?[/quote]

there is support for the onboard eeprom. in the i2c submode you can use a macro to use the onboard eeprom instead of the i2c pins on the header.

Shouldnt V4 allow all of these not the same as v3?

Short answer is yes. We need separate config files for v3/v4, maybe separate base.h or a smaller subset, so we don't have to change the version define every time. Instead we can just include the v3/v4 file in the v3/v4 project and it will work right away.

Also add fix USB led; I liked seeing the activity this doesnt show it. also instead of taking out the software reset; just have it go back to Hiz mode and set everything to default. that will be better.

also fix 'v'; the text is off. you need to change
   .pascii   "12.(RD)t11.(BR)t10.(BK)t9.(WT)t8.(GR)t7.(PU)t6.(BL)t5.(GN)t4.(YW)t3.(OR)t2.(RD)t1.(BR)"
to
   .pascii   "12.(RD)t11.(BR)t10.(BLK)t9.(WT)t8.(GR)t7.(PU)t6.(BL)t5.(GN)t4.(YW)t3.(OR)t2.(RD)t1.(BR)"

there isnt enough room. and i guess that means fix BPMSG right? can someone explain how that BPMSG thing works? Offset and Lenfth? offset of what in en_US?

i can send you some fixes.

Also the menu is messed up '?'.

Listen; This weekend I will be starting a 11day vacation and really enjoy working on the BP. So if it would be possible; could you give me access to a seperate portion of the SVN? Then over the my vacation (I plan to play with it alot :D) I can fix all these little issues in my own little SVN; then at some point you can test out my build and go through the code and if you like it and trust it; you can commit it to a real release? I mean alot of these issues are pretty simple its just I cant really help because it would take more work to write up a document on whats wrong with it and the fix; then it would be to fix it (i know you will find and fix them at some point; but i mean as I find them too).

To edit the text in "en_US.s" and "en_US.h" you need to edit the "bpstrings_en_US.txt" and run it trough this little java script (http://http://code.google.com/p/the-bus-pirate/source/browse/v5.newterm/newtermtools/textconvert.html) Sjaak made.
It then gives you a new en_US.s and the en_US.h with the modified text.

In the help menu it needs an new entry for the new "e" command to tell how the pullups work on the BPv4.
Also need a way to control the new AUX pins.

[quote author="pietja"]To edit the text in "en_US.s" and "en_US.h" you need to edit the "bpstrings_en_US.txt" and run it trough this little java script (http://http://code.google.com/p/the-bus-pirate/source/browse/v5.newterm/newtermtools/textconvert.html) Sjaak made.
It then gives you a new en_US.s and the en_US.h with the modified text.

In the help menu it needs an new entry for the new "e" command to tell how the pullups work on the BPv4.
Also need a way to control the new AUX pins.[/quote]

Adding: You still need to edit the en_US.s. in the BPstrings I could't use the ';' in the strings (it is the seperator) so I used the '.' (line 323).

I'm sorry for not documenting this properly.

Ok I see there is a 'translation.exe' now; can I use that? So if I want to fix one simple line all I have to do is edit it in bpstrings_en_US.txt and run it with  translation.exe and the generated files are good to go? Or do I still need to edit en_US.s?

The 'v' command string needs one letter taken out; So use that as an example what would I do from start to finish?

I got this question on IRC from a flashrom developer:

<carldani> do you think it would be possible to get a repeat-command-until-x command into the BP firmware?
<carldani> for SPI flash chip writing we have to check the result of a flash status register access until the busy bit is clear, and that takes a round trip each time
<_Sjaak> like :
<_Sjaak> while(!stop) { if(read()&0x01) stop=1; }
<carldani> stop=0; timeout=1000; while (!stop && timeout >0) { spi_cs_active(); spi_send_onebyte(0x05); if spi_read_onebyte()&0x01 stop=1; timeout--;}; return !stop;
<_Sjaak> i guess it is possible 
<_Sjaak> is this a general function, i.e. for all spi roms the same?
<carldani> all SPI roms used in x86 mainboards, but that's a useful subset

@ian: can this integrated into the spi binmode flashrom uses? This will boost there performance big time.

[quote author="BrentBXR"]Ok I see there is a 'translation.exe' now; can I use that? So if I want to fix one simple line all I have to do is edit it in bpstrings_en_US.txt and run it with  translation.exe and the generated files are good to go? Or do I still need to edit en_US.s?

The 'v' command string needs one letter taken out; So use that as an example what would I do from start to finish?[/quote]

You still needs to edit the en_US.s as I described. I saw your commit, but it contains the error in the help for the ';' command.

Thanks Sjaak!

Admittedly the code I suggested is not 100% optimal for the given case. The following variant would be better:

stop=0;
timeout=1000;
while (!stop && timeout >0) {
  spi_cs_active();
  spi_send_onebyte(0x05);
  tmp=spi_read_onebyte();
  spi_cs_inactive();
  if (tmp&0x01) stop=1;
  timeout--;
}
return tmp;

tmp is what the program interfacing with the Bus Pirate should see as return value.

The timeout value is debatable, I'm not sure if hardcoding 1000 is a good idea or if that value should be a parameter of the command.

gotcha

Also what are the advantages of doing the message system like this? I see a issue that that text must be compiled even if you have a v3 build and dont have the space.

So why did you guys move away from just defines?

[quote author="BrentBXR"]Also what are the advantages of doing the message system like this? I see a issue that that text must be compiled even if you have a v3 build and dont have the space.

So why did you guys move away from just defines?[/quote]

If we store the text this way it is 33% stored more efficiently then just storing the string by #define string "blaat". Read through the newterm topic (i think) for a better explanation.

I think we should move to v3 and v4 text file. Besides that some of the text should move to its corresponding protocol to even further reduces the occupied space. However we try to reuse string whenever we can. Also the names should be more descriptive then just BPMSG1234.

Edit: Alright I split the translation files into 2 a v3 and v4

Is this tortusSVN pretty good at keeping up to date? I really dont want to accidently overwrite somone elses work and mess things up. So is it safe to say that the icons are usually good; or is it wise to always run the repo-browser first and make sure no one has an item locked or changes before I last updated?

and if im working on somthing; should I lock it? or do you guys not normally do that?

@Sjaak

I have split up the v3 and below and v4 translation files into two and made them automatic by selected hardware version and what project you open (BPv4.mcp or BusPirate.mcp (v3)) but whats annoying if we add anything to the v4 that needs to be in v3 we have to add it to both and compile them both again...

I was thinking perhaps you could edit your textconvert.html so we can do this:

BPMSG####;X1;X2;"<TEXT>"

Where X1 = new line after string

and X2 = if 1 then use in both; and 0 = v4 only. and your script generates two of each. A version 3 and v4 H and S files.

Can you do that? that would save me alot of time...

Also please include #ifdef LANGUAGE_EN_US/#endif to the top and bottom of them all; so I can just copy-all and paste into the files instead of having to scroll through and just overwrite the defines

One other thing; instead of replacing ';'s with '.'s perhaps we should use $SC$ then we could do a simple find/replace (find: $SC$ rep: ';') that would be cool too!

let me know if you can do that! Thanks!

Just a note; the BP v4 hardware/firmware does not seem to work with AVRDude anymore. Im pretty sure its because there is no software reset anymore. So I even tried removed the reset message back to juist 'RESET' to see if I could fool avrdude into thinking we reset but that did not work either.

You can see on the output; AVRdude sends a reset; so I responded 'RESET' then I guess AVRdude sends an 'enter' command and gets a 'HIZ>' and avrdude says 'what?' and closes.

After a reset in v3 what happens after you press enter? what is avrdude expecting... Although I think the best solution would be to ask the AVRdude guys to make a 'buspiratev4' version that just ignores the software reset and perhaps we could add a hidden menu item for them to know if the buspirate is in a 'fresh' state and ready to be controlled...? just a thought.

avrdude uses binmode SPI for programming avr uCs. FTDI was keeping the COM channel in v3 but as in v4 we have the PIC handling virtual COM port stuff, when it gets reset, the COM port also disappears temporarily. I guess this is the main problem.

I swear someone got a patch to AVRdude to stop parsing the info header and not reset. It is really a bad dependency and messes up a lot.

A hidden reset command on BPv4 that prints RESET and also shows the info display might fool it.

Translate.exe should process the .txt into the two files, that was the goal. It may be temperamental though, so double check it.

1) I tried that; I made a custom build that had the BP mimic exactly what the BP3 would say (RESETnrBP Version 3.5anr) and just RESET.. The weird thing is it looks like its been fooled and looks like its sending 0x00 to try and break into binBB but it never gets there and after like 100 0x00's it gives us. So i dontknow whats up with that.

2) using the .exe seems to comout wrong for me..

[quote author="BrentBXR"]1) I tried that; I made a custom build that had the BP mimic exactly what the BP3 would say (RESETnrBP Version 3.5anr) and just RESET.. The weird thing is it looks like its been fooled and looks like its sending 0x00 to try and break into binBB but it never gets there and after like 100 0x00's it gives us. So i dontknow whats up with that.[/quote]
It is waiting for a repply form BP. When BP enters binary mode, it sends a message "BBIO1", probably avrdude is waiting for this. Try sending "BBIO1" after about 20 0x00 are received.

BBIO1 should still be sent once it enters it right? If I send BIO1 then AVRdude will think ints in that mode when its not?

Yes, it is the message sent right after it enters binary mode. avrdude is checking that condition right after it sends a couple of 0x00 messages to make it enter binary mode. Check out the source code for avrdude + BP binmode in DP wiki for more info.

thats what im saying; so your saying not just send BBIO1 but actually put it into that mode when # is pressed

[quote author="BrentBXR"]thats what im saying; so your saying not just send BBIO1 but actually put it into that mode when # is pressed[/quote]
Nope, when # is pressed (which may not be the case, binary mode has a seperate reset message, 0b00001111) send the bogus reset message, avrdude will send you some 0x00, if you are not resetting the BP and you are not actually in binary mode, then you don't have to do anything, you'll receive a bunch of 0x00 from avrdude (trying to put BP into binary mode), if BP is not in binary mode already, then it will get into binary mode by itself and send BBIO1, this is what avrdude is waiting in order to start bitbanging the pins in order to program.

You might want to try ascii mode too, avrdude supports that as well (for older versions of BP, ie v1), it is slower but no need for binary stuff.

Check out bitbang mode page (http://http://dangerousprototypes.com/docs/Bitbang), avrdude manual for 5.11.1 (http://http://download.savannah.gnu.org/releases/avrdude/avrdude-doc-5.11.1.pdf) and buspirate.c file from avrdude source for 5.11.1 (http://http://download.savannah.gnu.org/releases/avrdude/avrdude-5.11.1.tar.gz).

I added some define checks to base.h that set the version based on the hardware. Now no more swapping to compile v3/v4 :)

Also added avrdude 40x improvement patch. Testing v3 now, will test v4 next.

Alpha version a6:
*fixed AVRDUDE binmode issues in v4
*Fixed SPI mode issues in all modes in v4
*Fixed UART maybe (untested) in v4
*Fixed HD44780 LCD mode in v4

Need to:
*move different RPx pins to hardware profile defines
*Check AUXpin freq, PWM, and servo functions

With all the changes lately and the new a6 version i updates my BP again.

I noticed that the naming of the AUX pins is not constant throughout the interface.

In the "v" menu the pins are called:

AUX2
AUX1
AUX
CS

However in the Help menu they are called different:

c/C/k/K AUX assignment (A1/CS/A2/A3)

HiZ>c
a/A/@ controls AUX pin
HiZ>C
a/A/@ controls CS pin
HiZ>k
a/A/@ controls AUX2 pin
HiZ>K
a/A/@ controls AUX3 pin

Would it be better to number the AUX pins starting with "0" in the help menu:

c/C/k/K AUX assignment (AUX/CS/AUX1/AUX2)

HiZ>c
a/A/@ controls AUX pin
HiZ>C
a/A/@ controls CS pin
HiZ>k
a/A/@ controls AUX1 pin
HiZ>K
a/A/@ controls AUX2 pin

This way the user interface is constant with the PCB markings.

my bad :3 ill fix right now

commited; a new build will need to be performed. Good time upgrading Ian caught a huge issue and most of it was resolved earlier today.

Brent also added:
Fixes for UART/SPI mode PPS
Defined PPS in hardware setup
Fixes to SPI slave (sniffer) PPS
AUX1/2/3 fixes

Thanks Brent!

:D not a prob. I also just updated hardware4a again. I added

more 'NORMAL' button support including a 'BP_BUTTON_ISDOWN()' define; so if its down then true else false. simple.

I added the only other broken out PIN PPS, the ADC pin. for future use.

And i moved the EEPROM defines into it including: Enable/Disable/Check Write Protection, EEPROM Addressing (N/R/W), and the MIN and MAX values.

We are so close to v6!.

Oh I also added a 11th option to the 'Select UART BAUD rate' when entering UART mode that allows the user to auto-detect the baud rate and it will setup UART for you. Along those lines I had to make a simple math to generate the correct BRG, could we replace 'Input manual BRG' with 'Input manual BAUD rate'? and just use that same equation?

That would be great. We need to keep brg only on v3 I think due to space limitations.

I am packaging a v6 release, about time. I've done a ton of testing, but at this point I think it is time to unleash it and see what happens. Here is a screenshot of autobaud, it works well but seems to be slightly off for me. This is interfacing an IR Toy USB2UART at 19200bps. It rounded 5000 up instead of 3000 down, which I think would be closer. Sill plenty functional, and a fantastic new feature. I think in next update I will make it available by macro too, so you can easily attempt to get the baud multiple times.

---

Aw; yes the nearest common baud rate deal is not a great function. I will try and make it a bit 'smarter'. Did you LA the IRTOY to see the true baud?

No, I didn't go that far. I will do some testing for v6.1 though.

Hi,

it always puzzled me that the pirate-loader source code comes with a little shell script instead of a makefile.
My muscle memory always let me type make as soon as I see a .c file somewhere ;)
So here it is.... a makefile for pirate-loader.
It should do exactly the same like the shell script.
If people are interested we might add rules to do the entire update process.
like e.g., make upload to finally push the new firmware to the bus-pirate.

There might be better options to do that like e.g. scons, however, 'GNU make' might be available on all systems which comes with a GCC.

I can't test this for FreeBSD and Mac... but it works so far under Linux.

There was problem with the 6.0 source. The shell script was looking for the pirate-loader source in a subfolder ./source which does not exist. The source code is directly placed in the main source code folder of the pirate-loader.

Rename the file to makefile... can't upload it without file extension

Thank you so much, I committed this to SVN and it will be in the next release.