Hi, I'm working on a set of modules for OpenScad to generate SoB cases. The idea is to create something people call with a single line of code and which can be both printed on a 3D printer or cut-out by a laser cutter. Many parameters can be changed for individual generation.
Attached is the openscad file and some screenshots. Would be glad if someone could test it. I couldn't test the real world results yet. Hence there might be rather big mistakes or errors.
ok I guess all my other posts condense now down to this. How to configure a PROM or FPGA via urjtag?
In Xilinx impact I can set different configuration options. However, those are NOT part of a generated SVF file. They are included in the impact project file (ipf).
Just copy over the svf file is therefore not enough. One has to make sure PROM or FPGA are correctly configured. How to do this within urjtag?
There is the instruction command and some other and I tried a bit around but couldn't see how this should work.
After solving this I guess I am ready to update the wiki ;)
just a quick question I couldn't find much info yet. I still try to program a xcf16p. However, the version of the board returns to be STEPPING 14. urJTAG only contains STEPPING 0 in its stepping file I added 14 so now the file looks like this
Just guess there is more work to do. Otherwise, all this stepping stuff in urJTAG would be kind of senseless. Any idea where or how to make sure its working for other stepping versions.
Hi, still struggling how to program the FPGA board. Since i wasn't sucessfull using urJTAG, I thought I give Xilinx "impact" and the open source Linux drivers a chance. It seems the drivers and hence the cable gets recognized. However, performing a "Initialize chain" ends up showing me a single device xc2c32a instead of two devices (one should be xc5vlx30).
I somehow feel the scan used the wrong port of the FTDI FT2232C Dual chip and hence showing me the CPLD used by the busblaster.
Can someone confirm this or tell me how to change the channel?
I still struggel to get the toolchain up and running for the above device. I got the Linux stuff working so far (at least I hope) Here is a dump of what is working. I will be verbose to make sure I do not overlook something obvious
So far all looks good I guess. I only have a MCS file from Xilinx ISE (no access to the sources yet). I called impact created a new project and importet the MCS file. I called the "One Step SVG" process which created a file default.svf
svf default.svf stop progress Error svf: mismatch at position 31 for TDO in input file between line 21 col 1 and line 21 col 72 error: Error occurred for SVF command, line 20, column 0-71: SDR. detail: Parsing 475240/475248 ( 99%)detail: detail: Mismatches occurred between scanned device output and expected TDO values. jtag>
At this point I have trouble. Either the SVF conversion did not went right or something else is wrong as you can see from the output. The board does not react anymore (its not bricked I guess just not correctly programmed).
I would highly appreciate if someone can give me a hand and help me with that.
Two points I would like to notice. The stepping for the FPGA was not available in urJTAG. I manually added:
It seems the wiki is a bit out of date and I would be glad if we could summarize the actual status. Here is what I did so far.
I use 64 bit Arch Linux system and used a AUR package (a receipt) to build and install urJTAG from SVN. The busblaster was nicely recognized by the ftdi_sio drivers. However, the package explicitly build urJTAG against the proprietary ftd2xx drivers. No idea if that is a personal preference or a requirement. Anyhow, those drivers came as dependencies in form of another Arch Linux package (thanks Arch).
I hate if program binaries call different compared to the software name esp. for CLI-tools ;) )
Furthermore, it seems not longer necessary to used a patched version of urJTAG to address the second interface (interface=1). This seems to work with the current build from urJTAG. However, the Arch AUR shipped a patch which took care of some long int and integer conversion. This problem was addressed here already and seems not to be upstream yet.
So the question remain. Could it work with the native drivers (ftdi_sio) and where are the pros and cons? Obvious one pro would be the fact that the ftdi_sio drivers are available on most systems without additional installation.
If we once get an up-to-date "How to use it under Linux" we might push it forward to the wiki.
I just had an idea for a website, programming, software thing. Since I do not work on web-development I just place the idea here and hope someone else like to pick it up.
Problem: Just looking out for a uC-chip with certain features. Frankly spoken, there are many uC from many different brands, Atmel, Microchip, Ti, Cypress, Hitachi, etc. Some of the feature set, are very similar and programming them in C blurs the boarders between different manufactures further. However, some features are unique and would be a win for a certain project. Most important might be the the particular combination of such features.
E.g. a not real world example Project requirement USB, DAC and ADC
ADC DAC USB Price per unit AVR: X - X $3 PIC: X X - $2 MSP430: X X X $5
Now, first of all it takes much time to scan all the different manufacture pages and do all the same parametric searches over and over. Secondly, the different prices as well as other features makes it difficult to compare them, Is a $5 all included uC solution cheaper compared to a $3 uC with an FTDI chip? Does the PIC in question come with ultralow-power mode comparable to the ultralow-power of the MSP430? How about the clock speed of the AVR compared to the PIC? The MSP430 is 16 bit but what was the bus-width of the PIC again? Keep in mind, in this simple example we took one uC of each manufacture, in real life, you would have to deal with different families and a bunch of possible chips of each manufacture already.
How great would it be to have a meta-search engine for uC. A parametric search which leads to all kind of possible uC. You specify your requirements in a parametric search and get PICs, AVRs, MSP430, etc. all side by side for a direct comparison.
I was looking around for some combination of photography and electronics. Searching the web there are already many DIY intervalometers, remote shutters, etc. projects. However, the majority of them use the dedicated remote control contact of certain cameras.
On the other hand many cameras feature a USB interface which provides a PTP protocol. This seems to be much more powerful and based on the camera you can remotely control many details of the camera . It supports transmission of the images too. PTP based libraries for PC are available with description of the generic PTP-protocol and the often found home-made forks of different camera manufactures. Most close project I found so far is from Oleg from http://www.circuitsathome.com/ He has already a nice PTP-library for AVR (ardunio) for different camera models.
Thus, I was wondering if there would be interest at DangerousPrototypes to get a remote control module which can be connected to most of the available cameras which features the PTP protocol. As far as I looked into it it would only require one and the same hardware (obviously it requires a USB host system) which should be a nice dedicated board.
As for the software, I would like to see a modular set-up. * Frontend: for the particular camera brand and model, contain the PTP commands for this particular camera. -> Talk to main module via API. * Main: something similar like the BP macro feature (some sort of primitive scripting language) to execute small programs on its own (intervalometer, focus stacking, HDR, sensor based triggering, etc.) as well as dealing with I/Os, maybe an OLED display, buttons, etc. -> Talk to backend and frontend via API * Backend: Communication to some host device, USB, bluetooth (smartphone / tablet app), wifi, other uC/embedded device (web platform), etc. Depending on backend images could be transferred directly, host can send scripts to the main module via backend. -> talk to main module via API.
This would result in a rather flexible set-up ranging from full stand-alone usability (executing the internal script) to automatic pushing of images to a server for automatized image post-processing and publishing. Well this is first of all a brainstorming info collection post. I would highly appreciate if you send ideas, thoughts, links and rants you have about this idea.
If I find enough people interested to overcome my inertia and certain plateaus of development, I would jump in.... Sure, important would be to get a group of testers with different camera modules too.
I just think about a new project which involves to figure out the exact communication between USB host and client devices. USB seems to get more and more universal and away from the traditional PC<->"dump stick" scheme. More and more uC come with host/otg and client capabilities. SoCs implement full USB support too. Many projects try to lower total cost by using cheap USB-based modules (wifi, bluetooth, memory) instead of the more pricey uC-interface modules.
Those embedded applications are tricky to debug. You can't snoop easily on the communication as you are used to do on a PC. An error could be user firmware or usb stack on the host side, electrical, or client side related. Thus, I wonder a buspirate which acts as a transparent USB bridge connected between a host and client could really be helpful to debug such systems. Logging the traffic and possible analyse it (e.g. filter by looking for keywords within the datagrams or package headers), could be interesting.
I know its an ambitious aim, since USB is rather complex compared to the low-level interchip protocols. Speed and amount of data are another issue. Thus, I can see it will not hit the feature list very soon. But maybe we could think about it in some distant future?!
Hi, this topic was briefly discussed here before. Many here know how difficult it could be to do good detailed images of your project. A lot of point and shoot cameras are not up to this (macro) task. DSLRs might work nice, however, you have to cash out a big chunk of money to get a decent macro lens. The reverse lens trick is well known among photographers.
Basically you mount an ordinary lens with the help of a reverse ring adapter upside down on the camera body. This turns a small focal length lens into a super-macro lens.
There are some pitfalls
On modern cameras you will loose all electronic features of the lens, unlike you hack the electrical connections back to contact your camera body again.
Another problem is the extreme small depth of field. There is usually only a very small focal plane inside the image crisp and sharp, elements before and after that starts to get blurry very quickly. However, that could be used as an advantage too, if you plan to set the viewers attention to a particular detail.
The other problem is light. It requires fare more light as usual to get a good macro shoot. Camera flashs are advisable and if you need longer shutter times you quickly have to switch over to use a tripod set-up.
The advantage is clearly the price. You can get a cheap second-hand manual lens and buy a reverse lens adapter for your DSLR. Some even use point and shoot cameras for that, however the camera need to feature a manual exposure setting mode then. Total cost to start with macro shoots could be as less as $20 / 20 Euro / 2000 Yen, if you own a camera and a suitable lens already. You might even consider to get a used DSLR like a Nikon D40 or older Canon EOS model which you can get rather cheap now. Those old cameras will still create great images even for other purposes. Get a reverse-ring adapter for your camera model might be a bit tricky since it is not the usual stuff your local electronic discounter keeps in stock.
Assemble the lens with the help of the adapter and set-up the camera to work in manual mode. Now you have to test a lot, it rather depends on the lens/camera combination as well as on your light/flash settings and the exposure settings. Luckily making some dozens of crappy images do not cost much on a digital camera. Finally you will figure out settings which serve your purpose well.
Another great feature of DSLRs (or digital cameras in general) is the possibility to allow further digital zooming on your PC. The size of the images are rather high esp. for DSLRs with many pixels. If you only want to publish the images online you might have to reduce there size already. You can easily cut out a desired part of the images and zoom-in even further without loosing to much image quality. Documentation does not require totally noise free and art-like images. As long as they clearly deliver the information you want to present, they are fine. However, taking some time to make them nice and high quality is defenitely a plus. Good projects deserve good pictures.
O.k., after all this blabla... here are some of my very first shoots with my new set-up
All images were taken without tripod and using only the internal camera flash without any additional light sources. I believe the results can be further improved by a light box set-up and a camera mounted on a fixed point like a tripod. Higher optical zooms can be achieved by using a 24 mm or 35 mm lens.
[attachment=4] Complete image scaled down: The buspirate V4 (marked area refers to the zoom below)
[attachment=3] Original size (100%) of the buspirate V4. Any solder bridges?
[attachment=2] Complete image scaled down: The buspirate V4 (marked area refers to the zoom below)
[attachment=1] Original size (100%) of the buspirate V4. All nicely soldered!
[attachment=0] Digital zoom (4x) of the buspirate V4. This big boy is a SMT cap check how big it is in reality!
I recently took an old counter from the university dumpster. It even worked. I was interested because of the nixie tubes. Had no use for the counter itself due to space constrains and the missing of some safety features. What a shame to destroy it.
However, taking the nixies out, I found a crystal oscillator the size of a big cap (round about 14 cm). Readings are Crystal oscillator Type: TCO-1P Freq: 1KC MFG No: 5554 Date: 42-3 could be 1942 or be Japanese calendar and hence it should point to 1968. 1942 sounds kind of unlikely (just guess, at that time Japanese were not keen to mark there products with English labels). Manufacture: Toyo Communication Equipment Co. Ltd.
I searched the web up and down but there is very little about this old crystals. Does anyone here have an idea or even better a principle of operation. It comes with a 8-pin tube plug (don't know the English name for it). However, only three were connected and two other bridged.
I would like to see if I could use it for some sort of post-modern steampunk set-up like getting an uC running on it, or rebuild a counter, etc.
Hi, out of a discussion on the blog I was wondering if one could use Openscad [1] and Eagle in a similar way like the exitsting Eagle3D and EagleUp projects. Openscad is a 3D modelling program which uses a scripting language as a core rather then a GUI. Unlike Povray (Eagle3D), which renderes an image, openscad creates 3D models which can be freely zoomed and rotated (like Sketchup). Using a scripting language makes it fesonable for a tool to generate automatic openscad-code from a PCB in eagle. Openscad is already well known in the 3D printer community. Its generated STL files can be feed into the printing toolchain. The idea would be to have a model of the PCB including the components, after that you could draw the required enclosure and make sure all fits together. Finally, you could print this enclousure on one of the 3D printers (commercial and DIY) avaiable.
One think to consider would be the fact that it make not much sens to create another project which requires yet another part-library. Therefore, I would believe one of the aims of this project would be to be able to read in existing part libs from EagleUp and maybe Eagle3D and generate automatically openscad models for it. Openscad can import STL files and hence this format might be a good starting point as an universal exchangable format between several projects.
Are there people around which are well known to SketchUp? I would like to know how easy it is to import and export STL-files into Sketchup.
Hi, I visited a second hand store the other day and they had dozens of this Photoframes laying around starting from 1600Yen / $20 / 15 Euro. I know several hacks (there is a very recent (and decent) one on Hack-a-day) how to use them as display for your own purpose.
However, there are hundred (thousand) different models and it would be tricky and time-consuming to figure out which one can be hacked and which one not.
(Nearly) all of them have an SD-card interface to store the images you like to show and many of them will load them from there to in a time-laps manner.
Thus, I was thinking if one can design a electronic which fakes on one side an SD-Card with a FAT-Filesystem and on the other side allow to write/replace images, unnoticed by the photo frame, it would be a general way to hack this cheap photoframes into something useful. Some USB->SDCARD would be nice, since once could hook up some of them to display whatever the PC is generating on-the-fly.
This system could be useful for other consumer electronic too. You could spy/read the data written to it during runtime (set-top -boxes, cameras, navigation systems, etc.), or you could inject data, etc.
It might be a rather nice approach of an attack vector to all these devices which rely on SD-cards for firmeware-upgrades too. ;) E.g. Let the device check and start to read in an official verified firmeware image but then suddenly copy the body of your own image over the existing image...
I just played a bit with the buspirate code and was trying to compile it. Since there is a makefile I thought it should work under Linux ;) Learned I have to use pic30-gcc.
I am using Arch Linux the two available packages are outdated already. I goggled a bit around but it seems not to be trivial to get pic30-gcc compiled for a Linux 64bit system. Now we have the new MPLabX and Microchip officially offer linux packages for the compiler.
Maybe someone here has some experience already?! Any idea which way to go?
And what is all the fuss about lite, full and eval... for god sake this is gcc
Hi, I just got my Logic Sniffer and hooked it up to my buspirate V3 to play a bit around. After pressing reset on the logicsniffer I had my first kernel panic after maybe 5 years.... O.k. here are some facts
Arch Linux 64 bit Kernel 3.1.5-1-ARCH on a DELL Optiplex 755 more details in the attached system.txt the other attachments list the logs after reboot (only the part just before the oops)
I have made a picture of the kernel panic message but its kind of blurry.
Now we come to the Christmas question, what was this. Random, by any chance caused by the buspirate (the logs are full of ttyUSB but not of CDC stuff), the logic sniffer (it happen instantly after pressing reset) Will we ever figure out :)
The reason I post this is simply I want to make sure its not a bug or problem with the buspirate or the logic sniffer.
