Skip to main content

Show Posts

This section allows you to view all Show Posts made by this member. Note that you can only see Show Posts made in areas you currently have access to.

Messages - cuagn

General discussion / Flatcam
I've bought a Chinese CNC a couple of months ago, and I was still looking for the "god link" between Gerber/Excellon files (Kicad output) and the G-Code driver.
An open source solution is on the build by JC Caram.
It's Python based and is working fine even if some improvements (goodies)  may be required.
Have a look here :


General discussion / [closed]: Single row connector kit
As most of amateur I face the difficulties of not only what should be the connectors of a circuit but also to buy them somewhere. As a Ham radio, I also have to consider the RF part, but that’s another story. As a hacker, there is now the 2mm standard, single or dual in line.

Up to now, in order to avoid, either a bad plugging or more dangerous, an inversion of signals, I’ve made the choice of using HE10 (dual) or polarized connectors (SIL).

By the way, I bought a crimper and a lot of parts (contacts, housing and male connectors for PCB).
However, I always had the need to connect to a “basic” single row header when devices are already made when arriving on the workbench (PicKit3, shielduino, Logic sniffer, …)

Then the only solution was to use old cables found in old desktop.
There are always a lot of things to be connected to a mainboard (reset, leds …).
But this parts source is no more available or rare, as broken laptop have replaced desktop.

