Hi, on Tokyo Make Ian was talking about the pain of testing and verification of populated PCBs. Basically, for very high volumes, you would set-up a test card with prober-pins which fits exactly to your board. Then you run a bunch of tests measuring voltages, currents, maybe even serial com, etc. and compare them with some specs. Either you use some dedicated test equipment or you build up your own testing circuit. Getting a test-card with prober-pins is expensive and not really practical if you only have small batch volumes.
There might be different solutions to this problem. One could limit the position of test/debug pads/vias on a rather big raster. E.g., 0.5x0.5cm^2. Now one could assemble the required test pins into a base containing holes with the exact same raster pattern. This would already speed up things a lot.
Another idea would be the design of a standard test-pad pattern. E.g., somewhere on the PCB you will find 4x4 1x1mm pads or vias. This gives 16 test connections to proof functionality and the same test-probe could be used over and over again for different designs. However, it would require to route signal lines to this pattern and this might have some negative influence on the signal integrity.
Looking at the Dangerous Prototype logo I was wondering one could even utilise the logo itself as some kind of debug/test pattern. This would save the need to make space for another pattern and has some sort of geeky factor. E.g. telling people during troubleshooting, "please measure the voltage between the line and the dot of the exclamation mark" :) . However, this would require additional routing too.
I like the idea that open hardware includes some kind of easy and open testing/debugging features. If it could be standardized in some manner it would be even better and if it would be the logo it could be some kind of extra for DP-recognition.
Unfortunately, there are a lot of these flimsy, out-of-focus, barely sound, shaking, mobile phone camera "presentations" too.
I believe a good project deserves a good presentation. Thus, what do people use (hard- and software like) to create (video) presentations. Sure OpenSource solutions are favoured.
Hi, maybe a strange question. I found a very unique way to use the buspirate. If it works out, I will definitely write up some how-to. However, for this method I would need to send several charactes in one go to the buspirate. I'm not going to use the binary mode but simply write e.g. m/n3/n8/n1/n1/n1/n1/n to enter the UART mode. It is similar like copy commands from a textfile and paste them into a terminal shell. However if I try this, both under screen and minicom, the input stops at e.g. the forth command, despite the fact that the others are send too. Do I hit any buffer or time limit? There were some discussions about increasing the delay time between carriage returns ein the case of copy and paste text, but it sound that at least much more then 4 commands should work out of the box. Any idea?
just was trying to use the buspirate in transparent UART mode to program an Arduino which comes without USB interface (no USB serial bridge). I followed Ians description in a similar post. As far as I understood, I have to enter UART mode, and make sure the buspirate is using the same speed on the PC side, the actual software (Arduino IDE or AVRdude) are using (using the "b" command). The buspirate tells me... Please adjust your terminal settings Press space to continue.
However, whatever I tried I was not able to reconnect. I can open the serial port, but there is no communication with the buspirate. No garbage, nothing, simply plain dead. There is even no echo of any key-press.
I used screen and minicom with no luck. PB v3a is on the last firmeware-version 5.10 (IIRC) Host is Arch Linux
Thanks for helping
Torwag
CC. I basically, do not see the reason why I have to change the speed twice. First I set it up for UART mode and then for the PC side. I can see some use for the terminal mode. However, as soon as someone starts the transparent macro, I would say there is no need for different speeds. Can't we simply set the PC-site datarate to whatever was selected in the UART mode within the macro? Guess this might be something many people trap into.
