Searching \ for '[PIC] Programming the dsPIC (newbie)' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/begin.htm?key=programming
Search entire site for: 'Programming the dsPIC (newbie)'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Programming the dsPIC (newbie)'
2005\05\30@114754 by Tim Dallmann

picon face
Hello All,

First an formost - thanks for this great list - I've been a lurker here for
a while now,and I've gathered lots of great knowledge.

I've been successful experimenting with various PIC chips so far, namely a
few different 16F and 18F chips.  So I thought I would check out the dsPIC
line and picked up a pic30f4013.  From what I can tell, the programmer
hardware should still work (i have a JDM-based programmer from Olimax) if I
use ICSP.  However, the only programming software I can find is a linux
based one over at http://homerreid.ath.cx/misc/dspicprg/, and I run Windows
(IC-Prog does not yet do the dsPICs).

I've also googled and found some commercial products - the ICD2 from
MicroChip and the USB programmer from http://www.mikroelektronika.co.yu.  Both of
these are nice, but honestly, I'm trying to do this on  a shoestring budget.
 Even spending $90USD on a new programmer is putting me back more than I
(or should I say my wife!) would like.

So - has anyone developed programming software that will work on Windows
with the dsPIC and a JDM programmer?  Does anyone know where I would go to
find out the requirements for writing my own (I'm a programmer by trade)?  
Does MicroChip have any docs on how to do this?

Thanks for your help!!
-Tim


2005\05\30@125812 by Byron A Jeff

face picon face
On Mon, May 30, 2005 at 10:47:53AM -0500, Tim Dallmann wrote:
> Hello All,
>
> First an formost - thanks for this great list - I've been a lurker here
> for a while now,and I've gathered lots of great knowledge.

Well welcome aboard.

>
> I've been successful experimenting with various PIC chips so far, namely
> a few different 16F and 18F chips.  So I thought I would check out the
> dsPIC line and picked up a pic30f4013.  From what I can tell, the
> programmer hardware should still work (i have a JDM-based programmer
> from Olimax) if I use ICSP.  However, the only programming software I
> can find is a linux based one over at
> http://homerreid.ath.cx/misc/dspicprg/, and I run Windows (IC-Prog does
> not yet do the dsPICs).

I guess score one for free software!

> I've also googled and found some commercial products - the ICD2 from
> MicroChip and the USB programmer from http://www.mikroelektronika.co.yu.  Both
> of these are nice, but honestly, I'm trying to do this on  a shoestring
> budget. Even spending $90USD on a new programmer is putting me back
>  more than I (or should I say my wife!) would like.

The programmer isn't the issue. It seems to be the same serial programming
interface, just in a different spot on the chip. So if you do ICSP it should
be no problem from the hardware side.

> So - has anyone developed programming software that will work on Windows
> with the dsPIC and a JDM programmer?

You've missed the beauty of having Open Source software. Homer has already
written all of the code. All you need to do it port it. Why take the time
to reinvent [ and more importantly retest ] the wheel.

So I'll spend a minute talking about porting. MinGW is GNU C/C++ compiler
used for building Windows executables of Unix/Linux source code. Once
the compiler is set up, it will build a windows executable of most POSIX
applications. Furthermore it will use the Windows standard DLLs for
implementing most functionality.

Here's a good starting point for MinGW: http://www.mingw.org/docs.shtml

Another tool you'll need is port access. A DLL that's helpful in this
regard is the inpout32.dll for Windows. You can find it here:

http://www.logix4u.net/inpout32.htm

It loads a kernel driver to interface to I/O ports.

Between the two it's probably less than a day's work to get a working
windows console app that will drive your JDM.

>  Does anyone know where I would go
> to find out the requirements for writing my own (I'm a programmer by
> trade)?

I wouldn't do it. Leverage what you've already found instead of starting
over.

> Does MicroChip have any docs on how to do this?

No clue.

BTW Homer didn't put any licensing notices on his code. Drop him an E-mail
and ask him what type of license he plans for his code.

Hope this helps,

BAJ
>
> Thanks for your help!!
> -Tim
>
>
> --

2005\05\30@152022 by olin_piclist

face picon face
Tim Dallmann wrote:
> I've been successful experimenting with various PIC chips so far,
> namely a few different 16F and 18F chips.  So I thought I would check
> out the dsPIC line and picked up a pic30f4013.  From what I can tell,
> the programmer hardware should still work (i have a JDM-based
> programmer from Olimax) if I use ICSP.

Yes, but the dsPIC programming algorithm is totally different from other
PICs.  It's also not trivial to implement.

> I've also googled and found some commercial products - the ICD2 from
> MicroChip and the USB programmer from http://www.mikroelektronika.co.yu.
> Both of these are nice, but honestly, I'm trying to do this on  a
> shoestring budget. Even spending $90USD on a new programmer is
> putting me back more than I (or should I say my wife!) would like.

You're going to end up spendng more than that one you actually start doing
dsPIC projects.  How are you going to debug?  The ICD2 is pretty much
essential for that, and it can also be used to program these chips.

