Post by thread:[EE]: Zilog Encore series microprocessors

Seem highly capable & value for $ 64 KBytes Flash, 4K linear (hooray!) RAM, free ANSI C, $US49 development system includes ANSI C, C source level debugger. Unlimited breakpoints with on chip 1 wire interface. http://www.zilog.com/z8encore/ Documentation http://www.zilog.com/z8encore/encoredocs.asp Australia / NZ Polykom https://www.polykom.com/index.cfm oz $AU92 for kit $AU18.94 1-?10 $AU14.56/30 $AU12.38/100 64KByte Flash, 4K RAM, 2 x 9 bit UARTS with IRDA, 12 x 10 bit A2D, SPI I2C, DMA, 4 x 16 bit timers * each with PWM - around $US5 in 5K volume. Shame its made by Zilog :-( * - the ghost of the Z80 is very evident here. Device Memory Core Speed (MHz) I/O Lines Interrupts 16-Bit timers PWMs 10-Bit A/D Channels DMA Controller UARTs Operating Voltage Pin Count Flash (Bytes) RAM (Bytes) part / Flash / RAM / MHz / IO / IRQ / Timers / PWM / 10b A2D / DMA / UARTs / Vdd / Pins, pins/ Z8F6401 64K 4K 20 31 23 3 3 8 yes 2 3.0V to 3.6V 40,44 Z8F6402 64K 4K 20 46 24 4 4 12 yes 2 3.0V to 3.6V 64,68 Z8F6403 64K 4K 20 60 24 4 4 12 yes 2 3.0V to 3.6V 80 Z8F4801 48K 4K 20 31 23 3 3 8 yes 2 3.0V to 3.6V 40,44 Z8F4802 48K 4K 20 46 24 4 4 12 yes 2 3.0V to 3.6V 64,68 Z8F4803 48K 4K 20 60 24 4 4 12 yes 2 3.0V to 3.6V 80 Z8F3201 32K 2K 20 31 23 3 3 8 yes 2 3.0V to 3.6V 40,44 Z8F3202 32K 2K 20 46 24 4 4 12 yes 2 3.0V to 3.6V 64,68 Z8F2401 24K 2K 20 31 23 3 3 8 yes 2 3.0V to 3.6V 40,44 Z8F2402 24K 2K 20 46 24 4 4 12 yes 2 3.0V to 3.6V 64,68 Z8F1601 16K 2K 20 31 23 3 3 8 yes 2 3.0V to 3.6V 40,44 Z8F1602 16K 2K 20 46 24 4 4 12 yes 2 3.0V to 3.6V 64,68 4KB and 8KB devices and kit will be available to sample 6/2/03. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email spam_OUTlistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

