Searching \ for '[PIC] PIC18F vs. dsPIC30F Operating Current-- Resu' 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/ios.htm?key=spi
Search entire site for: 'PIC18F vs. dsPIC30F Operating Current-- Resu'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC18F vs. dsPIC30F Operating Current-- Resu'
2005\09\11@051854 by davedilatush

picon face
part 1 1685 bytes content-type:text/plain; charset=us-ascii (decoded 7bit)

Olin Lathrop wrote...

>Dave Dilatush wrote:

>> My vague, uninformed, totally off-the-wall WAG impression is that
>> the current consumption of the two approaches will probably be
>> approximately equal
>
>I haven't looked at the number with that in mind either, but my WAG is that
>they are about equal at the same clock rate.  In other words, they are
>probably close in joules/instruction.  If you can use the wider word and
>special math capabilities of the dsPIC at that clock rate, then I expect
>(but again, you should sit down and do the math) that the dsPIC takes less
>energy to crank the same computation.  In other words less joules/equation.

I set up a test with a PIC18F242 and a dsPIC30F3013, operating in
various oscillator modes and frequencies.  Full results are in
the attached text file, but overall it looks like the
dsPIC30F3013 can be expected to draw roughly two and a half to
three times the operating current as a PIC18F242 operated at the
same clock frequency.

However, that disadvantage was more than offset by the dsPIC's
ability to get more done per instruction: the PIC18F version of
the time-critical code took 546 instruction cycles to do the job,
versus only 64 instruction cycles for the dsPIC-- more than an
8:1 improvement.  The bottom line is that if I do this
application with a slow dsPIC rather than a fast PIC18F, I can
actually reduce operating current.

This is my first dsPIC project, and my initial impression is that
while the learning curve is big (not difficult, just a lot of
work), so is the payback: these things are REALLY easy to work
with.

Dave D.


part 2 1289 bytes content-type:text/plain; charset=us-ascii; name=Current.txt
(decoded 7bit)

Current Consumption vs. Clock Rate
for PIC18F242 and dsPIC30F3013

             MHz         mA       mA/MHz
           ------      -----      ------
PIC18F242:

HS:           4.00       1.80       0.45
             8.00       2.95       0.37
            10.00       3.50       0.35
            20.00       6.72       0.34

HS/PLL:      16.00       5.19       0.32
            32.00       9.64       0.30
            40.00      11.78       0.29

dsPIC30F3013:

LPRC:         0.512      1.10       2.15

XTL:          4.00       4.06       1.02

XT:           4.00       4.42       1.11
             8.00       7.70       0.96
            10.00       9.26       0.93
            20.00      17.63       0.88

XT/PLL4:     16.00      14.33       0.90
            32.00      27.76       0.87
            40.00      34.05       0.85

XT/PLL8:     32.00      27.76       0.87
            64.00      52.80       0.83
            80.00      64.60       0.81

XT/PLL16:    64.00      52.40       0.82

FRC:          7.37       6.57       0.89
FRC/PLL4:    29.48      24.38       0.83
FRC/PLL8:    58.96      47.30       0.80
FRC/PLL16:  117.92      87.60       0.74

HS:          10.00       9.54       0.95
            20.00      18.07       0.90


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2005\09\11@055947 by Jinx

face picon face
> various oscillator modes and frequencies.  Full results are in
> the attached text file, but overall it looks like the
> dsPIC30F3013 can be expected to draw roughly two and
> a half to three times the operating current as a PIC18F242
> operated at the same clock frequency

Nice job Dave, thanks for sharing - where have you been hiding ?

I wonder if the 24F (as I understand it 30F with the ds bits
left out) will be relatively lower power than an 18F

2005\09\11@062818 by davedilatush

picon face
Jinx wrote...

>Nice job Dave, thanks for sharing - where have you been hiding ?

I've been working my butt off trying to scratch together enough
loot to retire on someday.  :)

>I wonder if the 24F (as I understand it 30F with the ds bits
>left out) will be relatively lower power than an 18F

