No, Velleman can only be happy that people get interested in their products.
If I want do do everything I would like to, I needed days that lasted 72 hours… Problem is also that my working computer is far away from my electronics bench. That makes working on these microcontroller things rather difficult and time consuming. But I hope I ever find the time to experiment with the K8055! You’ll hear from it ;).
It is discouraging to see how this thread turned out. The original poster of the complaint, that the EDU05 isn’t what he expected, didn’t even visit this forum again. He basically vented his frustration and that was all he came here for. The next guy to “second” the complaints did visit again, but didn’t bother to respond to any of the suggestions made in response.
The only people with constructive input were the “usual suspects”, like laserguy and Wrong Way.
What is broken with the Internet these days? Back in the USENET days it was that people, who had a problem, got involved when someone suggested a possible solution. They actually tried to follow up and “solve their problem”. They reported back with the result of that effort. This has completely turned into a “consumer” attitude. People don’t want to participate in any community effort, they want to “download an app to their iTrash” and that’s it. If the download doesn’t install itself and works as expected, they complain about it on an iBlog and never read any of the responses to that.
Why do these people just drop a complaint and leave? How can we get these people involved?
Yeah, perhaps I was going about this the wrong way, assuming it was more simple than it is. Sorry for the delay in reply, I didn’t see the email notification.
When I see cheap little toys like this: http://www.kickstarter.com/projects/digistump/digispark-the-tiny-arduino-enabled-usb-dev-board, I can see that there is an opportunity for software developers to get onto the custom built hardware side of things - the components are getting cheap, smart and you only really need programming knowledge, not too much on the hardware level.
‘Everything’ plugs into the computer via USB these days, so I figured out I would start there. I’ve worked with devices over COM/LPT ports before so I thought this would be more of the same. I’m aware that saying this might make me a target of disdain for a hardcore hardware geek, but I certainly don’t want to be getting into the lower levels of things - in fact the whole idea is that I want to be able to move fast - rapid prototype sort of stuff.
That’s not to say I don’t want to understand electronics, I do, and in the past month or two I have been doing a ton of reading. But I don’t want to spend months writing firmware and custom protocols. I want to build working products.
The following is in no way meant as disdain. Everyone has different interests and strengths. I am more interested in the software side of things too, so I understand where you are coming from.
That said, “custom built hardware” starts with a functional definition, followed by developing a circuit diagram which is then used to create a PCB layout. One needs to understand electronics to a certain degree to do that. Plugging together Legos is not custom building hardware. Depending on the bricks though, there may still be the need for some degree of custom firmware parts and other software.
If such hardware is to communicate with a PC over USB, then it either is an existing device, for which firmware, drivers and libraries already exist (nothing custom about that), or it is something new and you certainly will have to define and then implement the communication with the device. There are frameworks for such communication, like HID and in the case of Microchip the development tools and sample code is all free. But you are going to have to fill in the blanks there. The framework only provides that the microcontroller connects (enumerates) and that you can send packets back and forth. The content of those packets, what they tell the microcontroller to do, what they tell the PC what the microcontroller is measuring, that’s all up to the “custom definitions” of your project.
Same for the firmware side of your custom built hardware. Each individual I/O pin on a microcontroller can often serve multiple functions. In the PIC18F series for example you have pins that can act as Analog inputs, digital inputs or digital outputs. Other pins can be used for serial communication, like an I2C bus, or again digital input/output. What you use each of those pins for depends on the needs of your custom hardware. The custom firmware then has to configure these ports to that specific function on startup, and to work those ports according to the specs of your functional definition. Some may be controlled by the firmware autonomously, some may be controlled by a message from the PC, interpreted by the firmware which reacts to that by turning the port on/off or setting a PWM port to a specific value, switching a pin from input to output, whatever it is your custom definition requires.
If you really want to build custom hardware, then it doesn’t get much more simple than all of that. The simple thing you got already. The EDU05. Granted, that is as simple as it gets since it is just one single Lego brick acting like a black box controlled by a ready to use library. But don’t expect much more depth from other Lego kits. They may have a few more bricks that you can plug together in different combinations. Like those numerous sensors, that you can ready attach to an Arduino. Likewise you will then plug together “their” firmware modules. But ask yourself: “what exactly is still custom about such a project?”
I’m afraid that I agree that the basic kit does not teach much about USB, but it certainly seems like a good starting point to get something working with custom USB hardware and a PC application.
Anyway, I just ordered a K8055N to play with. A large part of the reason I picked that product is the work mostlyharmless has done to make the software open-sourced so I really can use this as a starting point for USB software development on a PIC. I was hesitating about selecting this product until I saw mostlyharmless’ contributions.
Once I get the kit and have a chance to play with it a bit in native mode (probably not until Xmas), I would be interested in moving towards a custom K8055N software platform. That is important to me because the 8055 seems like a nice test platform to help get the PC-PIC interface working for my projects. I would be glad to help with the porting to the K8055N’s PIC18.
I did not want to get into a development system where my code is tied to a specific product like the 8055. With the open-source from mostlyharmless, I can use the 8055 as a test platform, and then make up a custom PIC based board to do the specific things my application will need if I want to. If using a K8055N is a better choice from the hardware and constrction point of view I woudln’t hesitate to go that route, but I don’t want to be locked into it. Learning new API’s is always time consuming, so once I know this one, and have a code base using it, I would be able to use it for many projects.
This is my first post here. What’s my background? I’m a retired computer sofware geek that has been writing and supporting software in one way or another since the 70’s. A major hobby is electronics, and I enjoy writing the PC and PIC based sofware. Winter is a good time for electronics and writing in C up here in Canada.
Let me know when you’re ready to modify your K8055N. At first that modification would just be replacing the PIC and burning a bootloader into the new one. I’m currently thinking about starting over with the open source firmware from scratch, so don’t waste too much of your time with the existing code.
I also ordered a K8055N and spare PICs (PIC18F24J50 as well as PIC18F25J50). As it is, the firmware should still fit into the smaller 24J50 version, but I have some ideas that may go beyond its memory. We should discuss those details in a new thread in the “PC related Kits” forum though. I will start a discussion there soon.
Thanks. I’ll keep an eye on out for your new project and help with what I can until I get my device (at least a week yet) and have a chance to play with it. I was looking at your API and it certainly does expand upon what the base Velleman code provides.
That sounds like some serious shipping time. I ordered my K8055N on Sunday and even with economy shipping it was here yesterday. I’m still waiting for the PICKIT 3 programmer though, since my old one won’t be any good for 3.3V, so I probably won’t get into flashing anything into it before next week either.
Anyhow, that API is up for a change as well. We should come up with a really “event driven friendly” design.
i have successfully compiled a very little bit modified (pwm frequency, address) the K8055 goodies of Jan, modified the dll a little to report analog and counters in one shot. Have used 3 modded k8055 to build some sort of measurement devices for educational purposes.
the main reason to buy the K8055 was the available open source code (possibility to modify it). the second - 10bit AD on 2550
now trying to port the code to 24J50, but… Mostly reading the docs and scratching head…
i’m pleased to read, that the nice coding quality of MostlyHarmlessOpen will be extended on the N model
if someone post near nothing, that isnt the symptom of indifference
You may find it of interest that the PIC18F2550 appears to work on the K8055N as well. That PIC is after all rated to work from 1.8 to 5.5V. I haven’t done any extensive tests, but configuring a Bootloader to 4MHz (PLLDIV=1) and changing the way SK5/SK6 are handled and it enumerated as “Microchip HID USB Bootloader” on first try.
this sounds very good But don’t have K8055N pcb with DIP socket to test…
because the manufacturing of K8055 board is discontinued, i think the modifying of K8055N to accept the 18F2550 (and the OpenSource) is hot (at last for me).
i would like to try (as i get the pcb) the next config:
R15/R21 and R14/R20 seems to be voltage divider, and additionally loads OP AMP TLV274 output (possibly better stability on pic input (using of R21, R20 {probably ~3kOm} can be tested on 18F2550 too)
R20,R21 to remove, and R15, R14 to change to piece of wire
{RSS impedance of both pic’s seems to be identic (2kOm)}
D1,D2 to remove; D1 contact of SK5 to “earth”
C11 to remove
in firmware code pin RC7 and RC6 must be “swapped”
or
in dll code digital in 4 and digital in 5 must be “swapped”
Digital In 1 (I1):
in firmware MCU pin 6 (RA4 on 18F2550) must be changed to serve pin 5 (RA3 on 18F2550)
i would like to eliminate SK6 from “bootloader mode” detection and address of card “hardprogram” into firmware
the involved hardware and firmware changes seems to me conditionally easy
i hope, this is correct.
And, off course, the SK9 header goes forgotten
sorry, if this is a in partialy repeated somebody message (dont did a search on this)