Russell McMahon wrote: {Quote hidden}>Seem highly capable & value for $ >64 KBytes Flash, 4K linear (hooray!) RAM, free ANSI C, > >$US49 development system includes ANSI C, C source level debugger. Unlimited >breakpoints with on chip 1 wire interface. > > http://www.zilog.com/z8encore/ > > Documentation http://www.zilog.com/z8encore/encoredocs.asp > >Australia / NZ Polykom > > https://www.polykom.com/index.cfm oz $AU92 for kit > > $AU18.94 1-?10 $AU14.56/30 $AU12.38/100 > >64KByte Flash, 4K RAM, 2 x 9 bit UARTS with IRDA, 12 x 10 bit A2D, SPI I2C, >DMA, 4 x 16 bit timers * each with PWM - around $US5 in 5K volume. > >Shame its made by Zilog :-( > > > >* - the ghost of the Z80 is very evident here. > > > >Device Memory Core Speed (MHz) I/O Lines Interrupts 16-Bit timers PWMs >10-Bit A/D Channels DMA Controller UARTs Operating >Voltage Pin Count > >Flash >(Bytes) RAM >(Bytes) >part / Flash / RAM / MHz / IO / IRQ / Timers / PWM / 10b A2D / DMA / UARTs / >Vdd / Pins, pins/ >Z8F6401 64K 4K 20 31 23 3 3 8 yes 2 3.0V to 3.6V 40,44 >Z8F6402 64K 4K 20 46 24 4 4 12 yes 2 3.0V to 3.6V 64,68 >Z8F6403 64K 4K 20 60 24 4 4 12 yes 2 3.0V to 3.6V 80 >Z8F4801 48K 4K 20 31 23 3 3 8 yes 2 3.0V to 3.6V 40,44 >Z8F4802 48K 4K 20 46 24 4 4 12 yes 2 3.0V to 3.6V 64,68 >Z8F4803 48K 4K 20 60 24 4 4 12 yes 2 3.0V to 3.6V 80 >Z8F3201 32K 2K 20 31 23 3 3 8 yes 2 3.0V to 3.6V 40,44 >Z8F3202 32K 2K 20 46 24 4 4 12 yes 2 3.0V to 3.6V 64,68 >Z8F2401 24K 2K 20 31 23 3 3 8 yes 2 3.0V to 3.6V 40,44 >Z8F2402 24K 2K 20 46 24 4 4 12 yes 2 3.0V to 3.6V 64,68 >Z8F1601 16K 2K 20 31 23 3 3 8 yes 2 3.0V to 3.6V 40,44 >Z8F1602 16K 2K 20 46 24 4 4 12 yes 2 3.0V to 3.6V 64,68 >4KB and 8KB devices and kit will be available to sample 6/2/03. > >-- >http://www.piclist.com#nomail Going offline? Don't AutoReply us! >email .....listservKILLspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body > Problems with Zilog, Russ? I bought the eval board from Digikey a couple of weeks ago and have been playing with it a little. The C compiler seems nice along with the assembler and emulator. Zilog brought out a debug pin so that you can examine the entire state of the processor, memory, etc. Jim -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestKILLspammitvma.mit.edu>

>Seem highly capable & value for $ >64 KBytes Flash, 4K linear (hooray!) RAM, free ANSI C, > >$US49 development system includes ANSI C, C source level debugger. Unlimited >breakpoints with on chip 1 wire interface. Bought one at ESC, actually. Zilog puts a lot into their cheap development boards and I expect it'll be neat to play with... But this is a Z8, not a Z80, right? As I was sitting there listening to their spiel on how wonderful the new EZ80 (w ethernet) chips were, I couldn't help but wonder at just how far behind a vendor starts out (in an internet environment) without third part commercial AND open source operating systems. I mean, for similar costs you get something like a Motorola Dragonball processor, and it'll run PalmOS, plus embedded linux, plus the 68k was always nicer than a z80 anyway... Seems to be a generic problem with the "small microcontrollers" trying to move "upward" in overall capability. The "more credible" "large microprocessors" have been moving downward in size and cost at the same time. I mean, tiny little PICs are great for some things, but that doesn't really mean that I just want a BIGGER PIC for the other problems... BillW -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam.....mitvma.mit.edu>