I'm wondering about that, too.  I did notice that the dsPIC's
current consumption didn't appear to depend much on what kind of
code it was executing: whether it was just a big loop full of
NOPs or whether it was my application code (very heavy on the DSP
hardware usage, especially MAC operations), Idd was about the
same.

That suggests MChip either clock the DSP hardware all the time
whether it's being used or not, or (more likely, would be my WAG)
it doesn't draw much current itself.  And if that's the case,
that would suggest the 24F might take almost as much current as
the 30F.

We shall see...

Dave D.

2005\09\11@095739 by olin piclist

face picon face
Dave Dilatush wrote:
> I set up a test with a PIC18F242 and a dsPIC30F3013, operating in
> various oscillator modes and frequencies.  Full results are in
> the attached text file,

Very interesting.  Thanks for doing this.  I notice that both PICs are
running well below their maximum specified current for the various
oscillator frequencies.  Your numbers are therefore a rough guide of what
you might get as apposed to something to design with.  Unfortunately I only
have an old 18Fxx2 data sheet here that has "advance infomation" written
accross all electrical specs, and I don't feel like waiting to download new
data sheets for the 18F242 and 30F3013.  My old 18F data sheet shows max
current draw at 40MHz as 38mA, and I sortof remember a dsPIC at 120MHz is
about 180mA(?).  If so, that's only 1.6x more current for the dsPIC after
adjusting for the clock speed ratio.

> but overall it looks like the
> dsPIC30F3013 can be expected to draw roughly two and a half to
> three times the operating current as a PIC18F242 operated at the
> same clock frequency.

For the single measured case.  I'm not trying to minimize what you did, but
it's important to note the your data is interesting and a useful guide, but
that there is no substitute for the specified maximum currents when
designing a circuit.  (I know you know this, but I want to make sure others
watching this look at it with the proper perspective.)

> This is my first dsPIC project, and my initial impression is that
> while the learning curve is big (not difficult, just a lot of
> work), so is the payback: these things are REALLY easy to work
> with.

I agree wholeheartedly.  I find the dsPICs easier to program than the 12,
16, or 18 PICs.


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

2005\09\11@100943 by Jan-Erik Soderholm

face picon face
Olin Lathrop wrote :

> I agree wholeheartedly.  I find the dsPICs easier to program
> than the 12, 16, or 18 PICs.

Without knowing the finer details, one thing that *seems*
harder with the dsPIC's, is to get support in some of the
common hobbyist-oriented PIC programmers... ;-) ;-)

Best Regards,
Jan-Erik.



2005\09\11@100957 by Xiaofan Chen

face picon face
So please post some useful examples in order to prove this.

I have not done any dsPIC yet. Looks like a nice MCU cum
low end DSP. Still the examples are so scarce so no newbies
dare to dive in. The programmer support is also a problem.
The only cheap solution is an ICD2 clone which can program
dsPICs and debug them. Anyway, we have such a long
thread of "dsPIC for hobbyists".

Regards,
Xiaofan

On 9/11/05, Olin Lathrop <spam_OUTolin_piclistTakeThisOuTspamembedinc.com> wrote:

> I agree wholeheartedly.  I find the dsPICs easier to program than the 12,
> 16, or 18 PICs.
>
>
> *****************************************************************
> Embed Inc, embedded system specialists in Littleton Massachusetts
> (978) 742-9014, http://www.embedinc.com

2005\09\11@103104 by olin piclist

face picon face
Xiaofan Chen wrote:
>> I agree wholeheartedly.  I find the dsPICs easier to program than
>> the 12, 16, or 18 PICs.
>
> So please post some useful examples in order to prove this.

Most of the dsPIC projects I've done can not be publicly disclosed.
However, my PIC development environment at http://www.embedinc.com/pic has
some dsPIC support, and I did release the source code for my new power
factor correction technique that was described in the January 2005 issue of
Circuit Cellar.


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

2005\09\11@104157 by olin piclist

face picon face
Jan-Erik Soderholm wrote:
> Without knowing the finer details, one thing that *seems*
> harder with the dsPIC's, is to get support in some of the
> common hobbyist-oriented PIC programmers... ;-) ;-)

