Searching \ for '[PIC]: [PBK] The PICLIST Development Project' 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/devices.htm?key=pic
Search entire site for: '[PBK] The PICLIST Development Project'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: [PBK] The PICLIST Development Project'
2002\08\29@122437 by Alan B. Pearce

face picon face
>What about a SMD mosfet pack with 4 fets in a device etc?

Well at this stage I'm wondering just how many I would need for the project.
The main use would be to drive a multiplexed 7 segment display, 4 digits,
which I suspect would be running about 30mA per segment to get enough
brightness under multiplex conditions.

The other major use would be to drive the "logic probe" led's, and these
would not need to run much current at all - single digit mA I suspect. I'm
starting to think that ordinary transistors may be the way to go, but the
ULN2xxx driver series are real nice in that they are darlington bipolar, so
it will not matter if the inputs get left open because a beginner hasn't
connected them anywhere, and they have built in resistors so they don't tie
down the outputs to Vbe type levels - read component count.

having said all that, it makes the ULN2803 look better as the Vce sat will
not be a worry, as there will not be much heat due to the low currents.

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2002\08\30@054739 by Alan B. Pearce

face picon face
>I understand what Wouter was asking, however the request (to which he
>happened to respond) was for "translating gpsim to Java".

>But whatever the request may be, there are dozens of ways one can
>interface with gpsim. First there is the gui. I presume that the request

This line of discussion came about from endeavouring to make the PICList
Beginners Kit multi-platform, including Mac's and OS/2 (which one of our
newer members happens to prefer).

My original suggestion had been to write the PC host front end in Delphi to
run under windows, which would allow porting to Kylix to run under *nix. The
other platforms then came out of the woodwork, as being nice to support.

The suggestion was that Java may be the ideal method to make whatever
assembler we use multi-platform, and gpsim is the major non-microchip viable
code that I am aware of at this stage, hence the suggestion to transfer it
to Java.

It may well be that someone else will need to do the conversion to Jave (or
Tk/Tcl, Python etc) from whatever package is perceived to be the ideal one
to convert.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\30@090338 by Bob Ammerman

picon face
I suggested Jave instead of Python, Tcl/Tk, or whatever other languages are
out there for several reasons:

1: 'C++' like syntax. I assume GPSIM is currently written in 'C' or 'C++'
and this would make the port easier.

2: Wide support. JVMs are found almost everywhere.

3: Decent performance. With JIT compilationa and all the other tricks used
by a good JVM you can get pretty good results. I could be wrong, but I don't
think the other suggested languages will be nearly as fast. Finally, with
computers just getting faster, the performance hit of using Java instead of
C/C++ will not be as painful.

Bob Ammerman
RAm Systems


{Original Message removed}

2002\08\30@100204 by Scott Dattalo

face
flavicon
face
On Fri, 30 Aug 2002, Bob Ammerman wrote:

> I suggested Jave instead of Python, Tcl/Tk, or whatever other languages are
> out there for several reasons:
>
> 1: 'C++' like syntax. I assume GPSIM is currently written in 'C' or 'C++'
> and this would make the port easier.

Correct, gpsim is written almost entirely in C++ and has a little bit of
C. I doubt porting 70 thousand lines of C++ code to Java is easy, but I
do imagine it'd be easier than porting to Perl.

>
> 2: Wide support. JVMs are found almost everywhere.
>
> 3: Decent performance. With JIT compilationa and all the other tricks used
> by a good JVM you can get pretty good results. I could be wrong, but I don't
> think the other suggested languages will be nearly as fast. Finally, with
> computers just getting faster, the performance hit of using Java instead of
> C/C++ will not be as painful.

The tacit assumption in your last sentence is that the feature set in the
simulator will remain constant. Windows 3.11 would scream on a 2GHz
Athlon! The problem is that programmers are prolific. For example, gpsim
can now simulate a PIC faster than real time - and at the same time
support several plug in modules and continuously update the gui. My
personal objective has always been to retain performance. Eventually gpsim
may get ported into something like SID.

