Searching \ for '[PIC]: The PICLIST Development Project: Concession' 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: 'The PICLIST Development Project: Concession'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: The PICLIST Development Project: Concession'
2002\08\19@200309 by Byron A Jeff

face picon face
On Mon, Aug 19, 2002 at 07:18:15AM -0400, Olin Lathrop wrote:

It's time for my concession speech. I'm abandoning my single processor design
and switching my vote to Alan's preliminary design that he posted (with a
few caveats which I'll talk about below)). There were a couple of factors than
changed my mind. Let's start with Olin:

----------------------------------------
> 4  -  The bootloader uses the hardware UART.  New firmware (except for the
> bootloader and the reset vector) can be uploaded into a 16F877 in about 37
> seconds using 115.2Kbaud.
----------------------------------------

That's one thing that cannot be done easily with a single processor design.
In fact I realize that's a deal killer because if the FT232 USB to serial
design is used, that rate can be pumped all the way up to 2 Mbits/Sec. In a
single processor design one cannot afford to give the hardware UART to the
bootloader side as it's too important for developement.

Second is Jason's clarification of his pin monitor:
--------------------------------------------------
The logic monitor (NOT "analyzer", that implies capabilities that it
doesn't have) in my design IS for for displaying output and supplying
input.  Think of it like one of those clip-on monitors that have a LED or
LCD element per IC pin, except that it displays on the computer screen
instead, and has the ability to set individual lines as outputs (with
automatic reversion to a hi-Z input if there's a conflict).  Think of it as
a LED on every port A, B, and C pin of the target PIC, except that you
don't need all those LEDs (I did specify at least one actual LED on the
device, just for real-world experience), and aren't loading the pins nearly
as much as a LED would.  Think of it as an optional pushbutton or toggle
switch on any of those port pins, except that you don't need physical
switches (again, one actual pushbutton specified for real-world experience
with debouncing).

Sample rate?  Tens of times a second perhaps, this is for human-rate I/O.

Storage of samples?  Hardware triggers?  Nonexistant, that's not what this
feature is for.
-----------------------------------------------------

In short virtualizing I/O. This I can see as an extremely useful feature. It
of course gives the crossplatform support junkie in me the willies, but as
long as the specification for the monitor is available I'm sure that one of
us GNUPIC folks can write a monitor in Perl or Python that we'll be able to
use. BTW the gpsim simulator already has the concept of virtual I/O modules
that will run in the simulation. This simply extends the concept further out
to the real hardware I/O pins.

The final nail in the coffin was Alan's initial diagram. I finally realized
that he actually wanted a 3 chip system with one chip dedicated to the host
and the other two as sockets. This makes a lot of sense.

That's why talk isn't necessarily cheap and advocacy is important. Each of
these points have come out in extended discussion.

So I'd like to move on to comments on Alan's initial design...

* Despite all of its faults, the prototyping area has to be a breadboard or
 something that's resuable. I read '...consists of all spare PCB area filled
 with dual in line pads or "measle dot" pads on 0.1" centers'. This would mean
 soldering to use it right?

* Jason's virtual peripheral/logic monitor (VPLM) concept negates the need for
 a lot of physical hardware onboard. It also eliminates the worry about
 running physical wires to components. I'm not quite sure how well we can
 virtualize analog hardware though. But the upshot is that only a limited
 amount of physical I/O is required.

* The primary socket in Alan's diagram needs to come filled with a 16F877A so
 that the box is ready to go from first turn on.

* We need high voltage for HVP somewhere.

* I'd personally be happy if there were at least a connector for an actual
 LCD display. I realize now that it can be virtualized, but it would still
 be nice to be able to connect a physical one to the board somehow.

Excellent job gentlemen! So what's next?

BAJ

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


2002\08\19@234351 by Jason Harper

picon face
BAJ wrote:
> * I'd personally be happy if there were at least a connector for an
actual
>   LCD display. I realize now that it can be virtualized, but it would
still
>   be nice to be able to connect a physical one to the board somehow.

My logic monitor idea can't possibly virtualize a LCD: most people's LCD
code asserts the E signal for only a few cycles, the monitor would almost
certainly miss it.

I guess it wasn't very clear in the original documents, but my design does
effectively include a connector for a LCD: you simply plug it into the
breadboard in a designated space.  There will be 14 consecutive pins on the
breadboard connection that correspond to the standard LCD pinout: probably
PortB for the data pins, some PortA pins for the control signals, the
potentiometer wiper for contrast, and power pins in the appropriate place.
All that is required is that the LCD be the type with a single-row
connector, not the dual-row which seems somewhat more common.
       Jason Harper

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu


2002\08\20@053819 by Alan B. Pearce

face picon face
>It's time for my concession speech. I'm abandoning my
>single processor design and switching my vote to Alan's
>preliminary design that he posted (with a few caveats
>which I'll talk about below)).

Well thanks. I had got to a point where I figured a picture was worth a
considerable number of back and forth words cluttering up the MIT bandwidth
:)

snip .........

>In short virtualizing I/O. This I can see as an extremely
>useful feature. It of course gives the crossplatform support
>junkie in me the willies, but as long as the specification
snip .........

While I like the idea of having the monitor report back to the computer
screen, it does seem to me to take a lot of chip space on the PCB.

How to interface to the target processor?
How to how to interface to the second processor?

The easiest way I see to do this is to have a very long shift register made
of 74HCxxx (whatever the parallel in/serial out part number is, don't have
it immediately to hand) and read them using the SPI hardware in the
programming PIC. (hereinafter called the Interface PIC) which then sends the
data back to the host PC. The shift register is made long enough to read all
pins on both target PIC's, and separated on the screen into the two PIC's
for display. Perhaps a set of commands can be implemented in the Interface
PIC - host PC to select primary/secondary/both targets for display, and the
Interface PIC sends only the appropriate ones to the host.

snip ......

>* Despite all of its faults, the prototyping area has to be a breadboard or
>  something that's reusable. I read '...consists of all spare PCB area
filled
>  with dual in line pads or "measle dot" pads on 0.1" centers'. This would
mean
>  soldering to use it right?

This is going to happen on any prototyping area, unless someone can source a
version of that breadboard that Olin photographed, which can be mounted on a
PCB. It may be that it gets supplied as a separate item in the box, which
the hobby user can screw on, and connect to with patch wires from pins by
the processor I/O pins, and the developer who has bought the unit for
convenience throws the breadboard bit away.


>* Jason's virtual peripheral/logic monitor (VPLM) concept negates the need
for
>  a lot of physical hardware onboard. It also eliminates the worry about
>  running physical wires to components. I'm not quite sure how well we can
>  virtualize analog hardware though. But the upshot is that only a limited
>  amount of physical I/O is required.

See my comments above about the monitor functions. However there is another
couple of bits to consider. On my block diagram I show some push buttons as
input devices. These could be virtualised, again using the SPI function to
feed out to shift registers, but this would mean that the experimenter never
experiences switch bounce, so a couple of real switches will be needed,
perhaps also a rotary encoder. A virtual reset switch could be ideal, but a
separate push button on the board edge for each target would probably suit
those developers who buy the unit for convenience better.

>* The primary socket in Alan's diagram needs to come filled with a 16F877A
so
>  that the box is ready to go from first turn on.

Agreed. It may even be worth having the processor programmed already with a
program that makes one port act as a 8 bit counter so the purchaser can get
used to using the logic monitor functions before trying to do their own
programming. I am thinking that this should already be in the processor, so
the first thing they do is try the monitor rather than load the program off
CD into the processor to try the monitor. It may also assist factory test :)
It would verify that the chip will program, and is not faulty before leaving
the factory :)