A few months ago the consensus was that anyone messing with dsPICs would be
using at least an ICD2 anyway, and that therefore there wouldn't be much
demand for a hobbyist programmer to support dsPICs.  I've seen a lot of
hobbyist complaining about the lack thereof lately, so has something changed
or are they not thinking this thru all the way?

Do you honestly think I would sell a reasonable amount of additional
EasyProgs if it supported dsPICs?  The host software is already tested and
working, and I've got the ProProg firmware that I should be able to port
without too much trouble.  The downside is that dsPICs won't be programmable
in the ZIF socket because they have a completely different pinout, and of
course I have limited bandwidth so this would be done at the expense of
something else, like adding 16F88 support.

OK, how about a show of hands?  I'm not going to hold anyone to this, but
who out there would personally be inclined to buy an EasyProg (in any form)
if it:

supported dsPICs?
16F88?
Any other PIC?


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

2005\09\11@111407 by davedilatush

picon face
Olin Lathrop wrote...

>Dave Dilatush wrote:
[snip]
{Quote hidden}

Agreed.  There's also no substitute for a data sheet containing
real numbers instead of long columns of nothing but "TBD", which
is all I've seen so far on the 30F3013.

Maybe MChip will grace us with some hard numbers "real soon
now"...

DD

2005\09\11@114442 by John Nall

picon face
Olin Lathrop wrote:

>> OK, how about a show of hands?  I'm not going to hold anyone to this, but
>who out there would personally be inclined to buy an EasyProg (in any form)
>if it:
>
>supported dsPICs.
>  
>

(Visualize hand going up).  I'd buy one (visualize Yul Brynner climbing
aboard the wagon with the coffin in it, in "The Magnificent Seven" and
growling in that Russian accent, "Oh, hell, I'll drive  the damned
thing!")  Seriously, I would buy one.  Not because I particularly need
it, having an ICD2, plus Wouter has kind of promised to add dsPIC
support to the Wisp628 and I have one those.  But I would like to see
the EasyProg have the capability to do that, and am willing to do a
little subsidy to help the project.

Besides, ever since Olin got into marketing he has been easier to get
along with, and THAT is worth a lot.  :-)

JOHN

2005\09\11@193050 by Kevin

flavicon
face

Well, I already bought one and have been patiently waiting
for the 16F88 support :)

~Kevin

On Sun, 11 Sep 2005, Olin Lathrop wrote:

{Quote hidden}

> -

2005\09\11@204603 by olin piclist

face picon face
Kevin wrote:
> Well, I already bought one and have been patiently waiting
> for the 16F88 support :)

After I saw the other responses I started looking into what it would take to
port the dsPIC firmware from the ProProg to the EasyProg.  I'm about 750
lines into the main 950 line module so I'm going to see this thru first.
I'm not sure yet if there is room in the 16F648A.  If not, I'll release a
separate firmware version that supports dsPICs but has something else tossed
out.  Who needs all those wussy 16F and 18F PICs anyway. ;-)

16F88 support will be next.  That's what I was going to do until the
discussion earlier today.  I've already got the samples in hand.


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

2005\09\11@210101 by Howard Winter
face
flavicon
picon face
EasyProg PICs supported...

On Sun, 11 Sep 2005 19:30:49 -0400 (EDT), Kevin wrote:

> Well, I already bought one and have been patiently waiting for the 16F88 support :)

Me too, although I haven't mentioned it before - I sort-of assumed Olin would get round to it when he has
time.  

But if it's that or dsPICs, my vote goes for the 16F88 - and in fact also the 8-pin 12F683, and 14-pin 16F684
and 688 (which I believe could not be used in the ZIF socket without an adaptor because of pin-assignment
differences).  Obviously Olin isn't going to sell me another EasyProg, so I don't know how much weight my
opinion carries!

Cheers,



Howard Winter
St.Albans, England


2005\09\11@214517 by Herman Aalderink

picon face
Olin Lathrop wrote:

