K8055 Open Source Project

Kits PC Related Projects
101

[quote=“MostlyHarmless”]I have made a couple substantial changes to the firmware as well as the client code.

[ul][li]All shared libraries are now independent of each other. If your program only needs K8055D.DLL, you only need to copy/install that one. It has the necessary parts of other libraries statically linked in.
[/li]
[li]The Tcl/Tk demo code now uses a proper binding library, that can be installed as a package. All that is needed to run the demos is an installation of ActiveState Tcl/Tk 8.5, then having the demo.tcl or demo_digital_out.tcl together with tclk8055m.dll in one directory.
[/li]
[li]The above obsoletes the k8055control.exe command line utility. It was removed to avoid keeping slowly rotting code around.
[/li]
[li]The Standard Servo digital output mode is fully implemented. I will post another thread with a more detailed explanation. This functionality is entirely interrupt driven. It required to move interrupt priorities around, but all that is transparent.[/li][/ul]

All of those changes are available in the 2012-07-02 developers snapshot or via the github repository.[/quote]

nice work

what is the purpose os the “ActiveState Tcl/Tk” by the way?

102

[quote=“diogoc”]
nice work

what is the purpose os the “ActiveState Tcl/Tk” by the way?[/quote]

Thanks.

Tcl/Tk is a scripting language, that I use for over 15 years now. It is available for almost every OS and the scripts behave more or less identical on Windows and Unix. That includes the GUI part (Tk). Those two scripts, demo.tcl and demo_digital_out.tcl are complete GUI applications that use event driven callbacks to turn your button/checkbox clicks and slider drags into USB commands for the K8055M. And they get another callback from the tclk8055m.dll when you press a button on the K8055M or when an analog input value changes.

The language has an awkward syntax, which prevented it from becoming popular. But it is very powerful and I’m used to it. So I use it to test the firmware and API libraries.

103

[quote=“MostlyHarmless”][quote=“diogoc”]
nice work

what is the purpose os the “ActiveState Tcl/Tk” by the way?[/quote]

Thanks.

Tcl/Tk is a scripting language, that I use for over 15 years now. It is available for almost every OS and the scripts behave more or less identical on Windows and Unix. That includes the GUI part (Tk). Those two scripts, demo.tcl and demo_digital_out.tcl are complete GUI applications that use event driven callbacks to turn your button/checkbox clicks and slider drags into USB commands for the K8055M. And they get another callback from the tclk8055m.dll when you press a button on the K8055M or when an analog input value changes.

The language has an awkward syntax, which prevented it from becoming popular. But it is very powerful and I’m used to it. So I use it to test the firmware and API libraries.[/quote]

I´m more familiar with the .net programming languages.
When I get some free time I will try to replicate you demo programs

104

Hi.

Great work on the driver. Now I’m able to use the board in Linux!

I used the latest source from Github. The firmware for the PIC compiled just fine. But I had some trouble with the client driver.

First of all:
k8055m.c:2444:5: error: unknown type name ‘libusb_device_descriptor’
and:
k8055legacy.c:827:5: error: unknown type name ‘libusb_device_descriptor’
both needed “struct” ahead

After that I got it to compile the driver. But when I implement the library in my program, I get the error: “ERROR k8055m_open(): libusb_set_configuration(): Device or resource busy”
From the dmesg output I learned that the problem is that the kernel’s usbhid driver claims the board.

Investigating in the k8055m.c file in the DeviceOpen() function (from line 2496 and further) I noticed the libusb_set_configuration() is being called before the libusb_detach_kernel_driver().

After I swapped it I was able to connect to the board without errors.

Currently I’m working on a GTK demo in C, just like the demos provided with the SDK.

Kind regards,

Piele

105

[quote=“piele”]Hi.

Great work on the driver. Now I’m able to use the board in Linux!

I used the latest source from Github. The firmware for the PIC compiled just fine. But I had some trouble with the client driver.[/quote]

Thank you.

