This is a old board I got a while back; I decided to take the board over for my own projects... but the transistor is confusing me a bit... I am not familure with SMD transistors but this looks backwards to me. I would assume they wanted the emittence to the pad not to the AVR. Here is what the transistor circuit looks like:
[attachment=0] (edit: the pin on the right (2nd up) is power and the bottom pin (bot left) is labeled 'SL' which if i remember correctly is 'status leds]
Also; if i remember correctly that pad the transistor is connected to was used to drive multi LEDs (using PWM for a fade effect).
Anyone familiar with smd transistors; am i correct that the schematic is wrong and its just a switch circuit to send power to SL and not the AVR?
that would be sweet, I can imagin it now. you have multiple 'games' on the code pages to put on the demo board. That would be sweet; burn through one learning new protocols and all that good stuff.
The bomb one would be awesome.It would be amazing as fudge if you had to use the bus pirate on differnt wires and such to try and figure out what its doing; thus figure out a way to disable it and such. Even bust out the OLS and multimeter and such!
I would totally purchase the demo board just for a game like that. Those would be as much fun programming them as playing them.
I have an idea for an idea I had just a minute ago and feel like testing it out (may end up being an interesting prototyping technique!).
What is awkward interfacing? Quite simply it is a completly random thought that occured to me while writing some RC5 receiver code for a project. :) But basically its interfacing one protocol (blind to it or not); using a different protocol. For example; lets say I had a device that spits out a code using some top secret protocol and encrypted 8 times and very complicated. But I wanted me device to do something when a certain code was sent from it. Lets also say there was a 'test' button on the target that when pressed it would send the secret code I want through the line. So my thought is well, lets hook up the BP to the target and enter some protocol/mode and hit that test button. Then I just might be able to adjust the settings on the BP (and/or my own device) to get a dependable list of bytes every time I press that test button.
So for example for my testing of this I hooked an IR circuit to the BP and entered UART mode and I was able to find dependable strings for each button press on 1200 baud I think it was. Looked something like:
So my thought it I could have an AVR sit in standby waiting for that string and perform a task when it gets it. and interfacing with a different protocol with minimal effort.
I really only fiddled with this for a few minutes; as I doubt I will use it any time soon (well maybe I will actually).
But my question Has anyone done this before for any reason? If so what where the results?
What are your thoughts on it? (maybe you like the idea, or have your own idea, or maybe you hate my guts just for thinking it)
Also; my first thought is UART is the best protocol to use for blindly interfacing with stuff because 1) its common on basically every IC I might want to do this on. 2) its easily adjustable. Do you guys agree UART is the best protocol to use? Or is there another one I should try? or do you feel it depends, and so on..
I really like the idea of this. In fact I think I could possibly even write an application that could find the best UART settings for you; and also find dependable strings.
What do you guys think?
Edit: Mods, If this is in the wrong forum; please move it for me and I apologize (Forum says 'Support' I didnt really think about that before I posted it.
I think the DP guys will need to verify this, as I have tried to use the following mode I am mentioning without success (but it was a 20% shot it would work anyhow, so I 100% doubt it was the BP why it didnt work for me).
Anyways; I think the macro (1) Transparent Bridge allows you to basically *Cut* the connection between something and insert the BP, so you can view the live transactions. I would assume you could possibly use the BP to do it something like connect a two devices to one (although thats no different then just running a wire... it just allows you to view).
Edit: OK I didnt read your thread enough. You want to record a transmition to playback at a different time... Ok, I dont know of a way of doing that with the stock interface (although I am not a designer of the product; so dont take my word as final.). I could see this done pretty easily with a microcontroller; as you can just get each byte and play it back later. Perhaps the custom scripting interface.
Good luck! if you need some code for an AVR to perform this task let me know; I could easily whip something up for ya. If you have AVRs and a programmer. (perhaps a PIC as well; GCC should be portable with minimal modifications if I use my portable coding method.)
Jawi; moving the screen didnt fix it but zooming OUT did.
It looks like instead of zooming to fit like 94, for some reason it zooms WAY WAY in. To far in I guess. Perhaps a trigger was removed that re-set the screen to 'zoom to fit' or somthing of that nature.
If still interested; here is the output: [attachment=0]
First Jawi, Awesome work on the OLS client. I absolutely love it. Perhaps I can help with some of the analyzers at some point; I often write my own protocol librarys when doing AVR projects, so I have a few projects that I may be able to port over to analyze! that would be sweet. I just have not taken the time to browse the source yet.
I did have a couple issues with the beta; one isnt a big deal just cosmetics the second is major.
First the before/after ratio is squished. I have seen this in 94 but just making the window a bit longer fixes it. but not in 95: [attachment=1]
Second; with the same settings as 94, I cannot see the captured data. It goes through the whole thing and says capute complete but it just doesnt show it! it just shows the channel numbers. [attachment=0]
If there is anything you would like me to try, just let me know. I am on windows xp.
Don't know if this is important anymore due to the space increase; but you should be able to decrease the size of m_onewire_213 by combining the onewire functions; they all share the same bit timeslots. So having a read and write bit function is repetative. Same with read write byte. You can just send a writebyte(0xFF) and the writebyte can return the bit values (return a byte) for you.
Of course I cannot test this. I did not install the PIC compiler yet. I will wait until I get a version 4 before I mess with my version 3. But the code (of course a bit differnt) is ported from an old project of mine thats tried and true.
unsigned char OWWriteByte(unsigned char b) { uint8_t i = 8, j; do { j = OWWriteBit( b & 1 ); b >>= 1; if( j ) { b |= 0x80;} } while( --i ); return b; }
unsigned char OWBit(unsigned char c){ //-- Write the bit to the port SDA=0; SDA_TRIS=0; //-- Lower the port bpDelayUS(5); //-- Time slot start time SDA_TRIS=c; //-- Output the data to the port bpDelayUS(14);//Wait until sample time c = SDA;//Get bit value bpDelayUS(60); //-- Finish Timeslot //bpDelayUS(5); SDA_TRIS=1; //-- Ensure Release of Port Pin bpDelayUS(D_RiseSpace); //-- Recovery time between Bits return c; }
I might have the data directions backwards on one or two changes; this is because im not used to changing directions by [call]=[val]. Im used to having to flip,set,and clear bits.
Of course I cannot compile it but its roughly a 30 lines less. and infact you could even turn some of the functions into defines and get it even more optimized.
Sorry for all the posts; but i think it looks cleaner if each idea is on a differnt post. hopfully you all dont mind :x
Also another idea for a protocol that could be on version 4 would be RC5 for remote control development. If we could hook up the bus pirate to a TSOP382 for example and it output the RC5 decoded value; that would be pretty sweet. I got to believe your IR-TOY already has code you could use for this to make it an easy addition.
Even more then just listening; what if you could hook the bus pirate up to an installed TSOP382 and 'inject' an RC5 code and the Bus Pirate send a stream that emulates what the remote would do. Then you could even connect the bus pirate to an IR LED and use it as a remote control; that would be super sweet.
Edit: I could even see there being an IR addon board (like the BP LCD board) that has an IR detector and IR emitter; and you could basically use it exactly like your IR-TOY just through the BP instead of direct. More monahs. I would for sure purchase that module for the BP.
another idea may be shift register controller.
I also have a few ideas for addon modules. Such as an RFID module to read RFID chips (I have not yet experimented with RFID myself, so I dont know what that all involves (like different Hz or whatever that might be)). Wireless module(s); Such as bluetooth,Zigbee / RF and so on. Then people could use the BP as there projects controller. I had more ideas I cant seem to recall at the moment. but if anyones interested in hearing them I would gladly jot them down.
I think there is a large possibility of expanding the bus pirate from something you take out to examine something with once and a while to a universal project controller. Especially through the use of direct control (using pearl or what have you). Thats when I think some of these specialized modules would really come in handly; I mean its basically being able to take control of your own project through USB without having to create a entire circuit for it. All you would have todo is code your own project to utilize the bus pirate in direct access mode and you could get pretty fancy. Forsure looking into expanding the direct control mode would eventually profit in many different aspects.
I sure hope im not out of line by saying any of this; Its just a thought, im in no way trying to tell you guys what you should do or how you should do it. I am just very interested in the BP project and enjoy it so much. I see alot of potential, not that its usless now, its already an amazing tool but I just see even MORE possibility.. sorry if im rambling.
Also, this is really sloppy but just an idea, in your base.h you are looking for a smart way to count the protocols enabled.
Perhaps instead of using
#if defined(PROTOCOL)
you could use #if (PROTOCOL)
then instead of enabling and disabling protocols by defining it; you define each protocol as 1(on) or 0(off) then you could count it. again this is very sloppy but it works.
I dont know if this is the right thread, but now that we have more space on v4, i thought it might be nice to add more 1wire devices and such. I had no internet all this morning so I basicly studied the firmware all day. (is the easter egg enabled? I see two easter eggs but both seem disabled, although a call is active? and seems to be compiled)...
anyways; So I added some 1wire devices to the list:(im not 100% how your BP echoing functions work but I tried my best to make it copy/pastable)
There was a couple more things but I have not prepared yet. Are you interested in seeing them? There all just minor changes like above no major changes to code or anything.
I would be honored to help on the version 4 firmware. Like I said before; im new to pic programming but not too C; im very experenced in C. So perhaps you guys can handle the major coding and I can help with some of the grunt work like above (stuff anyone can do its just time consuming and low level, I would be honored to help pick it up!).
Why dont you get some proto's PCB'd up? Perhaps you could partner with SEEED like DP and sell your modules with them? Or if you want to lone I would try ITead I hear they are the cheapest for prototyping (I hear they arnt very good for production though, seeed is tried and true in both respects though)
I had a neat idea. Im not sure if its worth doing but whatever..
Along the ideas of using the one controller to simulate a bunch of differnt devices and protocols; What if there was a sort of game. as in you start in simple UART and communicate with the controller to get the next protocol and clue.. and for example the next protocol/device is emulated EEPROM you log into that and dump the contents and its HEX that when you convert to ascii says something like; "Next use i2c and talk to the temp sensor at @ 0xA0. use the temp as the next address for a 1wire device."
So you slowly go through each protocol/device learning the protocol and also how to read data/turn hex into ascii/and so on.. It could even get advanced like use "use CRC32 on memory 0x22 through 0x25 on the PICS EEPROM for the next i2c device address". then they could even learn encryption and so fourth. Even throw in false data, like 1wire; you read it out but they didnt take the time to match the CRC byte at the end and have to backtrack or somthing.
Or something of that sorts; perhaps at the end you win an a updated firmware for the board that turns it into something useful so it doesn't get thrown away when finished.
Hey DP guys, I was just glancing the bus blaster page and noticed it says 3.3v levels. Is the bus blaster buffered in any way to use 5volt signals? I rarely use 3.3 when playing around (no real reason).
I think once the BP4 is out and ready at SEEED I will purchase a BB at the same time. I might need to get a level converter or make one though.
Oh I C. So you cannot use a trigger as the device is always going high-low rapidly due to garbage. Hm. Yeah.. I dont think there is any trigger pattern you could use for that specific task.
One idea is to hook the OLS up to the transmitter as well (common ground). Then you can trigger on the transmit instead of the receive. That would work, and you could see both the TX and RX signals... would be cool to see how much of a delay there is and how clean the signal is, so fourth...
Or set the transmitter up on the same common and hook the OLS up to the transmit button as well.. and have the trigger go off as soon as you press the button.? Would that work?
thats the great thing about having so many channels, you can hack yourself a solution to triggering the capture if need be.
Edit: Sorry tayken; I didnt mean to double your response. I didnt notice you mention the RX line, i was mainly looking at his responses!