>Jan-Erik Soderholm wrote:
>  
>
>>Without knowing the finer details, one thing that *seems*
>>harder with the dsPIC's, is to get support in some of the
>>common hobbyist-oriented PIC programmers... ;-) ;-)    
>>
> <>I've seen a lot of hobbyist complaining about the lack thereof
> lately, so has something changed or are they not thinking this thru
> all the way? Do you honestly think I would sell a reasonable amount of
> additional EasyProgs if it supported dsPICs? OK, how about a show of
> hands? I'm not going to hold anyone to this, but who out there would
> personally be inclined to buy an EasyProg (in any form) if it:
> supported dsPICs? 16F88? Any other PIC?


Olin:
I am a hobbyist learning PICs. I enjoy hardware, keep on putting off
firmware.  For programming to get interesting I have to find practical
applications .....
I am a potential buyer of the EasyProg. (it much depends on the
competition).

I follow the dsPIC threads closely, wondering if I should enter
PIC-programming at the dsPIC level.
(but .... at some later time I will need the 'smaller' chips, 10F thru
18F, for applications.)

I told a friend in USA to buy the EasyProg but I cancelled it. Because:

-I could not see the ZIF-socket underneath the 40-pin chip (does it
accommodate 18-pin PICs? I use 16F628 for all my learning).
-I was disappointed that it had no SMPS (I am interested in SMPS). I was
hoping it would run off my 6V/4AH battery or from a 5Volt supply.
(WISP628 can.)
-Serial ports are disappearing. I expect you will go USB in the future.
-dsPICs were on my mind in a negative way. I did not expect the EasyProg
could program dsPICs (I was expecting dsPICs required a more elaborate
programming interface). I did not forget your words 'dsPIC programming
is no trivial matter'. (I assumed you had problems supporting dsPICs.)

-I found alternatives. It was fun to build my own programmer. (my
experience is with parallel-port programmers).

-ICSP works well for me (experimenting/learning environment). I modified
(schematic) a parallel-port programmer for ICSP-only programming (leave
off ZIF-socket, use CMOS bufferchip). The resulting board is small
enough to solder direct to the DB-25 plug. Easy to build, easy to use.
Programmer is out-of-sight. Application and ICSP connector and
power-switch in front of me. Programmer-LED-indicators optional (at the
ICSP connector).
Toggle switch (power to programmer or application but not both) can
easily be added.

dsPIC capability of EasyProg is a major advantage (in purchase-decisions).
A decision is made EARLY (in a PIC-users-life) ..... Beginners (any
kind) need a Programmer >before< programming the first chip.
Your/Olin's ASSURANCE that dsPIC support is coming (firmware changes
only) is good enough for me (till dsPIC is a beginner's chip).
I assume dsPIC is a FAMILY much like the 10F 12F 16F is. IOW all major
dsPICs will be supported.

16F88 has become important because it's pushed as a beginner's chip.
But it is no big guess .... I am sure EasyProg will (eventually) support it.

In the meantime I am awfully busy (can hit myself for spending time on
this msg) :
Programmer-building, learning PIC-code, learning practical interfaces
(serial busses, piezo, read-out, RTC, motor drivers and a lot more ..) .
339 PIClist messages to read ....... (plus OT and EE). (Thanks for all
the GOOD stuff !!!)

Herman in PHL.

2005\09\11@215621 by Chen Xiao Fan

face
flavicon
face
My vote is dsPIC first. I will help you to promote the EasyProg at
various lists and Microchip Forums. ;)-

dsPIC will be a strong selling point for dsPICs. ;)-
You will also be the first one in the world to release to the
public a firmware for dsPIC. You are already one of the first to
release the source code for the host side (dsPICprg and WinPIC ?
for JDMs probably at similar time).

Of course my vote may not count since I do not have a EasyProg.
I have only a Wisp628 with EasyISP. It also takes time to adapt
your firmware for EasyISP. But if your EasyProg supports
dsPICs, I will probably buy one (or make one).

Regards,
Xiaofan

{Original Message removed}

2005\09\12@015734 by PicDude