A little bit tired to crimp in one case, or to search in boxes if I still have the required used cable with the “good” connector, I’m very interested in having nothing to crimp AND avoiding time spent searching for an unlikely existing cable in my boxes.
The solution was in the announcement of the connector kit (http://

Unfortunately six months later it’s not available.

Thanks to [tayken] I’ve received two sample kits two weeks ago.

Each kit contains:
2 x  2 pin (1×2)
2 x  3 pin (1×3)
2 x  4 pin (1×4)
2 x  5 pin (1×5)
2 x 6 pin (1×6)
1x 20 wire rainbow ribbon cable with crimped pins (100 mm)
… and a sticker Dangerous Prototypes.

Sure, there is no difficulty to insert a contact in one hole of the housing.
More interesting, if you make a mistake, it’s easy to remove the contact, from inside the housing.

Does-it means that all is perfect?

I don’t think so and I’m a little bit concerned by the length and the quantity of the cables.

The kit is announced with:
2x 40 wire rainbow ribbon cable with crimped pins (100 mm)
2x 40 wire rainbow ribbon cable with crimped pins (180 mm)
1x 40 wire rainbow ribbon cable with crimped pins (300 mm)

The 100 mm is useful only for connecting two adjacent cards.
I’m integrating a lot of cards in a 1U rack. With connectors on the front or rear panel which are to be solder. The 180 mm and 300mm are required cutting one end contact.

Just to highlight the fact that I don’t need headers in 2.54 (as in the sample kit) and I would prefer to have more cables

To conclude, I think that such a kit is needed to have the basis out of any specific requirement of a given assembly.
In this case there are other ways to get a lot of specific wires.



PS : I should have posted in ... cable-kit/
I close this thread and make a link in the right pace
General discussion / Gerber to HPGL converter
I’ve already asked this question somewhere, may be in another forum, but I didn’t receive any operational answer (just the one like “Google is your friend…”)

I'm a pure hobbyist player. (Ham radio). I started designing PCB many (many) years ago, using MSDOS tools with a HPGL plotter and the result was good enough. Then I moved to Windows, and my outdated former solution was no more working.
The basic free solution I'm still using is ExpressPCB, with a laser printer.
Quick, simple, free but very specific and not used by hobbyist communities. 
More, the laser printing, and by the way the final result, is not as good as expected (like a HPGL plotter is).

Now, it's time to move to Eagle, in order to have a real PCB design capability.

However, Eagle also (as far as I understand, but I may be wrong) doesn’t enable a HPGL output.

I’m quite sure that someone, somewhere has written a good Gerber to HPGL translator.
At least for basic PCB this may be fine for prototyping.

Does somebody have successfully tried a such converter? Which one?

Thank you

Bus Blaster JTAG debugger / Re: Some questions with OpenOCD / Win7
Hi ian,

I did not test (up to now) your solution with FT_PROG as I just wanted to unbrick my Dockstar.

It seems to be the solution to my question and ... our problem.

By the way, I think that this issue (and solution) may be documented in the Wiki as many people may have the same problem.

From my point of view, I don't see (own usage) an advantage of having a specific PID allocated by FTDI.
You may have another view with a DP global business approach.

Thank you for your answer.


PS : not terminated, but unbrick of Dockstar is on the way. Very efficient data transfer through BusBlaster with OpenOCD. Thank you.

PS2 : any idea with libftdi version ?
Bus Blaster JTAG debugger / Re: Some questions with OpenOCD / Win7
Tnks, but ...this means that we have to "swap" the drivers according to the usage we have of a FT2232H device. Not really optimal.
And more, it is not possible to have at the same time Busblaster AND another FT2232H for a native virtual port.
I had expected the ability to change (using eprom ?) the the PID of the busblaster. Could it be possible ?
Bus Blaster JTAG debugger / [resolved] Some questions with OpenOCD / Win7
Situation before
I’m working under Win7 Pro.
I’m also owning a DP FT2232H breakout board.
By the way the initial situation is that default FTDI drivers are installed on my computer, either for my old FT232HL serial converter or for the FT2232H dual converter.

Nota : I use USBDeview (see here) to get a synthetic view of the USB environment on my PC. A nice freeware!

All devices with VID=0403 (FTDI)

I’ve 3 virtual COM ports when I look to Device manager (click to see the screen copy)
That’s normal!

More details thanks to USBDeview:

Generic Microsoft parent for FT2232H (click to see the screen copy)
Interface A (click to see the screen copy)
Interface B (click to see the screen copy)
Serial converter FT232HL (click to see the screen copy)

Everything is working fine…

The issue…

I’ve received my DP BusBlaster (V2.0a) a couple of weeks ago.
Need first to adapt connectors to try to de-brick a Dockstar (Seagate Pogoplug) device and I decided to go with OpenOCD.
I installed the required USB environment, according to the WIKI setup

1. Install a driver (libUSB)
2. …

So did I, using the libusb documentation here.
The last version is (dated April 12th). See here.

“Starting from version, the inf-wizard.exe has embedded driver binaries and provide an option to install the driver at the end of the process.”

Fine, a few clicks and the driver is installed for both interfaces of FT2232H.
Interface 0 (click to see the screen copy)
Interface 1 (click to see the screen copy)

This is confirmed by testlibusb (click to see the screen copy)

Looking to Device Manager, I’m not happy however: the corresponding virtual ports have disappeared.

Note : the drivers are in a specific libusb-win32 devices group.

Which means that I can’t use the DP FT2232H breakout board.

But what about OpenOCD?
Just download (here) and install it…

The first strange and contradictory information is :

“OpenOCD 0.4.0 for Windows. An msi installer of complete package and it's md5 checksum. Due to alleged GPLv2 license incompatibility of using ftd2xx.dll libraries, this version was compiled to use libftdi + libusb-win32 libraries.”

Hmmm. DP wiki says that libusb is required but OpenOCD says that libftdi is required too.
What about libftdi?

As a result of the OpenOCD installation, a libftdi.dll and a libusb0.dll are included in the same directory of openocd.exe.
Fine, but this libfdti.dll may be a little old.
Let’s go here
Last version is from yesterday : 2011-05-23: Version 0.19 of libftdi released
No libftdi.dll is included and I did not find a way to generate it.

The good point is that at the end, I start openocd which seems to work (even with some difficulties at this time, but on the board side, ie. Dockstar)

Questions :

1 - I’ve lost the virtual ports for all the VID=0403 PID=6010 devices. How to fix this issue ?
2 – How to run with the last libftdi under windows ?

I may have some wrong understanding, but up to now, I do not find how.

Any idea ?

USB Infrared Toy / Re: Re: Compiling the FW
[quote author="ian"]I only use MPLABC, I have never tried the HI-Tech C compiler.

Fine. That's a choice. I don't think it's really an issue for our goals.

I'll provide the "post-install.bat" soon, in order to copy the required files in the right directory.
USB Infrared Toy / Re: Compiling the FW
You're welcome...

Two remarks :

1/ which C compiler do think it's better to use ?
HI-Tech C or MPLAB C?
Both exists in LITE (freeware) version (see here)

2/ by the way, it implies that the delivered svn project files should comply with such implementation... as soon as possible

A tiny and easy to do improvement could be a .bat file, copying only the useful (ie.required) files from the global Microchip Application Library to the DP specific subset in C:Microchip SolutionsMicrochip... :)
USB Infrared Toy / Re: Re: Compiling the FW
[quote author="ian"]Due to operating system differences, drive differences, and non-distributable code, I'm not sure how to implement a common instillation. I'm open to suggestions though. ...[/quote]