In my opinion, Java and other interpreted languages may have their place,
but not in gpsim. OTOH, they can serve as a useful glue.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\30@105631 by Alan B. Pearce

face picon face
>For example, gpsim can now simulate a PIC faster than real
>time - and at the same time support several plug in modules
>and continuously update the gui.

Impressive, and nice, but not necessarily the speed needed for the Piclist
Beginners Kit :)


>In my opinion, Java and other interpreted languages may have
>their place, but not in gpsim. OTOH, they can serve as a useful glue

But we would appreciate your input on how to achieve the possibility of
running the PBK front end software (including assembler and simulator) on
the widest possible range of platforms.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\30@132312 by Michael Rigby-Jones

flavicon
face
> -----Original Message-----
> From: Alan B. Pearce [SMTP:.....A.B.PearceKILLspamspam@spam@RL.AC.UK]
> Sent: Friday, August 30, 2002 3:54 PM
> To:   PICLISTspamKILLspamMITVMA.MIT.EDU
> Subject:      Re: [PIC]: [PBK] The PICLIST Development Project
>
> >For example, gpsim can now simulate a PIC faster than real
> >time - and at the same time support several plug in modules
> >and continuously update the gui.
>
> Impressive, and nice, but not necessarily the speed needed for the Piclist
> Beginners Kit :)
>
On the contrary, using a simulator that takes minutes to run something that
should take micro-seconds is very frustrating.  Anyone that's used MPLAB
should be familliar with that!

> >In my opinion, Java and other interpreted languages may have
> >their place, but not in gpsim. OTOH, they can serve as a useful glue
>
> But we would appreciate your input on how to achieve the possibility of
> running the PBK front end software (including assembler and simulator) on
> the widest possible range of platforms.
>
The PC is likely going to represent >99% of all hardware platforms, and of
the 99% of those PC's will be running *nix or Windows.  Is it really worth
expending so much effort in order to support the other few platforms that
could possibly be used?  Especialy given that a PC capable of running Linux
can be picked up for almost pennies.  In that case sticking with C shouldn't
be a huge problem.

Regards

Mike

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads



'[PIC]: [PBK] The PICLIST Development Project'
2002\09\06@094358 by Sean Alcorn (SYD)
flavicon
face
Alan,


> I'm starting to think that ordinary transistors may be the way to go, but
> the ULN2xxx driver series are real nice in that they are darlington bipolar,
> so it will not matter if the inputs get left open because a beginner hasn't
> connected them anywhere, and they have built in resistors so they don't tie
> down the outputs to Vbe type levels - read component count.

We stock TD62003 (ULN2003) and this would certainly be our preference. I am
not sure how the 2803 differs to the 2003 though.

Regards,

Sean

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\09\06@100320 by Alan B. Pearce

face picon face
>We stock TD62003 (ULN2003) and this would certainly be our preference.
>I am not sure how the 2803 differs to the 2003 though.

It is eight drivers wide instead of seven, otherwise seems identical
(without actually going and looking at the small print) and in an 18 pin
instead of 16 pin package.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\09\06@101105 by Wouter van Ooijen

face picon face
> I am not sure how the 2803 differs to the 2003 though.

2003: I can drive a seven-segment LED display!
2803: Do you know seven does not include the decimal point?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\09\09@024837 by Vasile Surducan

flavicon
face
On Fri, 6 Sep 2002, Sean Alcorn (SYD) wrote:

>
> We stock TD62003 (ULN2003) and this would certainly be our preference. I am
> not sure how the 2803 differs to the 2003 though.
>

 2803 may drive 8 loads, 2003 only 7, the first one is twice as a price
like the other ( here )

Both have the same problem when are used by beginners:
-- if they havent a good current limiting protection they will burn.

For 7 seg display I suggest you the cmos 74HC595. Self limited current
output with minimum tricks.

best, Vasile

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


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