flavicon
face
> In the meantime I am awfully busy (can hit myself for spending time on
> this msg) :
> ...
> 339 PIClist messages to read ....... (plus OT and EE). (Thanks for all
> the GOOD stuff !!!)


Must be nice.  This particular Piclist folder on my email client has 33911
messages (21422 unread).  This is another large folder prior to this too.  
Not sure why I have all of these though, but I know I'll need it once I
delete it.  Once in a while, I'll search for something, find a thread, read
all messages in a thread, then delete the whole thread at once.

Cheers,
-Neil.


2005\09\12@021354 by Chen Xiao Fan

face
flavicon
face
If you delete it, you can use PIClist.com. PIClist.com
should be quite good in searching messages. Another option
is to use Gmail to read PIClist. It is supposed to be quite
good but I just started to use it. Read the [OT] only from
PIClist.com and it reduces the total messages. Gmane.org
is another option.

Regards,
Xiaofan

{Original Message removed}

2005\09\12@073931 by olin piclist

face picon face
Howard Winter wrote:
> But if it's that or dsPICs, my vote goes for the 16F88

Unfortunately the dsPIC propronents were more vocal and quicker, so I've
already started down this path.  The 16F88 is definitely next though.

> also the 8-pin 12F683, and 14-pin 16F684 and 688 (which I believe could
> not be used in the ZIF socket without an adaptor because of
> pin-assignment differences).

I know the 16F684 is supported because I've been doing a project with it the
last two weekends.  I just checked the web page and I somehow missed adding
that, sorry.  Download all the latest and it should work.  And you're right,
you can't put these in the ZIF socket since the pinout is incompatible.  The
same adapter will for for 12F629/675 16F630/676, etc.

> Obviously Olin isn't going to sell me
> another EasyProg, so I don't know how much weight my opinion carries!

It matters a lot.  Existing customers are my best sales force.  If I keep
you happy, you'll be more likely to tell others about it, and more inclined
to try some prototyping boards, and maybe a ProProg when you go to
production.


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

2005\09\12@080419 by olin piclist

face picon face
Herman Aalderink wrote:
> I told a friend in USA to buy the EasyProg but I cancelled it. Because:
>
> -I could not see the ZIF-socket underneath the 40-pin chip (does it
> accommodate 18-pin PICs? I use 16F628 for all my learning).

Yes, the ZIF socket supports DIPs from .3" to .6" wide.  The web site lists
the chips that work directly in the ZIF socket in their DIP form.  This
includes the 16F628.

> -I was disappointed that it had no SMPS (I am interested in SMPS). I was
> hoping it would run off my 6V/4AH battery or from a 5Volt supply.
> (WISP628 can.)

I don't think you should be caring how the programmer produces the internal
voltages as long as it works correctly.  The EasyProg design was intended to
be low cost, so it's got a 7805 linear regulator and requires the input
voltage to be high enough to down-regulate the 13V programming voltage from
it directly.  I also looked around at wall wart prices and designed it to
work with one of the cheapest ones I could find.  I still think that was a
reasonable approach, although it won't run from a 6V supply.

> -Serial ports are disappearing. I expect you will go USB in the future.

Yes, that is definitely being considered, although I won't even say it's
coming soon.

> -dsPICs were on my mind in a negative way. I did not expect the EasyProg
> could program dsPICs (I was expecting dsPICs required a more elaborate
> programming interface). I did not forget your words 'dsPIC programming
> is no trivial matter'. (I assumed you had problems supporting dsPICs.)

The electrical interface is the same, although Microchip moved all the pins
around.  People were starting to get used to the existing pinout, and we
can't have that going on.

The programming interface protocol however is much more elaborate, and the
documentation sucks.  At least it did back when I added dsPIC support to the
ProProg.  There was a lot of stuff you had to guess at and figure out on
your own how it really worked.  It took about a month to add dsPIC support
when most chips take a few hours to a couple of days depending on how
different they are from something already supported.

> I assume dsPIC is a FAMILY much like the 10F 12F 16F is. IOW all major
> dsPICs will be supported.