I think what you can do yourself with FPGAs these days is also starting to blur the lines when it comes to choosing a uC...heck, there are even open-source CPU cores for FPGAs now. Granted, working with FPGAs is still a bit of "black art", but when you can buy an Altera development system for $89...well... Conceivably you can roll a fairly high performance system on a $10 FPGA part. -marc On 21/5/03 19:56, "William Chops Westfield" <EraseMEbillwspam_OUTTakeThisOuTCISCO.COM> wrote: {Quote hidden}>> Seem highly capable & value for $ >> 64 KBytes Flash, 4K linear (hooray!) RAM, free ANSI C, >> >> $US49 development system includes ANSI C, C source level debugger. Unlimited >> breakpoints with on chip 1 wire interface. > > Bought one at ESC, actually. Zilog puts a lot into their cheap development > boards and I expect it'll be neat to play with... > > But this is a Z8, not a Z80, right? > > As I was sitting there listening to their spiel on how wonderful the new > EZ80 (w ethernet) chips were, I couldn't help but wonder at just how far > behind a vendor starts out (in an internet environment) without third part > commercial AND open source operating systems. I mean, for similar costs you > get something like a Motorola Dragonball processor, and it'll run PalmOS, > plus embedded linux, plus the 68k was always nicer than a z80 anyway... > Seems to be a generic problem with the "small microcontrollers" trying to > move "upward" in overall capability. The "more credible" "large > microprocessors" have been moving downward in size and cost at the same > time. I mean, tiny little PICs are great for some things, but that doesn't > really mean that I just want a BIGGER PIC for the other problems... > > BillW > > -- > http://www.piclist.com hint: To leave the PICList > piclist-unsubscribe-requestspam_OUTmitvma.mit.edu > -------------------------------------------------- Marc Nicholas Geekythings Inc. C/416.543.4896 UNIX, Database, Security and Networking Consulting -- http://www.piclist.com hint: To leave the PICList @spam@piclist-unsubscribe-requestKILLspammitvma.mit.edu>

i don't fully understand this, quite dumb i know for less than 50 dollars i can buy a development board, including software, hardware and manuals but can i use this board to program zilog micros? and what if i need a different hardware configuration? can i tailor the board functionality to my needs or i just can make practice with it learning how to program Z8s? thank you in advance! Faisal {Quote hidden}>Seem highly capable & value for $ >64 KBytes Flash, 4K linear (hooray!) RAM, free ANSI C, > >$US49 development system includes ANSI C, C source level debugger. Unlimited >breakpoints with on chip 1 wire interface. > > http://www.zilog.com/z8encore/ > > Documentation http://www.zilog.com/z8encore/encoredocs.asp > >Australia / NZ Polykom > > https://www.polykom.com/index.cfm oz $AU92 for kit > > $AU18.94 1-?10 $AU14.56/30 $AU12.38/100 > >64KByte Flash, 4K RAM, 2 x 9 bit UARTS with IRDA, 12 x 10 bit A2D, SPI I2C, >DMA, 4 x 16 bit timers * each with PWM - around $US5 in 5K volume. > >Shame its made by Zilog :-( > > > >* - the ghost of the Z80 is very evident here. > > > >Device Memory Core Speed (MHz) I/O Lines Interrupts 16-Bit timers PWMs >10-Bit A/D Channels DMA Controller UARTs Operating >Voltage Pin Count > >Flash >(Bytes) RAM >(Bytes) >part / Flash / RAM / MHz / IO / IRQ / Timers / PWM / 10b A2D / DMA / UARTs / >Vdd / Pins, pins/ >Z8F6401 64K 4K 20 31 23 3 3 8 yes 2 3.0V to 3.6V 40,44 >Z8F6402 64K 4K 20 46 24 4 4 12 yes 2 3.0V to 3.6V 64,68 >Z8F6403 64K 4K 20 60 24 4 4 12 yes 2 3.0V to 3.6V 80 >Z8F4801 48K 4K 20 31 23 3 3 8 yes 2 3.0V to 3.6V 40,44 >Z8F4802 48K 4K 20 46 24 4 4 12 yes 2 3.0V to 3.6V 64,68 >Z8F4803 48K 4K 20 60 24 4 4 12 yes 2 3.0V to 3.6V 80 >Z8F3201 32K 2K 20 31 23 3 3 8 yes 2 3.0V to 3.6V 40,44 >Z8F3202 32K 2K 20 46 24 4 4 12 yes 2 3.0V to 3.6V 64,68 >Z8F2401 24K 2K 20 31 23 3 3 8 yes 2 3.0V to 3.6V 40,44 >Z8F2402 24K 2K 20 46 24 4 4 12 yes 2 3.0V to 3.6V 64,68 >Z8F1601 16K 2K 20 31 23 3 3 8 yes 2 3.0V to 3.6V 40,44 >Z8F1602 16K 2K 20 46 24 4 4 12 yes 2 3.0V to 3.6V 64,68 >4KB and 8KB devices and kit will be available to sample 6/2/03. > >-- >http://www.piclist.com#nomail Going offline? Don't AutoReply us! >email RemoveMElistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