> So - has anyone developed programming software that will work on
> Windows with the dsPIC and a JDM programmer?

My Windows programming software does support the dsPICs, but it requires a
programmer that adheres to my programmers protocol spec.  The only one I
know of that does this and has the necessary dsPIC support is my ProProg,
but that is not what you are looking for.

> Does anyone know where
> I would go to find out the requirements for writing my own (I'm a
> programmer by trade)? Does MicroChip have any docs on how to do this?

Microchip has programming specs available for all PICs.  These are in
separate documents from the data sheets.

Again, I think your best bet is an ICD2.  I hear there are second source
knokoffs out there, but can't recommend them because I've never tried them.
One reason I didn't bother with the effort of adding dsPIC support to my low
cost PIC programmer (EasyProg, http://www.embedinc.com/products) is because
I figured a hobbyist would need an ICD2 for dsPICs anyway.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\05\31@204351 by Chen Xiao Fan

face
flavicon
face
It is a pity that Olin will not support dsPIC with EasyProg. However
the message is clear: "A hobbyist would need an ICD2 for dsPICs anyway".
I agree with Olin on this even though I just start to learn dsPIC.

Speaking of clone ICD2, you can even make one by yourself. The simple
ones are using RS232 only and there are some catches. I have tried
one of the most simple ICD2 from http://stolz.de.be/ (this page
is down now) and made some small modification to it. For example,
it is better to use two diode instead of the 5V1 zener for the interface
of RS232 to /MCLR pin. It is also better to add two indicator LEDs
from RB3 (busy) and RB2 (error). I had some progress in terms of
programming some chips. In the end I got an original ICD2.

Regards,
Xiaofan

{Original Message removed}

2005\05\31@221944 by Mark Rages

face picon face
On 5/30/05, Byron A Jeff <spam_OUTbyronTakeThisOuTspamcc.gatech.edu> wrote:
> So I'll spend a minute talking about porting. MinGW is GNU C/C++ compiler
> used for building Windows executables of Unix/Linux source code. Once
> the compiler is set up, it will build a windows executable of most POSIX
> applications. Furthermore it will use the Windows standard DLLs for
> implementing most functionality.
>
> Here's a good starting point for MinGW: http://www.mingw.org/docs.shtml
>
> Another tool you'll need is port access. A DLL that's helpful in this
> regard is the inpout32.dll for Windows. You can find it here:
>
> http://www.logix4u.net/inpout32.htm
>
> It loads a kernel driver to interface to I/O ports.
>

Instead of MInGW, you could use Cygwin to make things easier.

Cygwin contains a more complete Posix implementation than MinGW.
Because of that, it's slower for some things.

It's the first thing I install when I have to use a Windows computer.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2005\05\31@225019 by Chen Xiao Fan

face
flavicon
face
Maybe I am a bit biased but I think JDM type of programmer
(or any programmer without a PIC on it) may be not a
good enough programmer.

To me it may be worth more effort to extend Wisp628/EasyProg
to program more chips (including dsPIC). Even though Wouter
and Olin may not want to do it for good reasons, the protocol
and the firmware are both open. They tend to be more stable
than JDM type across different computers.

I also quite doubt the assertion that you can port a Windows
console app within one day when dealing with hardware access
but I am not a PC programmer.

Xiaofan

{Original Message removed}


'[PIC] Programming the dsPIC (newbie)'
2005\06\01@073518 by olin_piclist
face picon face
Chen Xiao Fan wrote:
> It is a pity that Olin will not support dsPIC with EasyProg. However
> the message is clear: "A hobbyist would need an ICD2 for dsPICs anyway".
> I agree with Olin on this even though I just start to learn dsPIC.

I'm not totally against adding dsPIC support to the EasyProg, but it's a
matter of priorities.  When I asked about that here a few months ago I was
urged to spend the effort adding support for the new 16 and 18 PICs instead.
Someday I'd like to make the EasyProg PIC support more complete and add
dsPICs.  Would you buy one if it had dsPIC support?

By the way, I'm currently working on support for the 18F group that includes
the 18F2520, 18F4520, etc.  There are something like 30 chips in that group,
and I think these should be the primary 28 and 40 pin hobby PICs.  Of course
Microchip once again has not only changed some parameters, but also changed
the rules.  In this case the block size if variable, something my existing
software and firmware doesn't have a mechanism for dealing with.  I may get
it done this weekend depending on how much the rest of the world lets me be.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\06\01@080105 by olin_piclist

face picon face
Chen Xiao Fan wrote:
> Maybe I am a bit biased but I think JDM type of programmer
> (or any programmer without a PIC on it) may be not a
> good enough programmer.

Me too ;-)

> To me it may be worth more effort to extend Wisp628/EasyProg
> to program more chips (including dsPIC). Even though Wouter
> and Olin may not want to do it for good reasons, the protocol
> and the firmware are both open. They tend to be more stable
> than JDM type across different computers.

The EasyProg is halfway there, since the host software and the protocol
already support dsPICs.  Only firmware enhancements would be required to
make the EasyProg program dsPICs, although this is by far the most
complicated of the programming algorithms.

