Hi, I don't see why not. It doesn't seem like it would take too much space, so we could fit it in the BPv3... If you would provide the code, I'd be happy to integrate it into the firmware, test it out, and add it to the next betta release.
I would also be happy to help with the coding, but I haven't played around much with flashing chips. If you could provide more detailed instructions, I'd be happy to try and code it out...
[quote author="winso"]With firmware, in UART mode "Live monitor" can see only RX pin stream. What way to "RX-TX live monitor"? As "external uart" sniffer? I want to see all exchange between external devices on UART. Help me? I have v3 and v4 Bus pirate on hand. Thanks[/quote]
Sorry, bu this has not been implemented. But we might add it in a future release. The current firmware can only listen to one pin.
[quote author="winso"]What way for save start mode on v4 Pirate? For example, after reset, v4 auto go to Uart with saved port options? Eeprom on board - in manual i see "It will be used to store various settings and preferences." - ? - i not found more info about it
Thanks[/quote]
Hi, welcome to the forums. Sorry this function hasn't been implemented yet int the firmware... It's a future development feature.
Hi, up to v3.5 we used Vias with the D+ D- crosing each others' paths (uunderneathe) .. In V3,6 we fixed this with having one trace go around the SSOP pins... This makes one longer then the other, but there are no Vias on the Data traces, and no path crossing...
Do you thing we should revert to 3.5 layeout (Via's and path crossing), or keep 3.6 (longer lenght), which will produce less usb noise in the power supply.
[quote author="prazzb"]hello I just had a look at the code..... there seems to be some amount of unused code from the quick glance globals.h seems to be not included in any file... also contents from configwords.h are present in main.c you don't need both these files
[quote author="cybergibbons"]Just a quick heads up... after a post about power supply noise on a SparkFun Bus Pirate, I thought I'd check my SeeedStudio one as well. It exhibits a similar issue.
I have never had a problem with this noise before, but it might be worth bearing in mind if it matters to you, or if you are getting strange results.
Yeah we're here, sorry you're having issues with the programing this annoying flash. I haven't posted as I couldn't figure out what the problem could be. I'm sure someone who has more mobo-flashing experience will jump in. If not I'll forward this to Ian, when he gets back from his trip.
I have made one small project. I think others may be interested in buying my product. It is a simple PIC based board. I have already tested hand soldered board. Now I want to have something professional .
I am looking for cheaper way to have 20 units built.
Overall cost of components is around $30 per unit. It will be small PCB. ( At max 3 x 1.5 inches)
So what will be the reasonable cost for getting 20 units (PCB with components on it).
Which company should I contact ? Can Seeedstudio do it ? Do I have to pay everything upfront ?
I am looking for some advise from experts here.[/quote]
At 20 units, you're probably better off making them yourself, consider it a test run? if it sells, you can try kickstarter or indigogo to get funding for a higher run.
Thanks, I just wanted to check if it wasn't something that broke it in the latest release... Do you have another Linux computer you can check it on, just to rule out BP firmware/hardware error.
[quote author="arakis"]Hi, glad you got it working somewhat, In the SPI protocol the "[]" brackets are the start and end of message and designate when the CS pin has pin pulled low/high.. The bytes inside "()" brackets are the read bytes, as SPI sends and receives simultaneously.. Hope this helps.[/quote]
it seems you sending [0x01mast][e][r][1][7][7]['LF']
Hi, glad you got it working somewhat, In the SPI protocol the "[]" brackets are the start and end of message and designate when the CS pin has pin pulled low/high.. The bytes inside "()" brackets are the read bytes, as SPI sends and receives simultaneously.. Hope this helps.
[quote author="nowait"] So here are a few questions: 1. The cube would prob use around 20 LEDs (4 on each side). From what I understand, the colour is set using PWM on the RGB pins. Could I use say a transistor to set all 20 at once? And could this be done using a PIC or would I need an LED controller? 2. I was thinking about maybe getting some cheap vinyl stickers for the sides. By fashioning an unfolded cube with small tabs for overlap. But here comes my problem, I want the LED to light the entire section and not be one bright bit that dims towards the edge. I was thinking maybe using some clear perspex then spraying with glass frosting spray. Im hoping someone has a better idea than that!! :) 3. How much to build in a bluetooth module, roughly? 4. I was thinking around 100x100mm. Too small? Too big?
Thanks Ryan[/quote]
Hi, 1) I'd use the RGB LED strips.. ON them you get 4 wires, one for each color and one fro GND, all you need to do is apply voltage to each channel and all of them light up in that color. You will most defiantly have to use transistors to switch them on off. And yes a PIC can control them without a problem . Any PIC with at least 3 GPIO pins can do it, (which is all of them since 4 is the minimum)..I recommend one of the pic12F series(whichever one you can get cheaply next to you).
2) hmm, a diffused plexiglass, with milar foil (mirror) on one side (back), you align the RGB strips along the 4 edge sides.. this should keep the brightness more even along the whole plate..
3) all you need is a cheap bluetooth to serial module from ebay, and connect it to the UART pis of the microcontroller... So now you need number of pins the blutooth needs, + 3 RGB.. so move to a PIC16F, almost all will have a hardware UART, and enough pins.. Hope this helps..
be advised to program microcontrollers you''ll need a programer (cost around 30$), so an Arduino might be a better option..