for less than 50 dollars i can buy a development board, including software, hardware and manuals but can i use this board to program zilog micros? Hmm. Good question. I took a closer look at my kit. The software appears to support Zilog's equivilent of ICSP/ICD, and you get a separate dongle thing that connects from your development PC to the board, and would presumably also connect to other boards/processors supporting the same interface. (This looks like a one-wire bidirectional interface on a 6-pin header. I don't know offhand how much of the Zilog processor lineup supports a compatible interface.) The z8encore CPU being shown off here is one of those 100+pin QFP chips not very friendly with socket-based programming (like ATMega or larger MSP430 chips.) and what if i need a different hardware configuration? can i tailor the board functionality to my needs or i just can make practice with it learning how to program Z8s? The board does not have prototyping areas. It does have headers that appear to allow access to most or all of the z8 pins, as well as rs232, rs485, and IRDA serial connections, several PB switches, a pot connected to the A/D, and 4 5x7 matrix LED displays. I would say that it is primarilly aimed at getting people familiar with the zilog architecture and developement environment, rather than being a general purpose SBC. (so "demo board" might be better than "development board.") BillW -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Russell McMahon <spamBeGoneapptechspamBeGonePARADISE.NET.NZ> wrote: >Seem highly capable & value for $ >64 KBytes Flash, 4K linear (hooray!) RAM, free ANSI C, > >$US49 development system includes ANSI C, C source level debugger. Unlimited >breakpoints with on chip 1 wire interface. > > http://www.zilog.com/z8encore/ I'd be interested in any views on the wisdom of using these parts in a new design. Unfortunately, my most recent experience with Zilog was on a Z80 based CP/M system in about 1982! I don't wish to start a religious war - indeed, my application is probably architecture-neutral apart from one essential requirement (see below). I'm more interested in potential sourcing problems and long-term support than technical optimisation. I need a small microcontroller to do some simple manipulation of data on two serial ports. The bit rates (57,600bps and 19,200bps) rule out bit banging, so two hardware UARTs are pretty essential. Development of the code looks straightforward on any architecture given half-decent tools. As far as I can see, the obvious contenders are the top-end 18F series PICs (e.g. 18F6620) and the DS80C320 series (8051 core), but both seem overblown (price and functionality). I looked at the Rabbit processors as well, but the development tools seemed odd (non-standard C). The Zilog Encore processors and development tools seem like a good fit for the job (I don't need extensive library support). It looks as if some parts are available from distributors now, and Zilog are clearly doing a big marketing push, but I don't want to be caught by sourcing problems further down the line (say in the next 18 months). Any views? Many thanks in advance. -- Ian Chapman Chapmip Technology, UK -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> -----Original Message----- > From: pic microcontroller discussion list > [TakeThisOuTPICLISTEraseMEspam_OUTMITVMA.MIT.EDU]On Behalf Of Alan B. Pearce > Sent: Tuesday, 3 June 2003 5:45 PM > To: RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU > Subject: Re: [EE]: Zilog Encore series microprocessors > > > >I need a small microcontroller to do some simple manipulation of data on > >two serial ports. The bit rates (57,600bps and 19,200bps) rule out bit > >banging, so two hardware UARTs are pretty essential. Development of the > >code looks straightforward on any architecture given half-decent tools. > > How about a PIC with an I2C or SSP Uart from maxim or elsewhere? You don't > mention how much RAM you expect to need for buffering/processing though. > > Appreciate this does not really answer your query, just an > alternative train > of thought. Or an AVR like the Mega128 with 2 uarts and 128K code space,4K SRAM, 4K EEProm. Regular C, GCC AVR port on Unix, eval copies of Codevision AVR etc. If you want to write in ASM AVR Studio is free. ISP programmer costs under $10 when made yourself see : <http://www.kaqelectronics.dyndns.org/avr/Aispcable.html> Regards, Kat. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003 -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