>* We need high voltage for HVP somewhere.

Agreed, and I think it should be in my power supply block, rather than
generated by the Interface PIC in the manner used by the ICD. Should be able
to be switched off by the Interface PIC though.

>* I'd personally be happy if there were at least a connector for an actual
>  LCD display. I realize now that it can be virtualized, but it would still
>  be nice to be able to connect a physical one to the board somehow.

I did ponder this, and figured that although there is a defacto standard of
the HD44780, and a sort of defacto standard pinout for the connector they
use, there is enough variation in the pin arrangements that this could be
difficult. The only solution here that I see, if provision is made for an
LCD, is to supply a "deluxe version kit" which has an LCD in the box, and/or
an add-on kit which provides an LCD for which the board is designed.
Unfortunately the add-on kit would need to be relatively high priced, else
10,000 people who never bought the PBK would buy the add-on kit to get a
cheap LCD :) May not be a bad thing to get quantities up for bulk buying
though :)) Else I would certainly consider providing a suitable connector
for it.

>Excellent job gentlemen! So what's next?

Some thought into what could be done for analogue experiments.

Possible items
A potentiometer on an A/D port
Supply an LM35 wired to an A/D port for temperature experiments.
Supply an LM3919 with LED bar graph wired to a PWM port for analogue output
experiments - more rugged than a meter, and less expensive than a DVM chip
and display.

No-one has passed any comment on what I have suggested as the physical form
of the PCB.

Beyond that it is time to start coming up with proper circuits and software
I believe. I am prepared to do circuits in Orcad, but it will take time, as
I need to fit it into spare time.

--
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\20@074930 by Olin Lathrop

face picon face
I am not getting envolved in the discussion of what this PBK thing should
be.  I'm only responding about certain points of fact and misconceptions.

> > 4  -  The bootloader uses the hardware UART.  New firmware (except for
the
> > bootloader and the reset vector) can be uploaded into a 16F877 in about
37
> > seconds using 115.2Kbaud.
>
> That's one thing that cannot be done easily with a single processor
design.
> In fact I realize that's a deal killer because if the FT232 USB to serial
> design is used, that rate can be pumped all the way up to 2 Mbits/Sec.

This should not imply, however, that a 16F877 can then be programmed in 2
seconds.  The limiting factor is the time it takes the 877 to write to its
own program memory.  One time I worked out how long it would take to
transfer all the bytes at the full 115.2Kbaud rate, and I sorta remember the
answer was around 5 seconds.  In any case I remember the conclusion was that
the upload time was dominated by the flash memory write time.


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