Actually the 16F is far from one family when looking at programming
algorithms.  I attached my file listing flash PICs that my programmers don't
yet support and their associated programming spec document number.  Maybe
you can see now why its not so simple to support everything.

However that's one thing Microchip did right with the dsPIC programming
algorithm.  At least the whole mess applies uniformly to all dsPICs.  The
ProProg supports all current dsPICs with the same algorithm.  Hopefully
Microchip will keep the same interface for newer dsPICs.  But I'm not sure
what will happen once they catch word that people have figured it out...


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

2005\09\12@112144 by Jan-Erik Soderholm

face picon face
Olin Lathrop wrote :

> > -Serial ports are disappearing. I expect you will go USB in
> > the future.
>
> Yes, that is definitely being considered, although I won't
> even say it's coming soon.

Does the EasyProg have any problems running
through a standard USB -> serial coonverter ?

Jan-Erik.



2005\09\12@112956 by olin piclist

face picon face
Jan-Erik Soderholm wrote:
> Does the EasyProg have any problems running
> through a standard USB -> serial coonverter ?

In theory it shouldn't because it does nothing fancy.  It only uses RX, TX,
and GND.  However, I tried one USB to serial converter I got at the local
Radio Shack and it didn't work at all.  I have heard others found that some
converters work and some don't.  I don't know which ones.  It's hard to
imagine it's possible to screw up a USB to serial converter to the point
that just RX and TX don't work, but apparently its not that unusual.


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

2005\09\12@115540 by Alan B. Pearce

face picon face
>> Does the EasyProg have any problems running
>> through a standard USB -> serial coonverter ?
>
>In theory it shouldn't because it does nothing fancy.  It only uses RX, TX,
>and GND.  However, I tried one USB to serial converter I got at the local
>Radio Shack and it didn't work at all.  I have heard others found that some
>converters work and some don't.  I don't know which ones.  It's hard to
>imagine it's possible to screw up a USB to serial converter to the point
>that just RX and TX don't work, but apparently its not that unusual.

You may well find this has more to do with the driver software for the port.
Check various combinations of handshake such as having RTS-CTS connected and
DSR-DTR connected, if they are not already strapped inside the Easyprog.
Some drivers seem to expect to have the full gamut of lines in the correct
state, even if you tell the machine that you do not want hardware handshake.

2005\09\12@120450 by Mike Harrison

flavicon
face
On Mon, 12 Sep 2005 11:30:49 -0400, you wrote:

>Jan-Erik Soderholm wrote:
>> Does the EasyProg have any problems running
>> through a standard USB -> serial coonverter ?
>
>In theory it shouldn't because it does nothing fancy.  It only uses RX, TX,
>and GND.  However, I tried one USB to serial converter I got at the local
>Radio Shack and it didn't work at all.  I have heard others found that some
>converters work and some don't.  I don't know which ones.  It's hard to
>imagine it's possible to screw up a USB to serial converter to the point
>that just RX and TX don't work, but apparently its not that unusual.

I suspect the biggest problem is the way they packetise the RS232 data onto the USB timing
structure- the timeouts used can sometimes be adjusted in Device Manager, but any serial thing that
is intolerent of changes in the relative timing of the TX/RX data could well get unstuck.
If it uses the handshake lines I suspect matters will get a lot worse, as the relative timing to the
data lines will certainly be different, and I would suspect it is even possible for things to happen
in a different order than they do on RS232  - e.g. if you send 128 bytes then set DTR, I wouldn't be
at all surprised to see DTR changing before the end of the 128 bytes coming out the other end of the
various  USB FIFOs along the way.

These things are always a compromise, and so theer will always be some things that will not work
quite right,



2005\09\12@120949 by Wouter van Ooijen

face picon face
> In theory it shouldn't because it does nothing fancy.  It
> only uses RX, TX,
> and GND.  However, I tried one USB to serial converter I got
> at the local
> Radio Shack and it didn't work at all.

Olin, can you give the details of that particular converter, if possible
the chip used in it? I have heared similar stories from some of my
customers, I have the suspicion that it is linked to the chip used.

I could send you one of the converters that I sell (prolific) so you can
try it?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\09\12@122435 by olin piclist