They are available in the uk from Farnell at the moment - #37.55 inc vat by the way ----- Original Message ----- From: "Alan B. Pearce" <A.B.PearceEraseME.....RL.AC.UK> To: <EraseMEPICLISTMITVMA.MIT.EDU> Sent: Tuesday, June 03, 2003 10:44 AM Subject: Re: [EE]: Zilog Encore series microprocessors > >I need a small microcontroller to do some simple manipulation of data on > >two serial ports. The bit rates (57,600bps and 19,200bps) rule out bit > >banging, so two hardware UARTs are pretty essential. Development of the > >code looks straightforward on any architecture given half-decent tools. > > How about a PIC with an I2C or SSP Uart from maxim or elsewhere? You don't > mention how much RAM you expect to need for buffering/processing though. > > Appreciate this does not really answer your query, just an alternative train > of thought. > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Alan B. Pearce <RemoveMEA.B.PearceEraseMEEraseMERL.AC.UK> wrote: >How about a PIC with an I2C or SSP Uart from maxim or elsewhere? You don't >mention how much RAM you expect to need for buffering/processing though. Many thanks for your reply. I considered using a MAX3100 or similar, but my preference is to avoid the software overhead of a 16-bit SPI transfer for every transmitted or received character on one port. The burst data rate on each serial port is the full line rate, but only for a few tens of characters at a time. I was planning to buffer the incoming and outgoing characters in the background with quick interrupt routines, and do the string processing in the foreground. There may be enough time for one of the interrupt routines to talk to the MAX3100 as well, but it's a complication that I'd prefer to avoid. The RAM requirements aren't huge - a few hundred bytes should be enough for buffering and turnaround at a squeeze. However, if I have 4KB to play with then I'll probably fill it up with bigger buffers! As you say, a medium range PIC would otherwise fill the footprint quite well, so I'll reconsider this approach if a dual UART solution has other disadvantages. >Appreciate this does not really answer your query, just an alternative train >of thought. It's always good to hear alternative suggestions. On a slight tangent... Regarding the MAX3100, am I right in thinking that it has a design flaw which prevents it from receiving null characters (ASCII zero) reliably? As I understand it, a "write data" command can also return a pending receive character from the internal FIFO (although Maxim's example code seems to neglect this possibility!). The data sheet says the D0r-D7r field is set to all zeroes when the FIFO is empty, but I don't see any way of differentiating this from a received "all zeroes" character. There is an "R" bit which indicates that the receive FIFO is not empty, but I'd expect this to be updated *after* a pending character is read from the FIFO (i.e. it might be zero even if a char was returned and, with unfortunate timing, it could be one when a char wasn't returned). Am I seeing potential problems where none exists in practice? I'd be interested to hear from anyone who has experience of this. Many thanks once again. -- Ian Chapman Chapmip Technology, UK -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> I need a small microcontroller to do some simple manipulation of data on > two serial ports. The bit rates (57,600bps and 19,200bps) rule out bit > banging, Nonsense! You could use the hardware UART for 57.6Kbuad and software for 19.2Kbaud. There should be no problem with that. > As far as I can see, the obvious contenders are the top-end 18F series > PICs (e.g. 18F6620) Another possible solution is to use two small PICs that communicate between themselves. Two 16F628 come to mind. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> Good point. However, I'd prefer to run at a lower clock rate and let > hardware take the strain. Why? Are you trying to save power, EMI? Otherwise what's the drawback to a higher clock rate. One of the nice things about the 18 family is that you can use a 10MHz crystal and get 40MHz clock internally. > Development time is more important than cost > to me at this stage, so it makes sense to put as many of the low-level > issues into the background as is readily possible. If that's really true and you are already familiar with PICs, grab a 18F6x20 and get on with it! ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

