I personally think that the removal of one single resistor is a lot simpler that this:
Ok. You got just one of the working prototype photos (maybe not the prettiest one), a proof of concept from PC USB Projects website.
[color=#008000]This is much more discriptive photo of the same adapter from a different angle: [/color]
—>
The adapter on the photo also has an additional simple adapter attached (wires and two transistors) to enable programming of other PIC18F2xJ50 microcontrollers… So infact, there are two adaptes stacked together and of course more wiring…
However, there are just a few electrical elements needed to make a K8055 adapter! Everyone can make a nice PCB… Why haven’t you rather attach the adapter circuit schematic: https://sites.google.com/site/pcusbprojects/4-velleman-experiment-board-k8055-pic-replacement/3-k8055-upgrade-from-pic16f745-to-pic18f24j50?
[color=#008000]Here are more optimized designs of PIC32MX250F128B prototype adapters:[/color]
- to K8055 board https://sites.google.com/site/pcusbprojects/4-velleman-experiment-board-k8055-pic-replacement/q-velleman-k8055-to-pic32mx250f128b-adapter-schematic
- to K8055N board https://sites.google.com/site/pcusbprojects/4-velleman-experiment-board-k8055-pic-replacement/r-velleman-k8055n-board-to-32-bit-pic32mx250f128b-adapter-schematic
Click on the photo to enlarge.
[color=#008000]Velleman K8055N board to 32-bit PIC32MX250F128B adapter schematic is composed only of 5 small capatitors, one resistor (not counting the controll led, which is optional) and FOX924B crystal oscillator. The rest si just pure wiring. [/color] The other 2 two adapters need a voltage regualtor and 4 tranisitors to adapt voltage levels, so there are a few basic electrical elements more…
P.S.
Suppose that Velleman would have realized the advantages of my PIC32MX250F128B design and that they would have offered me cooperation to produce a new “native” experiment board kit with PIC32MX250F128B… It would have been light years better than the current K8055 and K8055N-x designs. It would have been as easy to build and it would have cost approximately the same to produce as existing K8055N-2 kits. Firmware is already available from PC USB Projects. Circuit schematic could have been easily refined from the PIC32MX250F128B adapter to K8055N experiment board and the experiment board existing circuit… But I’m afraid that many existing kits would not have sold anymore, if such a versatile kit would have been introduced…
Cheers!
Nobody can upload pictures to the forum. Not even the Velleman staff. And please note that I am not Velleman staff, just a forum member like you.
To post your picture I hot-linked the picture that you posted on your own site. Right click that picture on your site and select “Copy Link Location”. Then in the forum post editor click the “Img” button and paste the URL to your picture between the IMG tags. That said, if you want to point people to your “upgrade” projects, I would suggest opening dedicated threads for that with an appropriate Subject, instead of attempting to hijack each and every thread, that has K8055 in it. Your posts would stand a greater chance to survive.
And I stand corrected. Your adapter does enable Full Speed USB by not connecting VUSB from the adapter to VUSB on the K8055, thereby not providing 3.3V to R35. Should have spotted that earlier.
BTW, this is how I solved being able to convert back to the original PIC on the K8055. I just replaced R35 and X1 with these little sockets, so I can easily exchange the crystal and put the resistor back in. The PIC18F2550 runs fine with the original 33 pF capacitors at 4 MHz (not present in the picture), although the datasheet suggests 27 pF ones.
[color=#FF0000]BUT:[/color]
[color=#FF0000]K8055-1 is not produced anymore by Velleman. However, you my PIC18F2550 solution requires just to replace the crystal and to remove R35 resisitor: https://sites.google.com/site/pcusbprojects/4-velleman-experiment-board-k8055-pic-replacement/w-velleman-k8055-1-board-easy-upgrade… [/color]
[color=#008000]This is mine solution to connect PIC18F24J50 or PIC18F26J50 to K8055N-2: “Simple firmware upgrade: https://sites.google.com/site/pcusbprojects/4-velleman-experiment-board-k8055-pic-replacement/1-simple-pic-replacement-that-adds-more-functionalities-like-10-bit-a-d-conversion-and-additional-analog-input-channels”… You just replace the chip, because PIC18F24J50 and PIC18F26J50 are both “native” to K8055N-2 experiment boards… PIC18F26J50 is almost the same than PIC18F24J50, but it has 64 KB EEPROM instead of 16 kB. And it costs just a few cents more. Both have approx. 4 kB RAM…[/color][color=#FF0000]However, PIC18F25K50 has just 2 kB RAM, which is much more limiting and prevents FW to do more complex tasks that require more memory. Not to mention that the same amount of memory is consiumed for USB support.[/color]
Click in the photo to enlarge it.
So where is your advantage?
[quote=“simonvav”][color=#FF0000]BUT:[/color]
[color=#FF0000]K8055 is not produced anymore by Velleman…[/color][/quote]Does that make your adapter obsolete?
2 KB of RAM seems plenty to me. The Open8055 Firmware only uses 663 bytes of RAM (including what the USB stack consumes) yet and fits into 5 KB of the available 16 KB of Flash memory. How much resources does your firmware need?
According to your own documentation you added some functions resembling PEEK and POKE commands to your otherwise K8055 equivalent firmware. Changing the A/D conversion to 10 bits is not a substantial change. For that you should neither need more than 16 KB of Flash, nor anywhere near 2 KB of RAM. What “more complex tasks” are you then talking about? It doesn’t look like your firmware performs any complex tasks, that would require those amounts of resources. And how would someone go about adding any more complex tasks to it without the source code? Start their own firmware from scratch … well, they could do that with the K8055N as it comes from the factory.
The main advantage of the Open8055 firmware is that it is open source. Anyone can see how it does what it does. It comes under a BSD style license, so anyone can copy or modify the code and use it for whatever they want. And it actually has more complex functionality. PEEK and POKE commands to read and write memory locations or the memory mapped CPU registers are not an equivalent to actual firmware functionality.
Having the source code under a BSD style license also means that after changing to a PIC18F25(K)50, the Open8055 firmware can be used as a source code starting point to build USB experiments, that need custom firmware functionality. And it has some examples of such functionality already built in to use and learn from.
And yes, for the K8055N one simply replaces the chip. The PIC18F2550 and PIC18F25K50 both run without any hardware modifications on it. I stated that several times now.
[color=#0000FF]It is not a bad itea to read my Programming guides. Most programmers appreciate so called “PEEK” (direct memory read) and “POKE” (direct memory write) commands… They are perfect to program microcontroller functional units that mostly need an initial configuration to start operating, like: timers, RTC, … But you have to inbuilt FW subrutines that require fast execution, like microcontroller programming protocols, I2C protocols, independant operations, like thermostatic control, low frequency generator, etc. These are the ones that I of course inbuilt in my FW… All the software examples are provided…[/color]
I have made more adapters and PIC32MX250F128B adapter to K8055N-2 board is certainly not obsolete…
This is in fact PIC32MX250F128B adapter to K8055-1 adapter:
but the K8055N-2 adapter is much simpler since it doesn’t need a 3.3 V voltage regulator and voltage adapters (see the schematic from my previous posts), but the principle of attaching it to the K8055N-2 board and PICkit3 for “on the fly” debugging/programming is similar…
I wish you good luck with PIC18F2550 and 2 kB RAM… You may check may new PIC32MX250F128B User Guide, to check how many of the listed functionalities there can your FW support: https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxwY3VzYnByb2plY3RzfGd4OjMyNzYxYWI0ZDA1YmMyNjg
Simon,
you didn’t answer any of my questions. I find it rather impolite that you ask questions, get them answered, but do not answer any questions in return. Did you even read all of my post? Do you really come here only to make posts containing the “breadcrumbs”, that you placed on the pages of your banner-ad money making web site, hosted by the exact same company, that provides the “well known search engine”, you so heavily suggest to use? I have seen many of your since deleted posts. They seldom have anything to do with the original question, but rather just attempt to redirect readers to your site. It is annoying, to say the least.
BTW, I could easily compile the Open8055 firmware to run on the PIC182xJxx devices. A few changes to the config section, the IO port mappings and a couple conditional compiles in the A/D section is all it takes. Previous versions of Open8055 did run on PIC18F2xJ50, no problem to dig out that old code. I also have a PIC18F2xJ50 boot loader laying around.
However, the J-devices do not have any EEPROM (and you apparently don’t know the difference between EEPROM and Flash memory - hint: The “F” in PIC18FxxJxx stands for Flash).
Anyhow, so what is the real reason why you can’t show us the source code of your firmware?
That explains a lot and especially why you need that much memory and CPU power.
You, Simon, definitely need Maxi-Micro-Controllers. That much is clear now.
ETA: I am not going to respond to any more of your nonsense unless you answer my questions. The moderators did a pretty good job in the past of removing your obnoxious posts and there is nothing much to learn from the rest of them. Good bye.
Believe me; it is not about the money… It is about my enthusiasm… I liked PIC18F24J50 very must at the beginning, but as I got to know all the limitations of 8-bit micronstrollers, I started to think about 16-bit PIC24 and the ultimate 32-bit microcontrollers… At first it was hard to start the things going, to overcome the techincal questions. But now I’m delighted, when I see that I little microcontroller’s heart is actualy a 32-bit MIPS RISC processor that used to power the power workstations in the early 90’.
The term “flash RAM” was invented by Toshiba (http://en.wikipedia.org/wiki/Flash_memory). I prefere though to use the term “EEPROM”. I know that flash RAM is a special kind of EEPROM. But from the programmer’s point of view, it represents a non-volatile memory that unlike RAM doesn’t need energy to preserve data.
I agree with you that we have each a different view of the World and I agree that we disagree. [color=#FF00FF]I’m not going to disqualify your hard work, like you would probably like to do with mine.[/color]
[color=#008000]I try to offer to users much more additional functionality, more speed and more fun, while you are seeking an open source solution with more or less similar functionality as the original Velleman K8055-1 and K8055N-2 boards. I’ve overviewed your source code and it is technically based on Microchip libraries, just like mine. It is much less optimized than I anticipated. The major difference between us is that you think small and I think big. You prefer to drive an optimized “Mini Cooper”, while I prefer to drive a “Mercedes”, which costs approximately the same, but has a lot more to offer… But don’t think that the “Mercedes” was not optimized, just the optimizations were made differently… I’ve read all your posts and I think that I answered all the relevant questions, now… [/color]
Only the time will decide who of us was right… We obviously have different philosophies… I’ll let you have the last word…
[color=#FF0000]So, let’s stop this debate… [/color]
Agreed.
May I ask you at the same time to please stop spamming this forum with entirely useless references to your “breadcrumbs”?
I suggest you actually reread what I post. Because obviously, you don’t read so well.
I’m sorry…
But, I could not resist programming a PIC18F2550 with my FW: https://sites.google.com/site/pcusbprojects/4-velleman-experiment-board-k8055-pic-replacement/w-velleman-k8055-1-board-easy-upgrade? … I’ve tested it on a K8055-1 board and it woks perfectly, execpt for the lack of some functionality (like timer 4, more SRAM, … ) that is present only on newer PIC18F2xJ50 and PIC24 and PIC32 microcontrollers… But now I can get the max. out of PIC18F2550, too…
Congratulations.
Simon, I didn’t feel like responding the last time, but you really ask for it.
You commented on my firmware that “it isn’t optimized”. Well, Simon, there are several different goals for optimization. Which one did you have in mind when writing that comment? What exactly is your code “optimized” for? And what do you think my code isn’t optimized for?
I’m sorry that I wrote that and I apologize. The fact is that each of us is persuing a different goal and each of us has done some optimizations for sure. The basic optimizations like USB suppoort are of course the same, because we both use Microchip liberaries to produce FW. I had had high expectations for you source code, because I had taught that it had been all in assembly code. At first I taught that you had avoided using the Microchip libraries… I like to do this for some time critical sections… But then I found out that this was not true. All the code was in C++, like mine…
My code is optimized for versatility, compatibility and scalability. It tends to exploit all the additional features of advanced microcontrollers, while still preserving the common core functionality. I’ve tested mw FW on different PIC18s as well as on PIC18F2550 and PIC32MX250F128B. If one needs more RAM, he or she can now easily switch to a more advanced PIC18 or even to a PIC32 microcontroller, without the need to rewrite the whole application. PIC32 is much faster in executing integer instructions, too… At the same time it is excellent in floating point performance… I’ll add some artificial intelligence functions (neural networks support) in my next FW for PIC32, which I could hardly do in a PIC18…
Simon,
except for the USB framework, nothing in my firmware is based on Microchip library functions. Everything is done in C (not C++) directly. And everything is interrupt driven. Some places have manually unrolled loops, to avoid costly 16 bit integer operations, which (as you correctly state) the PIC18 isn’t good at. Your high expectations should be met.
You keep talking about the need for more RAM. I don’t see that need at this point. Even with the additional features of interrupt driven servo control and frequency counting, my firmware uses only 5560 bytes of program and 663 bytes of data. That is about 33% for each memory type. 66% free space! Plenty of room for more functionality to be added.
Which brings us to the actual difference between your firmware and mine. My code is open source, published under a BSD style license. Everyone can take it, change it to their hearts content and use it any way they want. You don’t publish your firmware source code. How would someone actually create any new feature for that? How does that “versatility” really work?
Let’s say that I want to add a new command to your firmware. Here is the functional specification for it:
[ul][li]The HID command tag in byte[0] will be 0x2A.[/li]
[li]Byte[1] contains a digital output port number between 0 and 7.[/li]
[li]Bytes[2] and [3] contain the low and high byte of a 16-bit “duration” value. Valid values for the duration are 0, and the range between 500 and 2500. Invalid duration values will be treated as 0.[/li]
[li]After receiving such HID command message, the firmware will start producing 40 to 60 pulses per second on the specified output port.[/li]
[li]Each pulse is “duration” microseconds long.[/li]
[li]While the output port is in that mode, normal digital output commands (K8055 HID command tag 0x05) will not change the port state.[/li]
[li]Setting the “duration” value to 0 will return the output port to normal function (responding to command tag 0x05).[/li][/ul]
How would someone add that functionality using your firmware? Is that even possible?
Regards,
Jan
Yes! The interrupts are usually the way to go. But don’t forget about the infinite loop that runs the main microcontroller thread. Certain tasks that are not time critical may also be implemented within this loop and they consume less processing time (no saving of CPU context). It also depends on the complexity of problems that you are about to solve… Simple tasks of course don’t require much memory… But there is also speed. As I tested PIC32MX250F128B it seems to me that it is many times faster than a PIC18. But I totally agree that many processes can still be succesfully automated with an 8-bit microcontroller… And that there are tasks that require much more power, precision and accuarcy…
I know both worlds and I think that in the end only 32-bit microcontrollers with many MB of RAM will eventually prevail, because the amount of SRAM will soon increase much beyond 64 KB…
All that computing power is useless if at the end of the day I cannot implement what I need. I don’t care if the microcontroller has gigabytes of spare RAM or billions of unused CPU cycles. I want it to do certain “simple” tasks.
Since you didn’t answer my question, let me repeat it. How can I add the simple functionality, I specified in my previous post, to your firmware? Since I don’t have the source code, there must be another way. Would you please tell me how?
Regards,
Jan
Source code is not all that important for someone that wants to use a microcontroller from a higher programming language like VB.NET or VC.NET. He or she would value more to have a rich FW functionality. However, you can alter PIC18 EEPROM settings from VB.NET or VC.NET code. PIC32MX250F128B firmware also enables you to program and execute your own subrutines. If we think of Linux, there are a vast majority of users that would never dear to alter the source code despite its free availability, because they want to have a tested and operational OS. But, there are only a few highly experienced users that would do some little changes to add some additional features. What’s most important, there are also workgroups of volunteer programmers, who would prepare the new releases. This is the way that I prefere most… Disagree? Imagine a programmer that is stucked with an old version of Linux, which core he had altered for some reason. Now, he has no time to add his “upgrades” to new versions…
If one wants to use a microcontroller as an autonomous unit, it might be better for him or her to go for the Microchip librarires and closely tailor the FW to his or her needs. The libraries are the best choice in this case, because they let you assemble the exact functionalities and also optimally use the relatively small PIC memory. There are a lot of good examples on how to use them, too. Maybe, I’ll release my own programing library or my own development framework in the future; but only as a supplement to the existing Microchip libraries …
Cheers!
I do think that source code matters.
But anyhow, what is that “rich” FW functionality, you’re talking about?
PEEK, POKE and CALL?
We had those on our BASIC home computers back in the 70’s (you remember, the things connected to the TV).
I don’t think that’s much of a step forward, do you?
BTW, Simon,
I am one of those people, who do this stuff you are talking about. I wrote countless features in the PostgreSQL database system. Arbitrary precision numeric operations, foreign keys, procedural languages, access statistics collector, unlimited row size, … name one.
All of that it BSD licensed Open Source. Guess why.
Regards,
Jan