--
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\22@101922 by Byron A Jeff

face picon face
On Mon, Aug 19, 2002 at 11:31:59PM -0400, Jason Harper wrote:

Hmmm,

I go away for a couple of days because I'm starting a new gig and all the
conversation stops. I presume that no discussion means virtual agreement?

I'll answer all of the responses so far here:

{Quote hidden}

If we're willing to compromise by limiting the port that the virtual LCD can
be attached then a small bit of hardware, a latch or a flipflop, can be
used to extend the cycle a bit by latching the data.

I think it's worth investigating.

>
> I guess it wasn't very clear in the original documents, but my design does
> effectively include a connector for a LCD: you simply plug it into the
> breadboard in a designated space.

I'm sure it was clear, but obscured in my mind by the other issues on the
table and the time.

>  There will be 14 consecutive pins on the
> breadboard connection that correspond to the standard LCD pinout: probably
> PortB for the data pins, some PortA pins for the control signals, the
> potentiometer wiper for contrast, and power pins in the appropriate place.

Might I suggest conservation by using a 4 bit interface? That'll limit the
port exposure to a single 8 bit port for both control and data. Same pinout
of course, but the extra 4 data bits simply goes unused.

> All that is required is that the LCD be the type with a single-row
> connector, not the dual-row which seems somewhat more common.

I figure that adapter cables can be used to rectify whatever differences that
exists between the different pinouts. We probably should just pic one standard
and go with it....
----------------------------------------------------
Olin chimes in...

{Quote hidden}

No. Not at all. It just that it'll turn the bottleneck to the programming time
and not the interface speed as you alude to below...

>The limiting factor is the time it takes the 877 to write to its
>own program memory.  One time I worked out how long it would take to
>transfer all the bytes at the full 115.2Kbaud rate, and I sorta remember the
>answer was around 5 seconds.  In any case I remember the conclusion was that
>the upload time was dominated by the flash memory write time.

But a bitbanged interface would probably have issues at that speed. Therefore
the hardware UART is a critical component on the infrastructure side of things.
-------------------------------------------------------
And Alan....

{Quote hidden}

Use the I/O pins of the infrastructure PIC (iPIC).

>How to how to interface to the second processor?

I'm still trying to figure that one out. I had always envisioned a two chip
system which would be an analogue to your iPIC and primary socket. Since the
iPIC would have complete control over the primary socket PIC it would be
possible to tie I/O pins directly and configure which would be active during
a development session. But I'm not sure how to proceed with 2 secondary
processors because neither will have control over the other...


{Quote hidden}

Maybe. The problem is that you lose the bidirectional capability that the
iPIC's I/O pins give you directly, therefore losing flexibility.

{Quote hidden}

That's one avenue. The other is the flip side of that: the main prototyping
unit always comes with a breadboard, and then there's a separate final product
PCB that's completely solder masked. The RatShack does that with their
breadboard. Makes a lot of sense to me.

{Quote hidden}

I think Jason had the right idea, few physical devices and the potential for
lots of virtual ones. So a physical button or two would be fine, then have
the ability to have 6,8,10 or more virtual ones.

>perhaps also a rotary encoder. A virtual reset switch could be ideal, but a
>separate push button on the board edge for each target would probably suit
>those developers who buy the unit for convenience better.

That's all fine.

>
>>* The primary socket in Alan's diagram needs to come filled with a 16F877A
>so
>>  that the box is ready to go from first turn on.
>
>Agreed. It may even be worth having the processor programmed already with a
>program that makes one port act as a 8 bit counter so the purchaser can get
>used to using the logic monitor functions before trying to do their own
>programming.

Wouldn't hurt.

> I am thinking that this should already be in the processor, so
>the first thing they do is try the monitor rather than load the program off
>CD into the processor to try the monitor. It may also assist factory test :)
>It would verify that the chip will program, and is not faulty before leaving
>the factory :)

That's true too.

>
>>* We need high voltage for HVP somewhere.
>
>Agreed, and I think it should be in my power supply block, rather than
>generated by the Interface PIC in the manner used by the ICD. Should be able
>to be switched off by the Interface PIC though.

Correct.

{Quote hidden}

Well you've seen my couple of thoughts on this above. If the LCD can be
virtualized properly, there's no need for a physical one to come with the unit,
just a socket. Again we just pick one socket style and then it's up to the
user to get a matching connector for it. We could sell those separately for
example.

>
>>Excellent job gentlemen! So what's next?
>
>Some thought into what could be done for analogue experiments.
>
>Possible items
>A potentiometer on an A/D port

Through an opamp voltage follower so that the input is independant of the
current impeadance of the the pot. Personally I'd key this as a input device
rather than an exercise in using the A/D.

>Supply an LM35 wired to an A/D port for temperature experiments.

I'd leave this one out as temp is a bit specialized and there's more than one
useful way to do it. For example I now swear by DS1620 digital themometer/
thermostat chips.