At 11:28 AM 6/3/2003 +0100, Ian Chapman wrote: >Alan B. Pearce <A.B.PearceSTOPspamspam_OUTRL.AC.UK> wrote: > >How about a PIC with an I2C or SSP Uart from maxim or elsewhere? You don't > >mention how much RAM you expect to need for buffering/processing though. > >Many thanks for your reply. I considered using a MAX3100 or similar, but >my preference is to avoid the software overhead of a 16-bit SPI transfer >for every transmitted or received character on one port. I've used the 3100s. If i was to tackle that project again, I'd use small AVRs for that. Much more "brains" and it still ends up as a cheap chip with a crystal. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Olin Lathrop <KILLspamolin_piclistspamBeGoneEMBEDINC.COM> wrote: >Nonsense! You could use the hardware UART for 57.6Kbuad and software for >19.2Kbaud. There should be no problem with that. Thanks for your reply. I didn't give a lot of information in my original posting, so I appreciate you taking the time to ask some good questions. I've explained a bit more below... Regarding hardware versus software, I guess I'm just feeling lazy. I developed an interrupt-driven software UART in a previous application, but I wasn't happy about sampling each incoming data bit at less than 8x rate, which in this case would be 153kHz for 19,200baud. I agree that this is by no means impossible, but surely it would require either foreground processing (tight polling/timing loops) or a large slice of CPU time for interrupt overhead (for background processing). On the other hand, a hardware UART would only interrupt the processor at a maximum rate of 1.9kHz. >Another possible solution is to use two small PICs that communicate >between themselves. Two 16F628 come to mind. This would be particularly good if the data on each serial port could be pre-processed by each PIC, with only a subset of data of common interest shared between the two PICs. Unfortunately this doesn't really work in this application, as the output stream from each port will be a mixture of the two input streams (albeit with some processing), and there's not much opportunity to filter out redundant information from either side. I still think this is a great approach when a lot of parallel processing can be done. I can see that a few PICs sprinkled around a design which is well divided-up can beat a single larger processor, and the code can be simpler (more modular) and easier to maintain as well. >Why? Are you trying to save power, EMI? Otherwise what's the drawback to >a higher clock rate. One of the nice things about the 18 family is that >you can use a 10MHz crystal and get 40MHz clock internally. Power is also a concern as the equipment is battery-powered, but other elements of the design necessarily consume about 100mA, so the processor is a smaller part of the overall problem. I still don't want to waste power on unnecessary extra speed, though. EMI is a consideration, but shouldn't be a major issue. I'd prefer to avoid clocks as high as 40MHz though, so the 4x PLL in the 18F series is a nice advantage (I had forgotten about this!). >If that's really true and you are already familiar with PICs, grab a >18F6x20 and get on with it! I have about equal experience with mid-range PICs (assembler only) and 8051s (C and assembler). The 18 series PICs look good but the issue for me is whether it's better to spend time learning about these or another micro for larger applications. Since this application involves string processing, I'd prefer to develop it with a C compiler and some good libraries on a microcontroller with plenty of resources so I don't have to worry much about optimisation. The obvious choice was another 8051 core, but I wanted to explore some other options. Whichever route I take, it shouldn't be difficult to get this application running. The question for me is whether to explore another micro such as the Zilog Encore, PIC 18 series etc, or just stick with what I know. I hope this explains the context better. Thanks for your interest. I'd also still be interested in any thoughts on the Zilog Encore micros, specifically. Best regards. -- Ian Chapman Chapmip Technology, UK -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> -----Original Message----- > From: pic microcontroller discussion list > [EraseMEPICLISTEraseMEMITVMA.MIT.EDU]On Behalf Of Ian Chapman > Sent: Tuesday, 3 June 2003 10:01 PM > To: @spam@PICLIST@spam@spam_OUTMITVMA.MIT.EDU > Subject: Re: [EE]: Zilog Encore series microprocessors > > > Brent Brown <spamBeGonebrent.brownKILLspamCLEAR.NET.NZ> wrote: > >Another couple of dual UART processors worth a look at (both are > >Flash 8051) are the Winbond W77E58 and several in the Cygnal range. > > Thanks - I'll add them to my list. Even if I don't use them this time, > I'll have a head start the next time I need more than one UART and I'm > feeling lazy. > If you want even more, try the cypress PSOC range IIRC you could configure a fair few of the modules to be uarts, or the Atmel FPGA AVR combo chip (something like fpslip) that you could make multiple UARTS in the FPGA Regards, Kat. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003 -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> Regarding hardware versus software, I guess I'm just feeling lazy. Well you can feel even lazier. Olin has posted to the list, his module for a software uart, sometime in the past. In addition to that his development environment has a hardware uart module. > I developed an interrupt-driven software UART in a previous application, > but I wasn't happy about sampling each incoming data bit at less than 8x > rate, which in this case would be 153kHz for 19,200baud. Why? The only time you really need to do this is during the start bit, and then use an interrupt on the leading edge of the start bit, and time a half bit time, then make sure it really is a start bitn not a noise glitch, and then sample every bit time, making sure there is a valid stop bit finally to > On the other hand, a hardware UART would only interrupt the processor at > a maximum rate of 1.9kHz. And using the above scheme that is what will happen for a software uart, except at the beginning of the start bit. > EMI is a consideration, but shouldn't be a major issue. I'd prefer to > avoid clocks as high as 40MHz though, so the 4x PLL in the 18F series is > a nice advantage (I had forgotten about this!). But don't forget that you do not have to run at such high frequencies. Also think in terms of using a 4MHz crystal or resonator and doing the multiply to end up with the processor internally running at 12MHz. {Quote hidden}> I have about equal experience with mid-range PICs (assembler only) and > 8051s (C and assembler). The 18 series PICs look good but the issue for > me is whether it's better to spend time learning about these or another > micro for larger applications. > > Since this application involves string processing, I'd prefer to develop > it with a C compiler and some good libraries on a microcontroller with > plenty of resources so I don't have to worry much about optimisation. > The obvious choice was another 8051 core, but I wanted to explore some > other options. Well don't forget that one of the free C compilers for PIC's (see http://www.bknd.com/cc5x/downl-stud.shtml )allows you to do linkable modules (but not 18 series). Each module is limited to 1k code, but by doing it modular it should be possible to do a reasonable size program. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email .....listservspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

