Searching \ for 'Greetings from Microchip !!!' 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=microchip
Search entire site for: 'Greetings from Microchip !!!'.

Truncated match.
PICList Thread
'Greetings from Microchip !!!'
1995\05\15@194225 by BBoles

flavicon
face
    Hello, PICLISTER's.  Yes, the factory is actually listening.  We have
    been duly monitoring the various conversation threads looking for your
    great ideas for improvements to our products, etc.

    On Friday, I asked if a moderator was present.  We absolutely do not
    intend to pollute the list with marketing type stuff.  We maintain a
    BBS for that.  Other than some very specific items, we will rarely
    post here.  We also won't be doing customer support here either.

    By the way, it is my job to specify the new PIC devices.  So, if
    there's a PIC you want....

    Regards, Brian Boles.                         spam_OUTbbolesTakeThisOuTspammicrochip.com

1995\05\16@044716 by Errington A

flavicon
face
>>     By the way, it is my job to specify the new PIC devices.  So, if
>>     there's a PIC you want....
>>
>>     Regards, Brian Boles.                         .....bbolesKILLspamspam@spam@microchip.com
>
>more variety in eeprom pics (akin to the c84)...

Me too!!

=:^)


Andrew Errington

1995\05\16@061429 by Adrian Godwin

flavicon
face
Brian Boles wrote :
>      BBS for that.  Other than some very specific items, we will rarely
>      post here.  We also won't be doing customer support here either.

That's a pity - I find email a lot more accessible than the BBS, since
it integrates with the rest of my work environment. Using the BBS is only
possible from home, and requires a standalone comms program so it
isn't easy to include examples or save useful tips. FTP is a good deal
more user-friendly than BBS protocols, too, so it's a shame that the
FTP filebase seems to lag behind.

Perhaps a more automatic gateway could be set up, so that both sorts of
users could benefit equally ? Of course, I'm not suggesting that all the
BBS comments should be echoed to _this_ list, nor that all customer support
should be conducted in public - but I do think that internet-based forms
of communication are a good deal more convenient than a standalone BBS,
even given the convenient access via Compuserve.

-adrian

1995\05\16@101623 by Henri Schultze

flavicon
face
>      By the way, it is my job to specify the new PIC devices.  So, if
>      there's a PIC you want....
What about an onboard CAN controller ?
Henri

--
==============> the sanest place is still behind a trigger <=================
[]-----------------------------------[]-------------------------------------[]
||         Henri Schultze            ||Magdeburg D 39122 Alt-Fermersleben 88||
||   henrispamKILLspamipe.et.uni-magdeburg.de   ||         The Cracker Company         ||
[]-----------------------------------[]-------------------------------------[]

1995\05\16@111615 by Paul Greenwood

flavicon
face
>      By the way, it is my job to specify the new PIC devices.  So, if
>      there's a PIC you want....
>
>      Regards, Brian Boles.                         .....bbolesKILLspamspam.....microchip.com

Brian,

       I want a PIC with a 12-bit A->D on it instead of an 8-bit!

--

           -- Paul Greenwood --  (EraseMEpablospam_OUTspamTakeThisOuTaustin.ibm.com)

                    AAAAAAAAAaaaaaaaaaaaaaaaccccccccckkkkkk!!!!!!!!!
You brute!  Knock before entering a ladies room!

1995\05\16@115441 by Robert Ellefson

flavicon
face
>>     By the way, it is my job to specify the new PIC devices.  So, if
>>     there's a PIC you want....
>>
>>    Regards, Brian Boles.                         bbolesspamspam_OUTmicrochip.com
>
>more variety in eeprom pics (akin to the c84)...
>
>jory bell

Ditto.  I *like* ISP! (and small smt)

-Bob Ellefson

1995\05\16@120733 by Maurice Rabb

flavicon
face
>Brian Boles wrote :
>>      BBS for that.  Other than some very specific items, we will rarely
>>      post here.  We also won't be doing customer support here either.
>
>That's a pity - I find email a lot more accessible than the BBS, since
>it integrates with the rest of my work environment. Using the BBS is only
>possible from home, and requires a standalone comms program so it
>isn't easy to include examples or save useful tips. FTP is a good deal
>more user-friendly than BBS protocols, too, so it's a shame that the
>FTP filebase seems to lag behind.
>
>Perhaps a more automatic gateway could be set up, so that both sorts of
>users could benefit equally ? Of course, I'm not suggesting that all the
>BBS comments should be echoed to _this_ list, nor that all customer support
>should be conducted in public - but I do think that internet-based forms
>of communication are a good deal more convenient than a standalone BBS,
>even given the convenient access via Compuserve.
>
>-adrian