>Supply an LM3919 with LED bar graph wired to a PWM port for analogue output
>experiments - more rugged than a meter, and less expensive than a DVM chip
>and display.

Only if it's virtual. I don't think there's any need for actual physical
hardware for this activity.

>
>No-one has passed any comment on what I have suggested as the physical form
>of the PCB.

No comment because I'm sure that it matters much. What's on the board is what's
important to me.

>
>Beyond that it is time to start coming up with proper circuits and software
>I believe. I am prepared to do circuits in Orcad, but it will take time, as
>I need to fit it into spare time.

Anything you bring to the table will be appreciated.

BAJ

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


2002\08\22@113741 by Alan B. Pearce

face picon face
>I go away for a couple of days because I'm starting a
>new gig and all the conversation stops. I presume that
>no discussion means virtual agreement?

<Big Grin> Well I suspect some of it may be that I did a diagram and now
it's all left to me :)

The other factor possibly is that once the real work starts, everyone
wanders off :)

... <snip to discussion on virtual monitor> ...

>>How to interface to the target processor?

>Use the I/O pins of the infrastructure PIC (iPIC).

Hmm, this is why I suggested a string of PISO shift registers, clocked in
through the SPI data in port. Some more SIPO registers could be loaded
through the SPI data out port for virtual controls. I don't think there will
be enough pins on the iPIC to have enough monitoring otherwise. The
monitoring ones would always be inputs, so should not be a problem, except
maybe if connected to a port with an analogue signal on it. I guess the
virtual push buttons could be individual pins on one port of the iPIC, with
jumpers allowing them to be connected to any pin of either of the target
processors.



>Well you've seen my couple of thoughts on this above.
>If the LCD can be virtualised properly, there's no need
>for a physical one to come with the unit, just a socket.
>Again we just pick one socket style and then it's up to
>the user to get a matching connector for it. We could
>sell those separately for example.

Hmm, in view of the differences between HD44780 emulations, and the scant
data on any of them, I wonder which we should emulate. :)  I see a problem
with someone designing code for an LCD, using the virtual LCD to get the
code going, then going and purchasing a real unit and expecting the code to
work. Where will they end up complaining about this wotsit development board
that doesn't drive their LCD? My personal feeling is that to do a virtual
LCD is a lot of work. To me it would require a processor on the board to
emulate the LCD because the monitor will not pick up strobe signals fast
enough to carry out the emulation well enough. If one is going to use
another processor, then there may as well be a proper LCD.

I could see use in a virtual 7 segment display though. This would not limit
the functionality of a port, as the display is not strobed to a device
external to a latch external to the processor. I would work on the basis of
using a port bit per segment, maybe allow another couple of (specifiable)
data lines to be used as digit selectors to get a multi-digit display, and
doing the emulation totally in the host PC. It may be that this is how you
envisage doing the LCD, without bothering with the hassle of the CS, RS and
EN lines, but if that is the case, I think you will run into strife as I
outlined above.


>>Possible items
>>A potentiometer on an A/D port

>Through an opamp voltage follower so that the input is
>independant of the current impeadance of the the pot.
>Personally I'd key this as a input device rather than
>an exercise in using the A/D.

Well I saw it as an exercise in learning how to use the A/D, and then the
user can go on and use it for an input device. :) I take your point about an
op-amp though, for two reasons, first it will act as protection to the input
port if external voltages are connected, and will buffer the source
impedance down to a level which will mean it is not a factor in using the
A/D.


>Supply an LM35 wired to an A/D port for temperature experiments.

>I'd leave this one out as temp is a bit specialized and there's
>more than one useful way to do it. For example I now swear by
>DS1620 digital themometer/ thermostat chips.

Well again I saw this as a learning tool, to go from a sensor to a display,
with all the hardware being pre-built on the board. The achievement in
having a sensor that measures something "real" and displays the result will
be a milestone for a beginner. It may be there are other sensors that would
fit the economic model better, but I think they are all less linear than the
LM35, or one of its close cousins. The DS.... series devices are all digital
interface IIRC, and I was looking for a second analogue application to
include on the board.

>>Supply an LM3919 with LED bar graph wired to a PWM port for analogue
output
>>experiments - more rugged than a meter, and less expensive than a DVM chip
>>and display.
>
>Only if it's virtual. I don't think there's any need for actual physical
>hardware for this activity.

Hmm, yes I can see where you are coming from, but I wonder if the monitor
hardware will be able to monitor the PWM waveform, or would you expect to
dedicate a CCP module on the iPIC to this purpose? Again I was looking for a
cheap way to have a hardware monitor of an analogue waveform. I also get the
feeling that if we try and have virtual instruments for everything, some of
the "experimenters fun" will disappear. Being able to code a real
"knightrider" display would (to my way of thinking) carry more kudos, than
having it display virtually on the screen. :)




Anyway, I am now doing a little work on a circuit diagram, and investigating
the ins and outs of the FT-232 chips. It seems that in the last few days
(literally) they have announced a new version. have not figured what the
difference is, except it seems it is supposed to be better. :)

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


2002\08\22@201904 by Sean Alcorn (SYD)

flavicon
face
Alan,