face picon face
Wouter van Ooijen wrote:
> Olin, can you give the details of that particular converter, if possible
> the chip used in it? I have heared similar stories from some of my
> customers, I have the suspicion that it is linked to the chip used.

It's probably a combination of chip and not-so-smart driver.  I returned the
USB converter for a refund, and I didn't open it so I have no idea what chip
was in it.  The unit had a Radio Shack logo on it, but I'm sure that's just
someone else's OEM rebranded converter.

> I could send you one of the converters that I sell (prolific) so you can
> try it?

If you want to.  I'm happy to try it, but I'm not sure what you get out of
finding out it works with an EasyProg or ProProg.  Both these units use
standard MAX-232 type converter chips and only connect to the RX, TX, and
GND pins.  One might think that is the lowest common denominator that would
work everywhere, but apparently not.


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

2005\09\12@125244 by Wouter van Ooijen

face picon face
> These things are always a compromise, and so theer will
> always be some things that will not work
> quite right,

But Olin was speaking about using RX/TX only. So unless timing gets in
the way an USB converter that does a decent job should work.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\09\12@125244 by Wouter van Ooijen

face picon face
> If you want to.  I'm happy to try it, but I'm not sure what
> you get out of
> finding out it works with an EasyProg or ProProg.

I sell those converters.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\09\12@140558 by PicDude

flavicon
face
On Sunday 11 September 2005 09:41 am, Olin Lathrop scribbled:
> OK, how about a show of hands?  I'm not going to hold anyone to this, but
> who out there would personally be inclined to buy an EasyProg (in any form)
> if it:
>
> supported dsPICs?
> 16F88?
> Any other PIC?

I'd be very interested in 2 of them in the near future as I intend to start
playing with dsPICs someday.  But other than that and the F88, I'd like it to
support the F818/819.

Cheers,
-Neil.


2005\09\12@142848 by Timothy Weber

face
flavicon
face
Wouter van Ooijen wrote:
>>These things are always a compromise, and so theer will
>>always be some things that will not work
>>quite right,
>
> But Olin was speaking about using RX/TX only. So unless timing gets in
> the way an USB converter that does a decent job should work.

Just naively - I have no idea how these are generally implemented - a
USB converter that decided to enforce the meaning of RTS/CTS itself
might cause problems with a device like this that doesn't implement
those signals, no?
--
Timothy J. Weber
http://www.lightlink.com/tjweber

2005\09\12@154705 by Wouter van Ooijen

face picon face
> Just naively - I have no idea how these are generally implemented - a
> USB converter that decided to enforce the meaning of RTS/CTS itself
> might cause problems with a device like this that doesn't implement
> those signals, no?

Indeed. But a well-behaved converter would not decide that on its own
account - there is are windows calls to set set the handshake behaviour
of a port. The PC USB driver should convey this info to the converter,
whi should act accordingly.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\09\12@164642 by Timothy Weber

face
flavicon
face
Wouter van Ooijen wrote:
> Indeed. But a well-behaved converter would not decide that on its own
> account - there is are windows calls to set set the handshake behaviour
> of a port. The PC USB driver should convey this info to the converter,
> whi should act accordingly.

Oh, right - I see.  Those calls should definitely be respected by a
reasonable driver.
--
Timothy J. Weber
http://www.lightlink.com/tjweber

2005\09\12@171329 by Bob Blick

face picon face
>> Indeed. But a well-behaved converter would not decide that on its own
>> account - there is are windows calls to set set the handshake behaviour
>> of a port. The PC USB driver should convey this info to the converter,
>> whi should act accordingly.
>
> Oh, right - I see.  Those calls should definitely be respected by a
> reasonable driver.

However, an application like Hyperterminal, when used with Prolific
chipped USB converters, is a combination that does not work. And it's
broken in a way that really can't be justified by any combination of
handshake pins.

That being said, USB converters using Prolific chips are the least
expensive and I have not had problems using them with other terminal
programs or in programs I've written using the tpapro serial library.

Cheerful regards,

Bob




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