I agree with adrian.  An FTP server would be much more friendly to use.
I have used your BBS, and it is somewhat obnoxious to use.  I used the
Microchip web site a few times and liked it alot.  However, I stopped since
it never seem to be completed.  Does anyone know when it will be completed?

-Maurice Rabb

----------------------
  Maurice Rabb
  Totem Consulting
  (312) 281-6003
  @spam@totemKILLspamspammcs.com
----------------------

1995\05\16@130904 by George Risch

flavicon
face
>>      By the way, it is my job to specify the new PIC devices.  So, if
>>      there's a PIC you want....
>>
>>      Regards, Brian Boles.                         KILLspambbolesKILLspamspammicrochip.com
>
>Brian,
>
>        I want a PIC with a 12-bit A->D on it instead of an 8-bit!
>
>--
>
>            -- Paul Greenwood --  (RemoveMEpabloTakeThisOuTspamaustin.ibm.com)

Hi Brian,

For my two cents (designing high temperature furnace and pressure
controllers), a 12 Bit A/D with 8 channels would be worth alot. But then
again, what makes the PIC so interesting is how cheap it is and its
simplicity. But its nice to dream.....

-George Risch (spamBeGonegar110spamBeGonespampsu.edu)

1995\05\16@135131 by Gordon Couger

flavicon
face
>      By the way, it is my job to specify the new PIC devices.  So, if
>      there's a PIC you want....
What about an onboard CAN controller ?
If you do a CAN controler Do it so it will do both the regular and
wide addressing mode. I think you will find a wider market.
Gordon

1995\05\16@180748 by gorden

flavicon
face
On Mon, 15 May 1995, jory bell wrote:

> >     By the way, it is my job to specify the new PIC devices.  So, if
> >     there's a PIC you want....
> >
> >     Regards, Brian Boles.                         TakeThisOuTbbolesEraseMEspamspam_OUTmicrochip.com
>
> more variety in eeprom pics (akin to the c84)...
>
> jory bell
>

Yes exactly!  How about a 16c84 with SCI and SPI.

Jason Gorden

1995\05\16@181153 by Charles Manning

flavicon
face
Much of my stuff is interconnected with other gizzmos via serial
connections (RS232, RS485 etc) and I have to write bit-bashing code for
the small parts. This eats into the limited RAM and cycles and must be
scheduled by the timer interrupt if you want to do much else.

Nirvana for me is a modified 16C84 with:

20 pin skinny = 16C84 + rx and tx pins.
On-chip UART
More on-chip data EEPROM (maybe 256 bytes rather than 64 bytes)
A bit more RAM (128 bytes?)

A 28 pin variant of the above with 8 more IO pins would also be major
cool! While I'm being greedy, maybe this beast could have 2k program
memory.

I really think that the small PICs (16x) are great in their niche. I
would not use the 17x in a hurry, rather using other devices such as the
8051.

-- Charles

1995\05\17@050152 by R J GAUTIER

flavicon
face
> If there's a PIC you want...

I'd like to second the call for a PIC with onboard CAN controller.

(In fact, CAN *and* UART would be even nicer...)

Bob G

1995\05\17@123825 by Doug Sellner

flavicon
face
>     Hello, PICLISTER's.  Yes, the factory is actually listening.  We have
>     been duly monitoring the various conversation threads looking for your
>     great ideas for improvements to our products, etc.
>
>     On Friday, I asked if a moderator was present.  We absolutely do not
>     intend to pollute the list with marketing type stuff.  We maintain a
>     BBS for that.  Other than some very specific items, we will rarely
>     post here.  We also won't be doing customer support here either.
>
>     By the way, it is my job to specify the new PIC devices.  So, if
>     there's a PIC you want....
>
>     Regards, Brian Boles.                         RemoveMEbbolesspamTakeThisOuTmicrochip.com


I'd like EERAM on a few more low cost devices.

Doug Sellner
Beach Tech
4131 Vincent Avenue South
Minneapolis MN 55410

Voice (612) 924-9193 x 521
Fax   (612) 926-1145

Internet: dsellnerEraseMEspam.....embay.com

1995\05\19@105239 by iek

flavicon
face
>     By the way, it is my job to specify the new PIC devices.  So, if
>     there's a PIC you want....
>
>     Regards, Brian Boles.                         EraseMEbbolesspammicrochip.com

I have a feeling you may have a large number of requests ;-)
Note, I think some of people may go over the top, I hope these ideas
are both reasonable and salable to 'Big' customers. So here goes:

1) A 14 bit PIC with 2/4k of EEPROM,
  a 'real' i2c port, 128 bytes of RAM and a stack (* see below)