> <Big Grin> Well I suspect some of it may be that I did a diagram and now
> it's all left to me :)

I could not view your diagram. What format was it in?
>
> The other factor possibly is that once the real work starts, everyone
> wanders off :)

Not I :-)

Sean

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


2002\08\23@063417 by Alan B. Pearce

face picon face
>I could not view your diagram. What format was it in?

It was a PDF attachment on a previous email to the one in which I made this
comment, but was on the same thread (.... Concession Speech)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2002\08\23@070433 by Sean Alcorn (SYD)

flavicon
face
Alan,

> It was a PDF attachment on a previous email to the one in which I made this
> comment, but was on the same thread (.... Concession Speech)

Yes, I know. I got it, but it came through to me as junk - could you send
another copy direct to my address please?

Thanks,

Sean

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2002\08\23@073908 by Alan B. Pearce

face picon face
>Yes, I know. I got it, but it came through to me as junk - could
>you send another copy direct to my address please?

Done - forwarded the original direct to you. Surprised it was junk as it
reached me OK through the MIT server.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2002\08\23@074010 by Byron A Jeff

face picon face
part 1 585 bytes content-type:text/plain; charset=us-asciiOn Fri, Aug 23, 2002 at 09:03:23PM +1000, Sean Alcorn (SYD) wrote:
> Alan,
>
> > It was a PDF attachment on a previous email to the one in which I made this
> > comment, but was on the same thread (.... Concession Speech)
>
> Yes, I know. I got it, but it came through to me as junk - could you send
> another copy direct to my address please?

Actually it was only sort of junk.

Alan used a very old style of attachment called uuencode/uudecode. So in all
likelyhood I was the only person that actually could read it! I'll attach it
to this message.

BAJ


part 2 15957 bytes content-type:application/pdf (decode)

part 3 136 bytes
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2002\08\23@080013 by Alan B. Pearce

face picon face
>Actually it was only sort of junk.

>Alan used a very old style of attachment called uuencode/uudecode.

Oh OK, so Sean probably won't be able to read what I forwarded anyway.
Thanks for reposting it.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2002\08\23@081008 by Sean Alcorn (SYD)

flavicon
face
Alan,

>> Alan used a very old style of attachment called uuencode/uudecode.

What does he mean by old? :-)

> Oh OK, so Sean probably won't be able to read what I forwarded anyway.

No. I could open the second one without any problem. And I am on the same
machine as last time. ???

Cheers,

Sean

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2002\08\23@082921 by Olin Lathrop

face picon face
> Alan used a very old style of attachment called uuencode/uudecode. So in
all
> likelyhood I was the only person that actually could read it! I'll attach
it
> to this message.

MS Outlook Express decoded it fine, although MIME base64 encoding would have
been more sensible.


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

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2002\08\23@143658 by Rob Hamerling

flavicon
face
Byron A Jeff wrote:

[PDF attachment]
> I'll attach it to this message.

That came over much better, could display it with Acrobat from
Mozilla.

In the output area I see several ULN200x-s applied. To me it seems
more obvious to use ULN2803/4 with 8 ports each to 'see' also the
8th port of the register. Allows the use of the decimal point of
7-segment displays (as extra boolean indicator), and the use of
eight discrete LEDs.

Regards, Rob.

--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2002\08\28@090701 by Alan B. Pearce

face picon face
>In the output area I see several ULN200x-s applied. To me it seems
>more obvious to use ULN2803/4 with 8 ports each to 'see' also the
>8th port of the register. Allows the use of the decimal point of
>7-segment displays (as extra boolean indicator), and the use of
>eight discrete LEDs.

Fair enough. Will look into getting those.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2002\08\29@052805 by Alan B. Pearce

face picon face
>>In the output area I see several ULN200x-s applied. To me it seems
>>more obvious to use ULN2803/4 with 8 ports each to 'see' also the
>>8th port of the register. Allows the use of the decimal point of
>>7-segment displays (as extra boolean indicator), and the use of
>>eight discrete LEDs.
>
>Fair enough. Will look into getting those.

Hmm, found them on the On Semiconductor site, but they only come as an 18
pin DIP. Would prefer an SM version for size/space reasons. Anyone any
ideas?


I am in the process of coming up with a bulleted set of lists of what
components I suggest we use, and various other bits and pieces, for comment
from people.

At this stage I suggest that the PC host interface program be written in
Delphi, so it is easily ported to *nix by using Kylix. Development software
for the PIC may need to be a GNU assembler or compiler unless we can
persuade Microchip to supply copies of their CDROM, but the problem I see
with that is the Microchip software would be Windows only, where the GNU
software has a reasonable chance of being ported to both platforms.
Whichever happens, someone will be needed to write the host interface
software.

Comments welcome.

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


2002\08\29@100947 by Rob Hamerling

flavicon
face
Hi Alan,

Alan B. Pearce wrote:
>
> At this stage I suggest that the PC host interface program be written in
> Delphi, so it is easily ported to *nix by using Kylix.

