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. 

On 2008-02-09, Gavin Brewer <gavinbr@clara.co.uk> wrote:
>
> 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.

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

"Andrew Smallshaw" <andrews@sdf.lonestar.org> wrote in message 
news:<slrnfr3v6u.9fr.andrews@sdf.lonestar.org>...

> On 2008-02-09, Gavin Brewer <gavinbr@clara.co.uk> wrote:

>

> This question is a little vague making a meaningful response

> impossible.

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.

> 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.

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

solved just by consulting the documentation.

> 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?

Crypto algorithms tend to be very dense routines, the

software components being tightly coupled.

The answer is probably no.

> 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.

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.

> 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.

I agree.

<Digression>

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.

</Digression>

Thanks for your help anyhow,

Gavin Brewer.

On 2008-02-13, Gavin Brewer <gavinbr@clara.co.uk> wrote:
> "Andrew Smallshaw" <andrews@sdf.lonestar.org> wrote in message 
> news:<slrnfr3v6u.9fr.andrews@sdf.lonestar.org>...
>
> 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.

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.

>> 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?
>
> Crypto algorithms tend to be very dense routines, the
> software components being tightly coupled.
> The answer is probably no.

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.

> 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.

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