2) The above with OTP/EPROM and 20MHz
3) A couple of 14bit processors with a CAN bus (18pin small resource and 40pin l
arge
  resource)
4) A Low voltage (sub 1.5 volt) processor would be really nice sometimes.

Thanks

=%-)

Ian

(*)  A stack would be really useful for producing high level languages/forth's a
nd
 clean up interrupt code. I figure a 16 byte stack would be OK on a PIC type
 of device. The optimal interface would be two registers one pushes w (when wri
tten
 to i.e. movwf'ed) and pops into w (when read i.e. movf reg, 0'ed) A second reg
ister
 would be the current top of stack for read and write.  This would mean no new
 instructions would be required and the stack could be made from 8x16bit shift
 registers + glue logic.

1995\05\19@111809 by Adrian Godwin

flavicon
face
>      By the way, it is my job to specify the new PIC devices.  So, if
>      there's a PIC you want....
>

I echo other writer's enthusiasm for the EEPROM PICs, though they're
made less useful by the lower speed - if this limitation is an inherent
problem with putting EEPROM on chip, then the EPROM and OTP parts will
stay important.

I do find the timer structure on the PICs too simple - capture and
one-shot functions would be useful (I think this is partly addressed
by the 16c64 timer block so the wider use of this design would be good).
Almost all uC timers seem to suffer from speed limitations due to the need
to synchronise incoming edges to internal clocks. How about a timer block
that can :

 - use a long prescaler, synchronised by the read operation rather than
   during counting, so it can count as fast as the crystal prescaler.
   I know that the

 - perform phase comparisons between a pair of timer registers so the
   PIC can be used as a single-chip frequency synthesiser (this might
   be possible in software using a processor loop as one counter,
   but I don't know if the phase comparison can be done without
   introducing jitter.

 - provide outputs from the timers as well as inputs, so that PWM
   and PPM can be generated without an interrupt or polling loop
   latency between the timer overflowing and the output bit changing.

For the R/C people who read this list, I'm thinking of an R/C receiver
with a single-chip decoder/synthesiser, performing any mixer / trim
adjustments in the decoder instead of the transmitter so that there's
no need for multiple model memories in the TX.  A related application
is a decoder with soft error detection : instead of falling back to
fixed servo positions when the signal is lost, error correction should
be performed to get limited functionality from a poor signal - slowed
servo movement perhaps, or coarser positioning.

-adrian

1995\05\19@142942 by Tim Braun

flavicon
face
> Subject:      Re: Greetings from Microchip !!!

>     By the way, it is my job to specify the new PIC devices.  So, if
>     there's a PIC you want....
>
>     Regards, Brian Boles.                         RemoveMEbbolesEraseMEspamEraseMEmicrochip.com

The small ones are good (18 pin), and the large ones look good (40 pin)
but I think you 28 pin middle line could use some 'beefing up'.

If you put your 14 bit core with 128/36 bytes of ram, eeprom program memory
version and eprom program memory versions (1K/2K versions), maybe an SCI or
SPI port, one TMR0, into a 28 pin package (20 i/o's), that'd be good.

Any 14-bit eeprom program memory version with a little more i/o would be good.

Any 12-bit version with eeprom program memory would be good.

Adding serial programmability to the above 12-bit eeprom version would be good.

Tim Braun                             |
Continental Healthcare Systems Canada | Voice: 204-942-2992 ext 228
1900-155 Carlton St                   | FAX:   204-942-3001
Winnipeg, Manitoba, Canada R3C 3H8    | Email: RemoveMEtimspam_OUTspamKILLspamchs.mb.ca

1995\05\21@173837 by Doug Sellner

flavicon
face
RE: Pic dream List

I'd like a stack for data, PUSH W,  POP W

Could save reduce need static variables

Doug Sellner
Beach Tech
4131 Vincent Avenue South
Minneapolis MN 55410

Voice (612) 924-9193 x 521
Fax   (612) 926-1145

Internet: RemoveMEdsellnerTakeThisOuTspamspamembay.com

1995\05\24@132420 by Chuck McManis

flavicon
face
> One of my visions of nervanah [sic], is a way to use multiple
> PICs, via a 1 or two wire network, that takes little or
> no CPU time on the PIC to interface with.  Preferably
> allowing the PIC to set an 'address' in a control
> register, then pick up data a byte at a time that has
> been addressed to it, or to a 'broadcast' address that
> all controllers on the same network would pick up.

I don't know what the current geometries Microchip is using in
the PIC but it is certainly technically feasible to put a
limited CD/CSMA network interface into a small piece of silicon.
(not full blown ethernet, just what Jack wants, one or two
bytes of address, one or two bytes of data, and two new interrupts
for transmit buffer empty and receive buffer full.

--Chuck

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