{Quote hidden}> -----Original Message----- > From: Alan B. Pearce [SMTP:TakeThisOuTA.B.Pearce.....TakeThisOuTRL.AC.UK] > Sent: Wednesday, June 04, 2003 9:50 AM > To: TakeThisOuTPICLISTKILLspamspamMITVMA.MIT.EDU > Subject: Re: [EE]: Zilog Encore series microprocessors > > > I developed an interrupt-driven software UART in a previous application, > > but I wasn't happy about sampling each incoming data bit at less than 8x > > rate, which in this case would be 153kHz for 19,200baud. > > Why? The only time you really need to do this is during the start bit, and > then use an interrupt on the leading edge of the start bit, and time a > half > bit time, then make sure it really is a start bitn not a noise glitch, and > then sample every bit time, making sure there is a valid stop bit finally > to > > > On the other hand, a hardware UART would only interrupt the processor at > > a maximum rate of 1.9kHz. > > And using the above scheme that is what will happen for a software uart, > except at the beginning of the start bit. > Actually, the processor will be interrupted at the bit rate using the above method, i.e. 19.2KHz. Typicaly for a robust software UART, the bit would be sampled multiple times (as the OP stated) which puts the interrupt rate back up to silly levels. Regards Mike ======================================================================= This e-mail is intended for the person it is addressed to only. The information contained in it may be confidential and/or protected by law. If you are not the intended recipient of this message, you must not make any use of this information, or copy or show it to any person. Please contact us immediately to tell us that you have received this e-mail, and return the original to us. Any use, forwarding, printing or copying of this message is strictly prohibited. No part of this message can be considered a request for goods or services. ======================================================================= Any questions about Bookham's E-Mail service should be directed to .....postmasterRemoveMEbookham.com. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email RemoveMElistservspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