I would be happy to do some PC programming, but I want the result
to be runnable under OS/2 Warp or eCom station too!  I think Java
is a better common base. Not only the source would be portable,
but even the executables, and including the Mac.
Don't know if you ever looked at it or even used it, but you know
I have already build and published a PIC programming program (LVP)
in Java: 'Jisp' for some specific PIC-based devices (see the
LocoNet_Hackers group on Yahoo).  This program doesn't use any
'native' (platform specific)  code and I suppose it could be
extended or modified quite easily for the PIClist Developper.

Regards, Rob.


--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

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


2002\08\29@101211 by Russell McMahon

face
flavicon
face
.. ULN2803 in SMD ?

A friend commented last week that he had recently seen these in SMD. I will
ask him where from


       Russell McMahon



{Quote hidden}

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


2002\08\29@105235 by Alan B. Pearce

face picon face
>.. ULN2803 in SMD ?

>A friend commented last week that he had recently seen these
>in SMD. I will ask him where from

Thanks Russell, appreciate it if you can find out.

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


2002\08\29@105640 by Bob Ammerman

picon face
Java is certainly the way for this!

Bob Ammerman
RAm Systems

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


2002\08\29@105817 by Alan B. Pearce

face picon face
>I would be happy to do some PC programming, but I want the
>result to be runnable under OS/2 Warp or eCom station too!
>I think Java is a better common base. Not only the source
>would be portable, but even the executables, and including the Mac.

Good thought, I had left the Mac out of my consideration, but if there is a
way of including it, then probably worth it. The major problem here would be
to have a suitable compiler/assembler for the PIC that runs under anything
but Windows or *nux.

Feel like doing a Microchip compatible assembler in java ? :) BTW doing this
would almost start to make it PDA compatible, wouldn't it? or is this the
area your meaning with eCom?

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


2002\08\29@110846 by Bob Ammerman

picon face
At least the UI and programmer stuff should be in Java. If necessary the IDE
could spawn external processes to perform the actual assembly/compilation.
With appropriate thought you could adapt to just about any existing tool
set.

Maybe we can get Scott to translate gpasm and gpsim to Java ;-)

Bob Ammerman
RAm Systems

{Original Message removed}

2002\08\29@111103 by Spehro Pefhany

picon face
At 03:51 PM 8/29/02 +0100, you wrote:
> >.. ULN2803 in SMD ?
>
> >A friend commented last week that he had recently seen these
> >in SMD. I will ask him where from
>
>Thanks Russell, appreciate it if you can find out.

Toshiba has them.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
EraseMEspeffspamspamspamBeGoneinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
9/11 United we Stand

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


2002\08\29@120533 by Roman Black

flavicon
face
Alan B. Pearce wrote:
>
> >.. ULN2803 in SMD ?
>
> >A friend commented last week that he had recently seen these
> >in SMD. I will ask him where from
>
> Thanks Russell, appreciate it if you can find out.


Hi Alan, I've worked with these before in the big
package and they get HOT.
Vce SAT is about 1.5v at 350mA and near 2v at the
max current of 500mA. The DIP is rated at 1W max
package dissipation, and I imagine the SMD chip
is rated a lot less. That won't go far with 8
transistors with lousy sat voltages.

What about a SMD mosfet pack with 4 fets in a device
etc?
-Roman

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


2002\08\29@123654 by Brendan Moran

flavicon
face
> At this stage I suggest that the PC host interface program be written in
> Delphi, so it is easily ported to *nix by using Kylix. Development
software
> for the PIC may need to be a GNU assembler or compiler unless we can
> persuade Microchip to supply copies of their CDROM, but the problem I see
> with that is the Microchip software would be Windows only, where the GNU
> software has a reasonable chance of being ported to both platforms.
> Whichever happens, someone will be needed to write the host interface
> software.

Kylix now supports C++ as well as Delphi.  I believe that Borland C++
Builder 6.0 code is directly portable.  I recommend that the development be
done in C++ in Kylix, which would allow almost complete
portability/retargetability.  Short of that, use Java, as it's pretty
universal too.

--Brendan

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


2002\08\29@130630 by Peter L. Peres

picon face
On Thu, 29 Aug 2002, Bob Ammerman wrote:

>At least the UI and programmer stuff should be in Java. If necessary the IDE
>could spawn external processes to perform the actual assembly/compilation.
>With appropriate thought you could adapt to just about any existing tool
>set.
>
>Maybe we can get Scott to translate gpasm and gpsim to Java ;-)

He would likely prefer Tcl. Me too. Tcl runs on all the quoted platforms
afaik.

Peter

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


2002\08\29@145406 by Wouter van Ooijen

face picon face
> >Maybe we can get Scott to translate gpasm and gpsim to Java ;-)
>
> He would likely prefer Tcl. Me too. Tcl runs on all the
> quoted platforms
> afaik.

For a simulator (where speed realy matters) and interpreted language
like Tcl would be a bad choice. And when you consider Tcl have a look at
Python, *much* better for more than a few 100 lines of code, and it has
Tk too (Tk is/was IMHO the biggest reason to use Tcl).

Wouter van Ooijen

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

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


2002\08\29@151853 by Peter L. Peres

