Is there any new information on the K8055N? I see that it will be much faster, does it use a new processor, an 18F or maybe a 24F? Is there a release date yet?
Regards
James
First batches are scheduled for April 2012. PIC18 is used.
Cool, I already converted my K8055 to a PIC18 device, the new board should be good for modifying.
Could you share info how you converted that? i couldn’t find a way to pm you 
I used the Microchip document TB095 as a guide but I used a 16MHz crystal as I already had one. I then flashed the 18F chip with the Microchip USB bootloader, with the config setting changed for the 16MHz crystal. I have noted that the K8055N looks to be a similar evolution but also looks to have a regulator next to the USB socket.
If Velleman don’t mind then I will publish the details and the firmware/software that I have, maybe it will be possible to get an open source project running with the K8055N.
There is no problem to publish software/firmware you wrote for our hardware.
I think there should be a lot of interested people into that
[quote=“J_Holland”]I used the Microchip document TB095 as a guide but I used a 16MHz crystal as I already had one. I then flashed the 18F chip with the Microchip USB bootloader, with the config setting changed for the 16MHz crystal. I have noted that the K8055N looks to be a similar evolution but also looks to have a regulator next to the USB socket.
If Velleman don’t mind then I will publish the details and the firmware/software that I have, maybe it will be possible to get an open source project running with the K8055N.[/quote]
I would be interested in participating in such a project. I am already writing an enhanced equivalent of the K8055D.DLL that is part of a network service to access cards on another computer via LAN. viewtopic.php?f=3&t=7448 . It is obvious that such an open source project would aim at introducing new capabilities programmed into the PIC, so we would need to expand the USB protocol as well. I have a few ideas about new features, but that’s for later.
Let’s start with the conversion to PIC18. Can you please confirm a few details about the modifications necessary?
I assume that you used a PIC18F2550, which seems to be pin compatible to the original PIC16C745.
Step 1. of TB095 should translate into replacing X1 with a 20 MHz crystal and removing C4 and C5.
Step 2. should translate into removing R35. The P8055-1 board doesn’t have an equivalent to the second pull up resistor.
Step 3. is not needed, unless one goes crazy and wants to use the MPLAB ICD and therefore sacrifices ports D4 and D8 plus adding the equivalent to J6 of the PICDEM wired to MCLR, VDD … RB7.
I obviously need an external programmer (like a JDM) to put the boot loader onto the PIC.
Am I missing anything so far?
That sounds about right. I think I used a 4550, any one of that series could be used. I used a 16MHz crystal because I had a few of them already, its just requires a slightly different configuration setting. If you have an external programmer then you can use that to programme the device. I had access to an ICD2 and a demo board so I plugged the chip in there and flashed it.
The HID report format protocol makes it quite simple to add additional functions although the data that can be sent is limited unless you use multiple reports.
I need to tidy up the firmware, I hacked it about a bit for the last job I used the board for. I will then publish it.
Thank you.
A PIC-PG2 serial programmer is $14 at Mouser. I need to order things there anyway (like a PIC or two and a crystal). I’ll get the 2550, since according to the Microchip website, that one has a pin count of 28 (compared to the 40 of the 4550). I wonder if Velleman support could tell us which PIC18 is actually going to ship on the K8055N. I can’t tell from looking at the picture. As a side note, there is a new SK9 on the right side of IC4 that looks very much like it could be an ICD connector, doesn’t it?
Since the new setup will communicate at full speed (12 Mbit/s), increasing the report size to get more information doesn’t sound unreasonable.
In the meantime I can finish the “Service” part of my k8055server. Running the k8055server in foreground in a command prompt with client IO debugging messages enabled is like peeking into the application, watching what the DLL sends to the card and what comes back from the card. That will come in handy when implementing new message types. But having it start up as a service at boot time for normal operation is definitely a must have. I’ll publish a new package of that when done.
I didn’t notice SK9 but I did notice that it appears to have an additional regulator next to the USB socket.
I left the report size as it was (8 bytes) in order to be backwardly compatible with the existing Velleman driver and software examples. The polling interval can be increased from 10ms to 1ms but I left it as it was for initial development to reduce the traffic on the USB. I used a software USB protocol anayser to determine the protocol and extract the Velleman header info, at 1ms the TX messages were being lost amongst all the RX messages.
I had another look, it does look like SK9 could be a programming/debug header - that would be really nice. It looks like the board is pretty much ready for production hopefully the manual and schematic will be published soon.
I got my information from reading the Pascal code of the original DLL and then wrote that drop in replacement in C based on it.
What it does right now is to communicate with either a physical card using exactly the same ReadFile()/WriteFile() calls, the original DLL does, or to communicate via TCP/IP with the k8055server, that then communicates with the real K8055. My K8055D.DLL exports all the entry points, the original K8055D.DLL does. It is just a hybrid that can access a physical card or communicate with a remote server. The k8055server can run on the local or a remote computer. And it can run on Windows or FreeBSD at the moment. I can run that K8055_Demo.exe program (the original VB thing with the light bulbs) here and control a K8055 card attached to another computer running FreeBSD. I just replace the K8055D.DLL and set one environment variable. Since the FreeBSD specific code to access a physical K8055 is based on libusb 1.0, chances are it will compile and run on Linux and OS-X as well.
We could enlarge the HID report size internally, but have the backwards compatible functions in the DLL ignore that new data. Then create new API functions that expose the new features. Like telling the card in what interval to report, including “only report if there is anything to report”. That of course includes mechanisms to tie the device into event driven (overlapped) IO so the application knows when it is time to receive new data. In that case, the DLL would tell the card only to report if there are changes to the input data, at a maximum interval of X ms. The DLL would then use overlapped IO to get reports and hand the application an Event handle that it can use in WaitFor…(). When that event is signaled, the application calls an API function, that actually gets the data from the card. All the normal API functions like ReadDigitalChannel() or ReadAllAnalog() will change their behavior at that moment too, and simply return the last received value, without actually communicating with the card at all. Since the card immediately reports changes, the last known value can be considered “current”. The k8055server actually has such a mode already.
That way, a legacy application would still communicate with the new firmware as if it was a good old K8055, and won’t notice any difference.
I’ve started a new thread with a more appropriate title in the kits section, I figure that there may be more interest there:
[quote=“MostlyHarmless”]
I am already writing an enhanced equivalent of the K8055D.DLL that is part of a network service to access cards on another computer via LAN. [/quote]
Sounds like a lot of hard work!
Have you not thought of writing a TCP server / client that just makes use of the standard .dll? - That would make your task a lot easier and you could modify the demo program to connect to any computer running the server/board.
[quote=“tangoforce”][quote=“MostlyHarmless”]
I am already writing an enhanced equivalent of the K8055D.DLL that is part of a network service to access cards on another computer via LAN. [/quote]
Sounds like a lot of hard work!
Have you not thought of writing a TCP server / client that just makes use of the standard .dll? - That would make your task a lot easier and you could modify the demo program to connect to any computer running the server/board.[/quote]
The effort is actually reversed. It takes very little code to build that standard DLL. But there is a lot involved building a Windows Service that accepts TCP/IP connections and interacts asynchronously with an arbitrary number of clients.
Except for the service part (coming, just not implemented yet), the k8055server works just fine as a console application right now. I can access a remote K8055 card, connected to any Windows or FreeBSD computer, and my replacement K8055D.DLL allows me to specify host/port/cardid in an environment variable. The replacement DLL is a hybrid. It will access a local card by default, but will open a network connection to the server instead if a specific ENV variable is set. The SDK demo programs don’t need to know about it, they just function like they should, card being local or remote.
No need to modify or recompile the demo programs at all.