Please note that I am no longer working on that branch and have started over from scratch as explained here: viewtopic.php?f=3&t=8429

The new stuff does work on the K8055N/VM110N with it’s original PIC18F24J50 too. I have not published any of that yet. I will do that as soon as I have all the base functionality back. Right now I only have digital inputs and outputs.

[quote=“piele”]First of all:
k8055m.c:2444:5: error: unknown type name ‘libusb_device_descriptor’
and:
k8055legacy.c:827:5: error: unknown type name ‘libusb_device_descriptor’
both needed “struct” ahead[/quote]

That is interesting. I never compiled it under Linux. The libusb included in my FreeBSD base system is version 0.1.12, which is still the latest in the ports collection. In that version the definition is

typedef struct libusb_device_descriptor { ... } libusb_device_descriptor;

Which means that it should work with or without the “struct” keyword. What version of libusb is your Linux distribution using?

[quote=“piele”]After that I got it to compile the driver. But when I implement the library in my program, I get the error: “ERROR k8055m_open(): libusb_set_configuration(): Device or resource busy”
From the dmesg output I learned that the problem is that the kernel’s usbhid driver claims the board.

Investigating in the k8055m.c file in the DeviceOpen() function (from line 2496 and further) I noticed the libusb_set_configuration() is being called before the libusb_detach_kernel_driver().

After I swapped it I was able to connect to the board without errors.[/quote]

Apparently my FreeBSD installation (8.1) doesn’t attach a kernel driver then. I probably should create some Linux VM for testing. I think I have some CentOS 64 Bit install ISOs on my laptop … somewhere …

[quote=“piele”]Currently I’m working on a GTK demo in C, just like the demos provided with the SDK.

Kind regards,

Piele[/quote]
Something like that would be nice to include.

Likewise I installed Visual C++ 2008 in my PIC development VM and am coding the new demo in that. I normally don’t do development on Windows. This PIC related stuff is the exception.

I do not plan to make the new client library backwards compatible with legacy boards. It will only work with the Open Source Firmware. Instead I want to create a service/deamon process that will manage the boards and then add network connectivity to the client library, so that programs can access remote cards.

Regards,
Jan

106

This project is nowhere close to exceeding the 25X50 models memory. But yes, once it gets there, one can step up to the 26x50’s. I only hope that by then there is a PIC18F26K50 or something similar.

About the PIC32MX250F128B, looking at the data sheet I think it would take some serious modifications to the K8055N to make that work. I don’t think the pinout is compatible. Probably easier to etch my own PCB, but I’d have to look deeper into it.

I am not sure what HEX file you think I should get. Much of the Open8055 project is about creating new Firmware for a flash PIC installed on a K8055(N). Firmware that exceeds the original capabilities of the K8055(N). The rest is about using that firmware with its PC side counterparts. Is it possible that I “create” those HEX files, you suggest to “get”?

107

simonvav,

I suggest you type “k8055 hid bootloader” into Google. There is no need to turn the board into a programmer. The firmware can be programmed into a PIC18F2550 or PIC18F25K50 right through the USB port. You only need to write the bootloader into the chip once with a programmer. From then on it can be flashed thousands of times without ever needing a programmer again. You just create a new bootloader compatible firmware HEX file and flash it into the PIC through USB.

The PIC18F25K50 has several advantages. It can be used on both, the K8055 and the K8055N, since it runs on 3.3V and 5V. It does not need an external crystal to run full speed USB. The only modification needed on the K8055 is removal of R35. It runs on the K8055N without any hardware modifications at all.

108

To simonvav:

Just a quick question: Why do you use the name of a well known search engine in every post you make?

109

Found your “adapter”. I guess you imagine someone to create some sort of piggy-back PCB that contains the PIC32 and all the other components and then somehow connect that to the original K8055.

Do you have any ready to print PCB layout for that? I own a laser printer and have used it to etch my own PCB designs. Or do you expect some free floating wire mesh disaster being implemented by the user?

110

I actually enjoy doing custom PCBs in the end. With the right software, you can load the netlist, produced from the circuit design tool, right into the PCB design tool.