picon face
On Thu, 29 Aug 2002, Wouter van Ooijen wrote:

>> >Maybe we can get Scott to translate gpasm and gpsim to Java ;-)
>>
>> He would likely prefer Tcl. Me too. Tcl runs on all the
>> quoted platforms
>> afaik.
>
>For a simulator (where speed realy matters) and interpreted language
>like Tcl would be a bad choice. And when you consider Tcl have a look at
>Python, *much* better for more than a few 100 lines of code, and it has
>Tk too (Tk is/was IMHO the biggest reason to use Tcl).

Maybe. I was thinking of a command line engine written in whatever
(probably C optimized by a guru) with a Tcl front end. Or Python if you
want. The portability and tweakability of Tcl is very large. I don't know
about Python on Macs, it probably runs there too. I am also nervous about
languages where whitespace is significant ;-).

Peter

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-request@spam@spamspam_OUTmitvma.mit.edu


2002\08\29@153532 by Scott Dattalo

face
flavicon
face
On Thu, 29 Aug 2002, Wouter van Ooijen wrote:

> > >Maybe we can get Scott to translate gpasm and gpsim to Java ;-)
> >
> > He would likely prefer Tcl. Me too. Tcl runs on all the
> > quoted platforms
> > afaik.
>
> For a simulator (where speed realy matters) and interpreted language
> like Tcl would be a bad choice. And when you consider Tcl have a look at
> Python, *much* better for more than a few 100 lines of code, and it has
> Tk too (Tk is/was IMHO the biggest reason to use Tcl).

What's the issue? Why would I want to Java-ize gpsim?

Scott

rant

I haven't followed this thread. In fact, for the last few days I haven't
followed any threads. Over the last few weeks the S/N ratio of the OTLIST
(used to be the PICLIST) has plummetted. Sigh. The message labeling junk
only promotes this. But despite resenting the labelling, I finally had no
choice but to block the OT crap.

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


2002\08\29@161400 by Peter L. Peres

picon face
On Thu, 29 Aug 2002, Scott Dattalo wrote:

>On Thu, 29 Aug 2002, Wouter van Ooijen wrote:
>
>> > >Maybe we can get Scott to translate gpasm and gpsim to Java ;-)
>> >
>> > He would likely prefer Tcl. Me too. Tcl runs on all the
>> > quoted platforms
>> > afaik.
>>
>> For a simulator (where speed realy matters) and interpreted language
>> like Tcl would be a bad choice. And when you consider Tcl have a look at
>> Python, *much* better for more than a few 100 lines of code, and it has
>> Tk too (Tk is/was IMHO the biggest reason to use Tcl).
>
>What's the issue? Why would I want to Java-ize gpsim?

You misunderstood. Just Tcl-ize the front end to gpsim. And it was a wish,
not a command ...

Peter

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


2002\08\29@170219 by Gordon Williams

picon face
I would put my vote in for Python as well.  Multi-platform, powerful,
readable and understandable to boot.  Check out http://www.python.org

For any gui work I would suggest wxPython http://www.wxpython.org the python
version of wxWindows and use Boa http://boa-constructor.sourceforge.net/ for
the layout.  Again it is multi-platform. Very cool.  I've used both tk and
wxPython and find wx faster and has a much larger selection of widgets.


Regards,

Gordon Williams



{Original Message removed}

2002\08\29@173920 by Scott Dattalo

face
flavicon
face
On Thu, 29 Aug 2002, Peter L. Peres wrote:

> On Thu, 29 Aug 2002, Scott Dattalo wrote:
>
> >On Thu, 29 Aug 2002, Wouter van Ooijen wrote:
> >
> >> > >Maybe we can get Scott to translate gpasm and gpsim to Java ;-)
> >> >
> >> > He would likely prefer Tcl. Me too. Tcl runs on all the
> >> > quoted platforms
> >> > afaik.
> >>
> >> For a simulator (where speed realy matters) and interpreted language
> >> like Tcl would be a bad choice. And when you consider Tcl have a look at
> >> Python, *much* better for more than a few 100 lines of code, and it has
> >> Tk too (Tk is/was IMHO the biggest reason to use Tcl).
> >
> >What's the issue? Why would I want to Java-ize gpsim?
>
> You misunderstood. Just Tcl-ize the front end to gpsim. And it was a wish,
> not a command ...

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
for Java was in some part associated with dispensing with that interface.
Then there's a CLI interface  (invoke gpsim with the --cli option and your
freed of all those ostentatious windows). Then there's a module interface.
That's primarily intended as a slave interface, but with a couple lines of
clever code the roles are easily swapped. Then there's the library
interface. gpsim is built as a series of modular libraries that are
dynamically linked. One could just as well write another frontend that
links in with the simulation engine to create a custom interface.

All of these interfaces theoretically require no code changes to gpsim. If
you wish to modify the gpsim source, then there are numerous other ways to
interface.

In practice, I'm certain code would have to be added to pacify some new
interface need.  But as it stands now, one could use Tcl, python, perl, or
whatever script glue desired to create a custom PIC simulator. The only
hurdle I see is time.

