USB programming on the VM110

Guys,

I recently bought:

1) The Velleman PIC VM111 programmer. 2) The Velleman USB experiment board, (VM110)

What I would like to do is to program some firmware into a PIC using the programmer, then pop it into the USB board.

Programming and testing the PIC on the VM111 is a well-documented and straightforward matter. However, integrating the PIC into the VM110 board isn't so well documented.

I have no idea how the DLL supplied with the VM110 fits into the overall scheme of things.

If anyone knows how to go about integrating and testing new firmware in the VM110, please send me some pointers to get my test bed up and running.

Thanks, Gavin Brewer.

Reply to
Gavin Brewer
Loading thread data ...

This question is a little vague making a meaningful response impossible. Your primary documentation is of course the PIC16C745 datasheet which documents the chip and the USB connection in particular. In addition the schematic at the back of the assembly manual will reveal which input or output interfaces to which pin on chip.

Whether you can reuse the existing DLL depends on what you want to do with the board which is the big unknown from your post. From a high-level perspective, do the actions you want have logical equivalents in the existing functionality? For example you probably could replace one of the analog outputs with a PWM output without altering the DLL since the difference between the two can be ignored from the host's perspective. OTOH programming autonomous responses to stimuli would probably need changes to the protocol between host and board. This isn't to say that the existing code can't be tweaked, though, ISTR source code is available.

Bear in mind though that like many embedded projects, the real complexity of the VM110 is in the software. If you are scrapping the software in its entirety and replacing it with something else you should question whether custom hardware designed specifically for your application would be more suitable. The VM110 is a good board - it's cheap and it does what it does well, and for many basic control applications it is all that is required. However, it isn't intended to form the basis of a sophisticated system and if you try and put it to use as such I suspect you will hit its limitations fairly quickly.

--
Andrew Smallshaw
andrews@sdf.lonestar.org
Reply to
Andrew Smallshaw

Oops. There are many different applications floating

around in my head at the moment, but for the sake of argument

I will consider just the one.

What I would like to build is an RSA cryptographic protocol

Burnt into EEPROM firmware, and running off the VM110 as

a USB-based project.

To complicate things, the hardware setup would also double up

as an ADSL modem/router but that's just added complexity.

The datasheet tells me a hell of a lot, 99% of my problems

solved just by consulting the documentation.

Crypto algorithms tend to be very dense routines, the

software components being tightly coupled.

The answer is probably no.

I'll bear that one in mind. It may be a question of adding

to the existing firmware, rather than starting with a blank slate.

I agree.

There seems to be an exponential cost/complexity curve in developing

Embedded systems. 30 odd years ago, Steve Wozniak (my role-model)

was lucky enough to develop the first PC from inexpensive parts.

It's not so easy for the little guy with a tight budget these days.

Thanks for your help anyhow,

Gavin Brewer.

Reply to
Gavin Brewer

On a PIC16? I suspect that is pushing things a little bit. PICs come in for much more stick than they deserve on this group but IMHO they are great for replacing what otherwise would be a board full of random logic. Anytime you immediately say to yourself "I need a computer for this" you are probably already exceeding what is possible or at least pleasant on the PIC. You also need to consider obtaining the necessary regulatory approvals for your device if you are connecting it to a phone line. Hooking up your device to an off-the-shelf ADSL 'modem' would avoid this.

Definitely not. The complexity of the algorithm isn't an issue here per se, it is more a question of how you present your input data to the device and get the results back within the confines of the existing protocol that was designed to do something else entirely. It may be possible but it wouldn't be natural or pretty. Still, the existing source code does at least provide you with a working template for use as a starting point with your own code if nothing more.

It sometimes seems that way but I don't think it's really the case. It is just different now. Simple stuff is if anything simpler than it was in the past. In the past you would need a separate processor, RAM, ROM and glue logic to decode the address bus before you even started doing anything productive. Nowadays you just use a single chip, and the device programmers, at least at the hobbyist level, are far cheaper than EPROM programmers and erasers.

The Internet really has transformed the design process - you can get datasheets in seconds instead of days and you often find interesting designs for particular subsystems to use as starting points, not to mention the great resource that is the online community as a whole. Standards such i2c greatly simplify designs in terms of both design effort and chip count by further eliminating glue logic. Software development tools and methodologies are vastly superior to what they were.

On the flip side things tend not to be 5V powered and on 0.1" pin spacing anymore so that can increase complexity - PCBs are pretty much essential even for comparatively simple stuff. Modern innovations such as USB are invariably much more complex than what they replace (although how much this affects a particular design depends on what you need to interface with). It isn't entirely clear cut, but as I said in my earlier remark, it is different, not worse.

--
Andrew Smallshaw
andrews@sdf.lonestar.org
Reply to
Andrew Smallshaw

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.