I use a laser printer set to high-gloss presentation slides to print the PCB layout onto inkjet photo paper. That print can be transferred to a copper PCB with a standard household iron. Once ironed on and cooled, you soak the paper over night in water and gently peel it off. Laser printer toner is actually acid resistant “plastic.” The top layer of inkjet photo paper is water soluble, so all the toner plastic will be on the copper. Drill the holes with a Dremel tool and you have a perfect “one of a kind” PCB or your custom project.

How is the stability of A/D conversions on the 32 bit PIC? The PIC18F2550 and PIC18F25K50 I’m using allow up to 10 bits precision. But I found that lacking a “clean” reference voltage, this is of little use. The noise on these boards produces measurement errors that effectively render everything beyond 8 bit resolution useless.

111

What functionality did you add to your firmware?

Mine has:

[ul][li]10, 9 and 8 bit A/D precision[/li]
[li]10 bit PWM precision[/li]
[li]Counters on all digital inputs with 0 to 5 second debounce feature in 0.1ms steps[/li]
[li]Operating digital inputs as low speed frequency counters (up to 2 kHz)[/li]
[li]Operating digital outputs as hobby servo control (500 to 2500 micro seconds, 40 pulses per second)[/li]
[li]Firmware keeps operating servo settings and counters even if USB communication is lost[/li]
[li]Current configuration and output settings can be queried from the card[/li]
[li]Firmware does not send HID reports unless some input data has changed[/li]
[li]PIC can be reset via HID command[/li][/ul]

Right now I am not working much on the firmware. I am trying to develop the PC side USB parts into a client/server model. I have a functioning TCP/IP server process, that allows to control locally attached cards over a telnet style protocol. The counterpart at this point is a python module, but since this is just a TCP/IP line protocol, every language that can do asynchronous IO on sockets will be able to use this. The server code works on Linux (Centos 6.4) and FreeBSD right now. All of that is available on github.

112

I’ve soldered this:

And it works for making contact with Europe at 10W power. So I guess my soldering skills are good enough.

PS: That short wave radio is based on a Microchip DSPIC30. I do have the source code for the firmware, which is Open Source. My radio actually runs firmware that was compiled by me. I have contributed to that firmware too. Small bits. I could not have done that without the basics, that I learned by using Velleman kits.

113

Where is the source code for your firmware?

Mine is here: github.com/wieck/open8055

Regards,
Jan

114

All the VB.NET source code is available for free… For more information read: sites.google.com/site/pcusbproj … ource-code
PC USB Projects is not a 1:1 copy of the Velleman FW, it offers much more functionality, while retaining backwards compatibility.

115

Hi guys, thanks for the information in this post, alot of useful information.

I posted a project in which I needed 5 counters in the K8055 board.

The old version board (P8055-1) I have has a pic16748-I/SP which I understand needs some component replacement - xstal and capacitors.

The new version board (P8055N-2) I have has a pic18F24J50 which I understand may just need to be reprogrammed ?

Thanks in advance, appreciate the help.

116

[quote=“simonvav”]All the VB.NET source code is available for free… For more information read: sites.google.com/site/pcusbproj … ource-code
PC USB Projects is not a 1:1 copy of the Velleman FW, it offers much more functionality, while retaining backwards compatibility.[/quote]

Ive tried this software with the firmware version 2.6 and the pic18f2550 and have found the 5 counters not to function correctly using the 3.9 DLL for VB net 4.0.

This was using the samle test environment that was also supplied on the website. Has anyone else experienced this ? all things like set outputs and read inputs and analog readouts work well, it’s justt the counters.

117

I searched the (velleman) db of this forum using the search option, it did not return anything related to ‘Ffidl’. So, I am confident that my contribution with regard to controlling the K8055N board with tcl/tk is unique. It uses ‘Ffidl’ to estabilish a communication line with the DLL that velleman provides for this product.

Here the link:

wiki.tcl.tk/42399

Works nice…