Scott

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-request.....spamTakeThisOuTmitvma.mit.edu


2002\08\29@191002 by Giles Honeycutt

flavicon
face
Is their an overview or consensus as to what the design is now?  (sorry if I
have not followed the project from the beginning)
I am currious and am trying to understand the project from fragmented
conversation.
Has anyone compiled anything in one location for review?   (to catch up)

Best regards,
Giles

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


2002\08\29@192712 by Tony Nixon

flavicon
picon face
Rob Hamerling wrote:

> I would be happy to do some PC programming, but I want the result
> to be runnable under OS/2 Warp or eCom station too!  I think Java
> is a better common base. Not only the source would be portable,
> but even the executables, and including the Mac.

Does this support the USB/Parallel/Serial ports across different
platforms for interfacing to the PC?

I have a Borland Java package but haven't looked into it much.

--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
.....salesspamRemoveMEbubblesoftonline.com

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


2002\08\29@195941 by Peter L. Peres

picon face
On Thu, 29 Aug 2002, Scott Dattalo wrote:

>whatever script glue desired to create a custom PIC simulator. The only
>hurdle I see is time.

I aggree 150%.

Peter

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-request@spam@spamspam_OUTmitvma.mit.edu


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

flavicon
face
> -----Original Message-----
> From: Bob Ammerman [SMTP:TakeThisOuTrammermanspamspamADELPHIA.NET]
> Sent: Thursday, August 29, 2002 3:49 PM
> To:   PICLISTEraseMEspamMITVMA.MIT.EDU
> Subject:      Re: [PIC]: The PICLIST Development Project: Concession
> Speech
>
> Java is certainly the way for this!
>
> Bob Ammerman
> RAm Systems
>
Ugh.  Have you seen HiTechs new IDE "HiTide" ?  It looks very pretty, has a
potentialy fantastic simulator built in and is all written in Java.  Shame
it runs at the speed of a drugged snail when you try to simulate anything
with peripherals.

I'm sure I have seen an MPASM compatible assembler written in Java somewhere
on the web, (apart from the very nice miSim at
http://www.feertech.com/misim/index.html which is a commercial package).
However, there already exists a 100% MPASM compatible, open source assembler
in the shape of GPASM which has been ported to Win32 IIRC.

Porting GPSIM to Windows would be more usefull activity IMHO (although a
fair amount of effort I suspect).

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


2002\08\30@090321 by Scott Dattalo

face
flavicon
face
On Thu, 29 Aug 2002, Michael Rigby-Jones wrote:

> > -----Original Message-----
> > From: Bob Ammerman [SMTP:RemoveMErammermanEraseMEspamspam_OUTADELPHIA.NET]
> > Sent: Thursday, August 29, 2002 3:49 PM
> > To:   @spam@PICLISTRemoveMEspamEraseMEMITVMA.MIT.EDU
> > Subject:      Re: [PIC]: The PICLIST Development Project: Concession
> > Speech
> >
> > Java is certainly the way for this!
> >
> > Bob Ammerman
> > RAm Systems
> >
> Ugh.  Have you seen HiTechs new IDE "HiTide" ?  It looks very pretty, has a
> potentialy fantastic simulator built in and is all written in Java.  Shame
> it runs at the speed of a drugged snail when you try to simulate anything
> with peripherals.

I haven't seen it, but I've seen similar fiascos. OTOH, when done
properly, Java can be fast.

>
> I'm sure I have seen an MPASM compatible assembler written in Java somewhere
> on the web, (apart from the very nice miSim at
> http://www.feertech.com/misim/index.html which is a commercial package).

This started as an "open source" project and then changed over at some
point to commercial. BTW, this will not happen with gpasm or gpsim. Their
license specific precludes this.

> However, there already exists a 100% MPASM compatible, open source assembler
> in the shape of GPASM which has been ported to Win32 IIRC.

True. AFAIK, The only thing gpasm lacks at the moment is the banksel
macro.

> Porting GPSIM to Windows would be more usefull activity IMHO (although a
> fair amount of effort I suspect).

Someone did this a couple of years ago already. The issue is not gpsim per
se, but with gpsim's dependencies. For example, 2 years ago GTK on Windows
was very flaky. I don't know if that's changed or not.

BTW, gpsim is approaching a 100k lines of code. That's a lot of code to
port to another language! If you want to leverage off gpsim's speed and
maturity then the best way would be to interface to it through the
methods I described earlier.

Scott

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



'[PIC]: The PICLIST Development Project: Concession'
2002\09\01@141745 by Rob Hamerling
flavicon
face
Tony Nixon wrote:
> Rob Hamerling wrote:
>
>
>>I would be happy to do some PC programming, but I want the result
>>to be runnable under OS/2 Warp or eCom station too!  I think Java
>>is a better common base. Not only the source would be portable,
>>but even the executables, and including the Mac.
>
>
> Does this support the USB/Parallel/Serial ports across different
> platforms for interfacing to the PC?

I don't know, I'm running just OS/2.
I think USB is not supported at all.
Regards, Rob.

--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

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


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