If you're serious about doing this, I'm willing to provide some support.
I'd be willing to give you a ProProg and an EasyProg, and make the ProProg
firmware available to you privately.  In return, you must make your EasyProg
firmware with dsPIC support publicly available as both HEX file and source
code that works with my PIC development environment as the existing firmware
does now.

Unfortunately I've been burned in the past with this.  I gave out several
beta test units of the EasyProg to various PIClist members.  Most had
promised to create all kinds of software for it.  In the end I got one
person to test it on an operating system that I didn't have.  Not a single
person implemented any software for it, even though they had no problem
accepting and keeping the free units.

So, I no longer give out free units just because someone promises to
implement software.  If you buy a ProProg and EasyProg now, I'll refund your
money once your EasyProg firmware with dsPIC support is available and I've
tested it to my satisfaction.  Sorry, but that way I'm covered if you get
busy or whatever, and you aren't obligated to do anything.

I'm willing to make similar offers to others, but these have to be arranged
with me ahead of time.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\06\06@011456 by Chen Xiao Fan

face
flavicon
face
It is great that Olin is willing to support the effort. Too
bad I am not a good enough programmer to do this. :(

There is an easier way out there. One can test using the
Wisp628 with EasyISP firmware. Wisp628 is pretty easy to
build. The only issue is how good the EasyISP firmware
adheres to Olin's protocol.

Another candidate is the PICkit1. The problem is the
OTP PIC16C745 parts used and not many people like to
deal with OTP parts or windowed EPROM part any more.
Therefore, one may want to change it to 18F USB parts.

By the way, it seems to me that Mikroelektronica programmer
is also using PIC16C745 judging from the driver.

Anyway, it seems ICD2 is still the way to go for now.

Xiaofan

{Original Message removed}

2005\06\06@031013 by Philip Pemberton

face picon face
In message <3B8AEFFADD3DD4118F8100508BACEC2C07F77267@spex>
         Chen Xiao Fan <.....xiaofanKILLspamspam@spam@sg.pepperl-fuchs.com> wrote:

> There is an easier way out there. One can test using the
> Wisp628 with EasyISP firmware. Wisp628 is pretty easy to
> build. The only issue is how good the EasyISP firmware
> adheres to Olin's protocol.

Very well actually. It's based on the EasyProg firmware, but with
modifications that allow it to use the Wisp628 hardware. IIRC it supports a
slightly higher protocol version than the Easyprog itself, but that's only
because the WISP is an in system programmer. Early versions of the protocol
couldn't deal with ISP-only programmers IIRC.

I did take a look at the dsPIC programming spec once - then I decided life
was too short to deal with it. The 16Fxx programming algorithm is nice and
simple - the dsPIC one is hellish in comparison.

> Anyway, it seems ICD2 is still the way to go for now.

Well, I like it :)

Later.
--
Phil.                              | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB,
philpemspamKILLspamphilpem.me.uk              | ViewFinder, 10BaseT Ethernet, 2-slice,
http://www.philpem.me.uk/          | 48xCD, ARCINv6c IDE, SCSI
... Start slow and taper off.

2005\06\06@052427 by Chen Xiao Fan

face
flavicon
face
Glad to hear that. However I am not so sure whether it supports
slightly higher protocol version than the EasyProg. I think
the firmware insider EasyProg is as well evolving. So does
Olin's protocol. :) What is the protocol version supported
in EasyISP?

Xiaofan

{Original Message removed}

2005\06\06@080857 by olin piclist

face picon face
Chen Xiao Fan wrote:
> Glad to hear that. However I am not so sure whether it supports
> slightly higher protocol version than the EasyProg. I think
> the firmware insider EasyProg is as well evolving. So does
> Olin's protocol. :) What is the protocol version supported
> in EasyISP?

The spec protocols are generally backward compatible.  Both the EasyProg and
ProProg will soon be supporting spec version 14.  Most new commands are
optional and the host has to determine the capabilities by using the FWINFO,
CHKCMD, and GETCAP commands.  The currently released host software works
with any firmware adhering to spec version 2-13.  If a target chip is
identified that requires commands not implemented in the particular
firmware, then you get a "target chip not supported with this firmware"
message or something like that.

Since most of the commands are optional, it is quite possible to write
minimal firmware that only supports a few chips and still be compatible with
the latest spec revision.  In fact, more commands were made optional in
later spec revisions specifically to make it less burdensome to implement
minimalist firware.  I think it's good for everyone if it is possible to mix
and match host software and programmers.  I'm therefore trying to make the
cost to entry of implementing compatible firmware as low as possible, and
push as much of the complexity of dealing with different implementation
capabilities to the host software where it's easier to handle and resources
are essentially unlimited for that task.

By the way, spec version 14 adds additional optional commands to support the
different write block sizes of the 18F2520 and related chips.  There are 32
chips in this programming specification.  These include the current generic
28 and 40 pin PICs which are good starting points for hobbyists.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...