>Actually, the processor will be interrupted at the bit rate >using the above method, i.e. 19.2KHz. Whoops, sorry, yes it will be at least 10x the number of interrupts (for an 8 bit word) But the interrupts only need to occur while the word is actually being received, not continuously during the idle time. >Typically for a robust software UART, the bit would be sampled >multiple times (as the OP stated) which puts the interrupt >rate back up to silly levels. Well if the line is really that noisy that this is needed, then I doubt that a hardware uart will receive valid data either. There will be that much noise on the line that there will be so much uncertainty in the position of the start bit the uart will never get started. During the start bit time is the only time I can see that rigorous verification is needed. I am aware that many moons ago there were hardware uart chips that did sample on absolutely every baud rate clock pulse, but what do you really do with all this data? Any sort of majority logic is just as likely to make a wrong decision as a right decision if there is that much noise. If it is a noisy environment then maybe the transmission medium needs changing for something less affected (differential, optical etc). The logic of detecting the leading edge of the start bit, then sampling in the middle of the start bit to ensure that some vaguely possible noise pulse has not got into the system seems as viable as any other method. Then sampling in the nominal centre of each bit to collect the data received, and verify that the stop bit is correct, and produce a framing error flag if not, comes back to a simple and probably as robust a system as multiple samples each data bit. What do you do if you have some samples within the bit time different to other samples? Which are the correct samples? If the data is being used as an instruction to a device then the receiving end instruction parser should be verifying the characters are correct and report an error to the instructing device. Is this going to be any different if the software uart reports a framing error on a multiple sampled word that has different samples within a bit causing the error flag? It strikes me that whatever you do, you need a robust protocol between devices, and it is this which is going to detect the errors however they are flagged. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email spamBeGonelistserv@spam@spam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

> -----Original Message----- > From: Alan B. Pearce [SMTP:TakeThisOuTA.B.PearcespamRL.AC.UK] > Sent: Wednesday, June 04, 2003 10:44 AM > To: PICLISTEraseMEMITVMA.MIT.EDU > Subject: Re: [EE]: Zilog Encore series microprocessors > > I am aware that many moons ago there were hardware uart chips that did > sample on absolutely every baud rate clock pulse, but what do you really > do > with all this data? Any sort of majority logic is just as likely to make a > wrong decision as a right decision if there is that much noise. If it is a > noisy environment then maybe the transmission medium needs changing for > something less affected (differential, optical etc). > All hardware UARTs that I am aware of sample multiple times through the bit with a majority decision. The line wouldn't have to be particularly noisy for a single point sample strategy to fail, just one glitch in the wrong place would produce an error. Of course, you have to weigh up what the application is, there must be thousands of simple bit bashed UARTS working happily all over the world. Mike ======================================================================= This e-mail is intended for the person it is addressed to only. The information contained in it may be confidential and/or protected by law. If you are not the intended recipient of this message, you must not make any use of this information, or copy or show it to any person. Please contact us immediately to tell us that you have received this e-mail, and return the original to us. Any use, forwarding, printing or copying of this message is strictly prohibited. No part of this message can be considered a request for goods or services. ======================================================================= Any questions about Bookham's E-Mail service should be directed to RemoveMEpostmasterEraseMEspam_OUTbookham.com. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email @spam@listservRemoveMEEraseMEmitvma.mit.edu with SET PICList DIGEST in the body