Here are my suggestions :

This is a proposal for a standard installation of MicroChip tools under MS WINDOWS
It may be a complement (if agreed) to this document : ... C_projects

-   This is a proposal for an installation on a MS Windows workstation.
MPLAX (Linux, Mac) are out of the scope
-   Tools are installed according to the normal Microsoft way, ie. in the disk drive C: and in the “programs” directory. If you are running a 64bits version of Windows, there are two directories for the programs:
      C:/Program Files (x86)   for 32 bits programs
      C:/Program Files   for 64 bits programs
MPLAB will be installed in C:/Program Files (x86)/Microchip
-   Sources, either the personal ones or the Dangerous Prototypes ones (the svn structure) or the examples provided by Microchip are installed where the user wants, as it’s difficult to define a general method. It may be on any drive and directory, including the Microsoft approach of directories bellow C:/Users (I personally hate this approach…)

Doing this requires some changes in the projects definitions. Some will be automatically prompted by MPLAB, some (link libraries or include for example) will imply “errors” unless changes are made in the project build options.

For the moment I just implement MPLAB_IDE, mplabc18 and a subset (the required parts for USB programming) of Microchip USB Framework.

Remarks : we have the choice for the C compiler. I’ve decided  to go with MPLABC18.

In other words, we install the useful environment to compile the firmware of the following devices:

Project    PIC
USB IR Toy    18F2550
Flash Destroyer    18F2550
Logic Sniffer    18F24J50

Three Microchip installation files are required (versions on April 1st 2011) ... t=SW007002

mplabc18-v3_37_01-lite-installer.exe ... irects=c18 ... e=en547784

Installing the tools

Install first MPLAB. You will be required to restart the computer.
Then, install C18 compiler.
For both installations, accept the default options, including directories.

As a result, everything will be installed in
C:Program Files (x86)Microchip

Installing Microchip Application Library

In this huge library, we will find a lot of examples, not all being useful for the different FW compilation.
Only the subdirectory Microchip is useful even if not for it’s whole content.

My proposal is to install the library wherever the user want’s, but to have (at least), the required sub part of the Microchip subdirectory installed on the C: drive
C:Microchip SolutionsMicrochip

We will need access to some ”Licensed” c files
usb_device.c   <install path>MicrochipUSB
usb_function_cdc.c   <install path>MicrochipUSBCDC Host Driver
usb_descriptors.c   <install path> USB Device - CDC - Basic DemoCDC - Basic Demo - Firmware
and also to a lot of .h files.

So the C:Microchip SolutionsMicrochip directory will contain
<install path>MicrochipUSB
<install path>MicrochipInclude
and we will add
<install path> USB Device - CDC - Basic DemoCDC - Basic Demo – Firmware usb_descriptors.c
C:Microchip SolutionsMicrochipUSBCDC Device Driver

By the way, at least until svn version 775, you should modify the (svndangerous-prototypes-open-hardwareUSBIRtoyIRtoy-firmwareglobals.h (starting line 27) in order to use the right directory.

Quite easy to do, and after no more difficulties as sources are where everybody wants and Microchip environment is standardized.


Project development, ideas, and suggestions / Re: Eagle Tips and Tricks
Hi arhi,

That's clear, I would like a HPGL output.

I'm not so sure that a Gerber translator will do the job as easily (1:1) because of the pen plotter size.
May be...

I will search on the web, but I assume that if you don't know a solution, probably there is none :(

Thank you