Searching \ for '[EE] Microchip/ZeroG ZG2100M -- detailed datasheet' 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/memory.htm?key=data
Search entire site for: 'Microchip/ZeroG ZG2100M -- detailed datasheet'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Microchip/ZeroG ZG2100M -- detailed datasheet'
2010\04\22@202320 by Philip Pemberton

face
flavicon
face
Hi guys,
The thread on wireless modules has piqued my curiosity... and I'm
tempted to nip down to Farnell and buy a couple of ZeroG ZG2100M modules
to muck about with. Thing is, the datasheet (go to
http://uk.farnell.com/ then search for ZG2100M) is a 30-page
"connecting-it-up HOWTO" with no information on the hardware registers
or anything that could be remotely considered "programming information."

Ordinarily I'd just use the Microchip libraries, but I'm not fond of the
licensing scheme (I don't want anything in my codebase that is tagged
"for XYZMCUManufacturer's products only", especially when it's code
that's cross-platform portable). That and based on my experiences with
the MCHP USB stack, I'd sooner juggle flaming torches in the middle of
the Buncefield Oil Refinery than use their code.

Has anyone managed to get hold of a more detailed datasheet or some
sample code without the "for use on Microchip MCUs only" licence rider?
A quick Google search suggests there was (once upon a time) STM32 and
Freescale driver code kicking about, but zerogwireless.com has been
zapped, and said code is nowhere to be found :(

Thanks,
--
Phil.
spam_OUTpiclistTakeThisOuTspamphilpem.me.uk
http://www.philpem.me.uk/

2010\04\22@210731 by Peter Loron

flavicon
face
On Apr 22, 2010, at 5:23 PM, Philip Pemberton wrote:

{Quote hidden}

Phil, I don't have anything other than the aforementioned datasheet, but if you do manage to lay your hands on something, please let the list know as I'm sure I'm not the only one who would be interested in that data.

Thanks.

-Pete

2010\04\23@075945 by Olin Lathrop

face picon face
Philip Pemberton wrote:
> That and based on my
> experiences with the MCHP USB stack, I'd sooner juggle flaming
> torches in the middle of the Buncefield Oil Refinery than use their
> code.

I know what you mean.  I had a bad experience with the Microchip network
stack.  I took a snapshot of their code, which was AN833 if I remember
right, some years ago.  That was the latest at the time.  At first things
worked fine.  I got PING reply up and running quickly, and a basic TCP test
also seemed to work.  Then I implemented my application for real and lots of
little issues with their stack started cropping up.  Eventually I ended up
going over just about every line of code from the TCP module on down to the
ENC28J60 driver.  What a pile of crap!  It was very poorly written, and
poorly documented.  I think I found and fixed half a dozen bugs myself, and
the product sortof worked well enough for the purpose.

I think there were two basic problems with that network stack.  First,
although it claimed to be designed for multiple TCP connections, proper
concurrency wasn't designed all the way thru.  There were very onerous
restrictions placed on the application as a result.  Second, they were
reluctant to require or specify a multi-tasking system, so the stack really
didn't fit well with a application layer that did.  I think it would have
worked OK if the app was a single web server, but my app included a web
server and a additional TCP server and client.  It just couldn't handle 3
TCP streams.

I'll spare you some stuff in the middle, but last summer I got to where I
just couldn't fix this mess anymore and bumped up against hard architectural
limits that pretty much guaranteed lockup on certain events outside the
control of this embedded system.  So I wrote my own network stack for a PIC
18 driving a ENC28J60 external MAC/PHY.  We ran this thru all kinds of
turture tests and it just kept ticking.  This meant having both the TCP
server and client regularly tranferring data, while hitting the web page,
while hitting it with a PING flood.  The PING flood definitely increased
response time, but it didn't go down, and the response recovered when the
PING flood stopped.  These toruture tests were run for days at a time on
multiple units without a single one wedging, rebooting, or anything else
that could be considered a failure.  Just for comparison, we ran the same
test on the previous firmware that was based on the Microchip stack.  The
average up time was 350mS.  Yes, about one third of a second.

Recently I made up a networking testbed board that has a 18F67J60 (this PIC
contains a 10Mbit/sec ethernet MAC/PHY) on it with a hardwired ethernet
connection, and also a ZeroG module.  I'm adding the packet layer to drive
the internal ethernet module now, and then it's on to the ZeroG module after
that.  I'm not sure how exactly the code will be released and who will
maintain responsibility for it.  Let me get it written first.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2010\04\23@082624 by Olin Lathrop

face picon face
Peter Loron wrote:
> Phil, I don't have anything other than the aforementioned datasheet,
> but if you do manage to lay your hands on something, please let the
> list know as I'm sure I'm not the only one who would be interested in
> that data.

Microchip has not publicly released the detailed specs for the ZeroG
modules.  They may in the future.  In the mean time as I understand it, this
data has been released to a single individual outside Microchip, and this is
being used as a test of the process and of the data itself.  I expect in the
long run this data will be available, like it is for all their other
products.  However, the WiFi chip community is very very tight with such
things, and my guess is there is a little culture shock between ZeroG and
Microchip.  Now that Microchip owns ZeroG, I expect things to loosen up, but
they need to feel comfortable with this one step at a time.  Apparently they
also need to get the documentation verified and into publicly releasable
form.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2010\04\25@131040 by Vitaliy

face
flavicon
face
Philip Pemberton wrote:
> Has anyone managed to get hold of a more detailed datasheet or some
> sample code without the "for use on Microchip MCUs only" licence rider?
> A quick Google search suggests there was (once upon a time) STM32 and
> Freescale driver code kicking about, but zerogwireless.com has been
> zapped, and said code is nowhere to be found :(

Philip, can you not connect directly to the UART pins, and just pretend it's
not there? If it works anything like the Roving Networks device, you should
be able to.

http://ww1.microchip.com/downloads/en/DeviceDoc/70624A.pdf

"ZG2100M/ZG2101M incorporates Transmitted Data pin (UART0_TX) and Received
Data pin (UART0_RX) for serial testing purposes. These pins can be connected
to commercially available RS-232 line drivers/ receivers with appropriate
external level shifters. The ZG2100 serial interface is fully tested at
115200 bits/seconds baud rate with RS232/UART interface applications. "

Vitaliy

2010\04\25@172342 by Josh Koffman

face picon face
On Fri, Apr 23, 2010 at 7:59 AM, Olin Lathrop <olin_piclistspamKILLspamembedinc.com> wrote:
> I know what you mean.  I had a bad experience with the Microchip network
> stack.  I took a snapshot of their code, which was AN833 if I remember
> right, some years ago.  That was the latest at the time.  At first things
> worked fine.  I got PING reply up and running quickly, and a basic TCP test
> also seemed to work.  Then I implemented my application for real and lots of
> little issues with their stack started cropping up.  Eventually I ended up
> going over just about every line of code from the TCP module on down to the
> ENC28J60 driver.  What a pile of crap!  It was very poorly written, and
> poorly documented.  I think I found and fixed half a dozen bugs myself, and
> the product sortof worked well enough for the purpose.

I've got a couple of ideas that I'd like to play with in the Ethernet
world. At the moment I can't really program in C, so that's one item
before the Ethernet item on my list. I currently only use assembly.

Nothing is too complex, it's basically that I want to make a small
device that has a few switches, LEDs, etc. PoE would be a cool future
addition, but that'd be in the future. I too was looking at the
18F67J60. I like that it's self contained and if I'm careful I can
make a pretty small device. I also like that I could end up with a
wireless version by changing a few things and adding a ZeroG module. I
am pretty sure I don't have the ability to write my own TCP/IP stack.
I was looking at the Microchip stack since it's fairly available and
easily configured for the 18F67J60. Is there something else that's
better?

> Recently I made up a networking testbed board that has a 18F67J60 (this PIC
> contains a 10Mbit/sec ethernet MAC/PHY) on it with a hardwired ethernet
> connection, and also a ZeroG module.  I'm adding the packet layer to drive
> the internal ethernet module now, and then it's on to the ZeroG module after
> that.  I'm not sure how exactly the code will be released and who will
> maintain responsibility for it.  Let me get it written first.

Well I'm interested if you're going to release it (either free or as
some sort of inexpensive licence). Is it written in C or assembly? I'd
want to start with the wired module first as I don't want to run into
wireless problems while debugging my application.

Please keep us posted!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2010\04\25@190047 by Matt Pobursky

flavicon
face
On Fri, 23 Apr 2010 01:23:14 +0100, Philip Pemberton wrote:
{Quote hidden}

I designed these modules into a product about a year ago. Our system uses a
Samsung S3C2443 ARM920T CPU and we're running a commercial OS (smx).

At the time, ZeroG was able to provide us with Microchip specific drivers
(which we didn't use) and a generic driver development package. They also
had a driver package for Linux which they used to benchmark the modules
under Linux with an ARM9 CPU (much like our system). We ultimately ported
the generic drivers to the smx OS. They told us the Linux drivers had some
rough edges and weren't production ready but they sent them to us anyway.
My software engineer had a small linux system up and running on our
hardware in a few days for our own benchmarking so I know they couldn't
have been too bad.

We have much more detailed data than is publicly available but we had to
sign an NDA to get them.

I'm not sure what the situation is now that Microchip owns them but I think
the information and drivers you want probably still exists.

I would get in touch with the product manager at Microchip for the ZeroG
modules. They should be able to tell you for sure.

Matt Pobursky
Maximum Performance Systems

2010\04\25@190920 by Matt Pobursky

flavicon
face
Vitaly,

I'm not sure they work that way but it may be possible. I don't recall if
there is a way to use the UART interface as working module I/O port, but I
wasn't looking for it in the documentation either.

All the drivers I've seen (Microchip specific, generic and Linux) used the
SPI interface. We use the SPI interface on our design and with DMA we get
very good performance -- about 1.5 Mbps sustained throughput with the
generic or Linux drivers. The application engineers at ZeroG told me they
were getting about 1.8 Mbps with their ARM920/Linux test board.

Matt Pobursky
Maximum Performance Systems


On Sun, 25 Apr 2010 10:10:21 -0700, Vitaliy wrote:
{Quote hidden}

2010\04\25@194544 by Olin Lathrop

face picon face
Josh Koffman wrote:
>> Recently I made up a networking testbed board that has a 18F67J60
>> (this PIC contains a 10Mbit/sec ethernet MAC/PHY) on it with a
>> hardwired ethernet connection, and also a ZeroG module. I'm adding the
>> packet layer to drive the internal ethernet module now, and then it's
>> on to the ZeroG module after that. I'm not sure how exactly the code
>> will be released and who will maintain responsibility for it. Let me
>> get it written first.

As a followup, I've meanwhile gotten the packet layer for the internal
ethernet module working.  It was easier than I expected.  Once I fixed two
MOVFF I accidentally typed as MOVF, everything worked.  So far I have only
tested it by PINGing the board from my PC.  That tests the packet layer, ARP
replies, and ICMP PING replies.  I didn't change anything in the upper
levels, so I assume the ARP cache, IP, and TCP are working too.  I'll
eventually test it more thouroghly, but for now I'm on to the ZeroG module.

> Well I'm interested if you're going to release it (either free or as
> some sort of inexpensive licence).

I haven't decided how the code will be released, if at all.  If you want it
just for personal use you can have it now.  I have three boards and have so
far populated just the one I'm working with.  You can have one of the bare
boards if you're serious about using it.  You'll have to acquire the parts
and build it up yourself.

> Is it written in C or assembly?

This is all in MPASM with my development environment.  I expect to use this
as a low level capability for future projects not yet dreamed up, so I want
this code to be as light weight and low footprint as possible.  However, it
is possible to call this stuff from C18.  I've done that with a customer
project using Microchip's HTTP server, which is in C18.  I had to create a
few glue routines, but it was pretty simple.

> I'd
> want to start with the wired module first as I don't want to run into
> wireless problems while debugging my application.

That's why I started with the wired ethernet module too.  I wanted to make
sure everything was OK above the packet layer before creating the ZeroG
packet layer.

2010\04\25@195709 by Philip Pemberton

face
flavicon
face
Matt Pobursky wrote:
> I would get in touch with the product manager at Microchip for the ZeroG
> modules. They should be able to tell you for sure.

I opened a support ticket on Friday -- with a bit of luck (ha!) I should
hopefully be hearing from MCHP fairly soon.

It is, however, nice to know that the information I want exists :)

--
Phil.
.....piclistKILLspamspam.....philpem.me.uk
http://www.philpem.me.uk/


'[EE] Microchip/ZeroG ZG2100M -- detailed datasheet'
2010\05\02@190826 by Josh Koffman
face picon face
On Sun, Apr 25, 2010 at 7:45 PM, Olin Lathrop <EraseMEolin_piclistspam_OUTspamTakeThisOuTembedinc.com> wrote:
> As a followup, I've meanwhile gotten the packet layer for the internal
> ethernet module working.  It was easier than I expected.  Once I fixed two
> MOVFF I accidentally typed as MOVF, everything worked.  So far I have only
> tested it by PINGing the board from my PC.  That tests the packet layer, ARP
> replies, and ICMP PING replies.  I didn't change anything in the upper
> levels, so I assume the ARP cache, IP, and TCP are working too.  I'll
> eventually test it more thouroghly, but for now I'm on to the ZeroG module.

Just out of curiosity, what's your ultimate goal? I mean how do you
want to use the board (web server, etc). I'm hoping to stay away from
generic webserver, though I guess it might be useful for
configuration.

Hardware wise I'd like to have the switches and indicators I mentioned
before. It will likely be a PC controlling the units, so I can use
whatever signaling method I want. It's all pretty up in the air right
now as I'm not sure I can do the programming work.

> I haven't decided how the code will be released, if at all.  If you want it
> just for personal use you can have it now.  I have three boards and have so
> far populated just the one I'm working with.  You can have one of the bare
> boards if you're serious about using it.  You'll have to acquire the parts
> and build it up yourself.

I'm sorry it's taken a few days to reply, things have exploded a bit
here. I am interested in looking at how you've laid it out, but I
don't think I'm going to be able to use it immediately (I have a
couple of other things I need to finish up first). I like that you're
working in MPASM as I feel that it's more likely I'll be able to grasp
it quicker.

Thank you for the offer of the board. If you're offering it so that
you can have feedback on it in a reasonable amount of time, you might
be better served with someone who could do it quicker. I just want to
give you fair warning. What do you think?

> This is all in MPASM with my development environment.  I expect to use this
> as a low level capability for future projects not yet dreamed up, so I want
> this code to be as light weight and low footprint as possible.  However, it
> is possible to call this stuff from C18.  I've done that with a customer
> project using Microchip's HTTP server, which is in C18.  I had to create a
> few glue routines, but it was pretty simple.

If it's written in MPASM, I'm happy to keep it there. I feel much more
comfortable there vs in C18.

> That's why I started with the wired ethernet module too.  I wanted to make
> sure everything was OK above the packet layer before creating the ZeroG
> packet layer.

Nice to know I'm not totally out to lunch!

Thanks,

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2010\05\03@091749 by Olin Lathrop

face picon face
Josh Koffman wrote:
> Just out of curiosity, what's your ultimate goal? I mean how do you
> want to use the board (web server, etc). I'm hoping to stay away from
> generic webserver, though I guess it might be useful for
> configuration.

I want a solid generic network stack that I can easily include in future
projects yet unknown.  I had some bad experiences with the Microchip stack,
so I was forced to write my own.  The protocols supported by the stack so
far are:

Network packet layer.  Can handle one receive packet and multiple transmit
packets open concurrently (try that with the Microchip stack some time).
The amount of memory used in the MAC/PHY for transmit packets is
configurable, and so is the maximum number of simultaneous transmit packets.
Does dynamic memory allocation on the transmit memory.

ARP.  Replies to ARP requests and keeps a cache for resolving IP addresses
to MAC addresses for local applications.  Cache entries time out and
automatically try to refresh.  The number of cache entries is configurable.
Applications can also resolve the source address of the currently open IP
packet, if any, without using up a ARP cache entry.

IP.  Handles the base mechanics for IP packets and provides resources unique
to IP to higher level protocols, like ICMP and TCP.

ICMP.  This is implemented only far enough to reply to PING requests over
the network.  It does not currently support outgoing PING requests or any
other ICMP functions.

TCP.  Configurable to a maximum number of concurrent TCP streams.  The app
sees a bi-directional stream of bytes without needing to worry about packet
boundaries.  The restrictions pushed onto the app are much less onerous than
with the Microchip stack.  For example, there is no rule about a app having
to consume the entire received packet in one "time slice".  The app also
need not get envolved with low level details like ARP resolution and
allocating/deallocating transmit buffers.

This code all relies on my cooperative multi-tasking system, which apps have
to use and be aware of too.

> I'm sorry it's taken a few days to reply, things have exploded a bit
> here. I am interested in looking at how you've laid it out,

OK, I put a board drawing at http://www.embedinc.com/temp/net1.gif and the
schematic at http://www.embedinc.com/temp/net1.pdf.

> Thank you for the offer of the board. If you're offering it so that
> you can have feedback on it in a reasonable amount of time, you might
> be better served with someone who could do it quicker. I just want to
> give you fair warning. What do you think?

I don't care about feedback.  This just a testbed, not a product, so I can
tell for myself whether it works.  I might spin off a ReadyBoard from this,
but that would have quite different layout and wouldn't be both ethernet and
WiFi on the same board.  I ended up with 3 of these boards because I had to
buy 75 square inches minimum.  I have already promised one to someone else,
but there is still one I could let you have if you're serious about using
it.

Again, this is a bare board.  You'd have to acquire the parts and populate
it yourself.

Update:  I had a bunch of real work to do last week, so the ZeroG support is
progressing slower than I had hoped.  However, I have register access and
send/receive of management messages working.  The firmware just makes all
that accessible to the host over the serial port so that I can experiment
there.  So far things largely work as the documentation says it should.  I
can have it enumerate access points, join one, and authenticate.  Next I've
got to write the code to pass it the security information and have it
associate to the network, then it will be off to transfer data packets.  I
just got another thing plunked on me Friday, and possibly another one today,
so it may take a while for the next bit of progress.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2010\05\03@194056 by Xiaofan Chen

face picon face
On Fri, Apr 23, 2010 at 8:23 AM, Philip Pemberton <piclistspamspam_OUTphilpem.me.uk> wrote:

> Has anyone managed to get hold of a more detailed datasheet or some
> sample code without the "for use on Microchip MCUs only" licence rider?
> A quick Google search suggests there was (once upon a time) STM32 and
> Freescale driver code kicking about, but zerogwireless.com has been
> zapped, and said code is nowhere to be found :(

I just came across this.
www.microchip.com/forums/tm.aspx?m=497721
www.seeedstudio.com/depot/blackwidow-10-p-613.html
http://asynclabs.com/wiki/index.php?title=AsyncLabsWiki


--
Xiaofan http://mcuee.blogspot.com

2010\05\04@144859 by Vitaliy

face
flavicon
face
Xiaofan Chen wrote:
> www.microchip.com/forums/tm.aspx?m=497721
> www.seeedstudio.com/depot/blackwidow-10-p-613.html
> http://asynclabs.com/wiki/index.php?title=AsyncLabsWiki

I sent the BlackWidow schematic to our engineers. It looks like the authors
intended it as a teaching aid for the self-paced tutorial "How to Design the
Most Terrible Schematic in the World".

http://asynclabs.com/hardware/blackwidow1.0/asynclabs_blackwidow_v1.sch

The aesthetic pleasure one gets from beholding this work of art, is akin to
surveying the aftermath of a car wreck. There is twisted metal and broken
glass everywhere.

The designers had difficulty mastering the Copy command, and made the
ill-fated decision to make their own symbols. It looks like they didn't
understand the purpose of supply pins, different layers, or the
old-fashioned notion that you want to avoid plopping the name & value
strings on top of the symbol (who reads those things, anyway).

I'm sure the viewers will find the 30 degree VIN net and the zig-zag
connection on C9 unforgettable.

Vitaliy

2010\05\04@151423 by Olin Lathrop

face picon face
Vitaliy wrote:
> http://asynclabs.com/hardware/blackwidow1.0/asynclabs_blackwidow_v1.sch
>
> The aesthetic pleasure one gets from beholding this work of art, is
> akin to surveying the aftermath of a car wreck. There is twisted
> metal and broken glass everywhere.

I see what you mean.  Yucc, what a mess!

> I'm sure the viewers will find the 30 degree VIN net and the zig-zag
> connection on C9 unforgettable.

Good one.  Given the obvious lack of care and disregard for details these
people have, I would stay far away from anything else they do.  In my
experience, sloppiness in one area is a strong warning of sloppiness in
other areas.

If you want to see a real schematic incorporating a ZeroG module, take at
look at http://www.embedinc.com/temp/net1.pdf.  That's the board I made just
for internal development using the 18F built in etherent module and the
ZeroG WiFi module.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2010\05\04@155246 by Vitaliy

face
flavicon
face
Olin Lathrop wrote:
> Good one.  Given the obvious lack of care and disregard for details these
> people have, I would stay far away from anything else they do.  In my
> experience, sloppiness in one area is a strong warning of sloppiness in
> other areas.

Their PCB looks reasonably well done, but of course I agree. We spend
considerable time polishing our schematics.


> If you want to see a real schematic incorporating a ZeroG module, take at
> look at http://www.embedinc.com/temp/net1.pdf.  That's the board I made
> just
> for internal development using the 18F built in etherent module and the
> ZeroG WiFi module.

Looks cool. We use the "flat" grounds, symbols for supplies. I think your
style more closely resembles Microchip's.

How do you put the little direction indicators on the pins? Are they symbols
that you put on top of the nets?

Vitaliy


2010\05\04@163439 by Olin Lathrop

face picon face
Vitaliy wrote:
> How do you put the little direction indicators on the pins? Are they
> symbols that you put on top of the nets?

Yes.  They are special symbols for that purpose in the SYMBOLS library.  The
SYMBOLS library is included in the Eagle Tools release at
http://www.embedinc.com/pic/dload.htm.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2010\05\04@172359 by Michael Watterson

face picon face
Vitaliy wrote:
> Olin Lathrop wrote:
>  
>> Good one.  Given the obvious lack of care and disregard for details these
>> people have, I would stay far away from anything else they do.  In my
>> experience, sloppiness in one area is a strong warning of sloppiness in
>> other areas.
>>    
>
> Their PCB looks reasonably well done, but of course I agree. We spend
> considerable time polishing our schematics.
>  
I find doing that helps think about design and review it. Sometimes I'll
redo a schematic just to think about it.
Cheaper than making scrap boards and wondering why they are scrap.

2010\05\04@172916 by Herbert Graf

picon face
On Tue, 2010-05-04 at 11:48 -0700, Vitaliy wrote:
> Xiaofan Chen wrote:
> > www.microchip.com/forums/tm.aspx?m=497721
> > www.seeedstudio.com/depot/blackwidow-10-p-613.html
> > asynclabs.com/wiki/index.php?title=AsyncLabsWiki
>
> I sent the BlackWidow schematic to our engineers. It looks like the authors
> intended it as a teaching aid for the self-paced tutorial "How to Design the
> Most Terrible Schematic in the World".
>
> asynclabs.com/hardware/blackwidow1.0/asynclabs_blackwidow_v1.sch
>
> The aesthetic pleasure one gets from beholding this work of art, is akin to
> surveying the aftermath of a car wreck. There is twisted metal and broken
> glass everywhere.

Any chance you could convert it to gif or other portable format?

Thanks, TTYL

2010\05\04@220212 by Xiaofan Chen

face picon face
On Wed, May 5, 2010 at 5:29 AM, Herbert Graf <@spam@hkgrafKILLspamspamgmail.com> wrote:

>> I sent the BlackWidow schematic to our engineers. It looks like the authors
>> intended it as a teaching aid for the self-paced tutorial "How to Design the
>> Most Terrible Schematic in the World".
>>
>> asynclabs.com/hardware/blackwidow1.0/asynclabs_blackwidow_v1.sch
>>
>> The aesthetic pleasure one gets from beholding this work of art, is akin to
>> surveying the aftermath of a car wreck. There is twisted metal and broken
>> glass everywhere.
>
> Any chance you could convert it to gif or other portable format?
>

I opened it with the free version of Eagle (5.9.0 Light) and export
the schematics. It is not good indeed. Maybe the guy is a firmware
engineer who is trying to draw schematics. ;-)
http://picusb.googlecode.com/files/blackwidow.png


--
Xiaofan http://mcuee.blogspot.com

2010\05\04@220624 by Xiaofan Chen

face picon face
On Wed, May 5, 2010 at 10:02 AM, Xiaofan Chen <KILLspamxiaofancKILLspamspamgmail.com> wrote:

> I opened it with the free version of Eagle (5.9.0 Light) and export
> the schematics. It is not good indeed. Maybe the guy is a firmware
> engineer who is trying to draw schematics. ;-)
> http://picusb.googlecode.com/files/blackwidow.png
>

And if you download some of my codes, you may well laugh
at my codes as well -- a hardware engineer trying to write
software by copy/paste/modify. ;-)


--
Xiaofan http://mcuee.blogspot.com

2010\05\05@111713 by M.L.

flavicon
face
On Tue, May 4, 2010 at 10:06 PM, Xiaofan Chen <RemoveMExiaofancTakeThisOuTspamgmail.com> wrote:

> On Wed, May 5, 2010 at 10:02 AM, Xiaofan Chen <spamBeGonexiaofancspamBeGonespamgmail.com> wrote:
>
> > I opened it with the free version of Eagle (5.9.0 Light) and export
> > the schematics. It is not good indeed. Maybe the guy is a firmware
> > engineer who is trying to draw schematics. ;-)
> > picusb.googlecode.com/files/blackwidow.png
> >
>


I think this wins the prize for the obfuscated schematic contest:
http://wacco.mveas.com/img/schema1d.png


--
Martin K.

2010\05\05@163102 by Vitaliy

face
flavicon
face
M.L. wrote:
> I think this wins the prize for the obfuscated schematic contest:
> http://wacco.mveas.com/img/schema1d.png

Mr. Meeuwisse doesn't know how to use buses, but I think the schematic was
still done with more care (parts/nets are aligned, diodes don't look like
they're going to beat up/stab the tiny resistors, etc).

Plus, it says "v1.0 UNFINISHED"

:)

2010\05\05@174456 by Josh Koffman

face picon face
On Mon, May 3, 2010 at 9:17 AM, Olin Lathrop <TakeThisOuTolin_piclistEraseMEspamspam_OUTembedinc.com> wrote:
> I don't care about feedback.  This just a testbed, not a product, so I can
> tell for myself whether it works.  I might spin off a ReadyBoard from this,
> but that would have quite different layout and wouldn't be both ethernet and
> WiFi on the same board.  I ended up with 3 of these boards because I had to
> buy 75 square inches minimum.  I have already promised one to someone else,
> but there is still one I could let you have if you're serious about using
> it.

I'm serious about using it, the only issue is that I'm not sure when
that will be. I want to be open about that.

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2010\05\05@175636 by Olin Lathrop

face picon face
Josh Koffman wrote:
>> I don't care about feedback. This just a testbed, not a product, so
>> I can tell for myself whether it works. I might spin off a
>> ReadyBoard from this, but that would have quite different layout and
>> wouldn't be both ethernet and WiFi on the same board. I ended up
>> with 3 of these boards because I had to buy 75 square inches
>> minimum. I have already promised one to someone else, but there is
>> still one I could let you have if you're serious about using it.
>
> I'm serious about using it, the only issue is that I'm not sure when
> that will be. I want to be open about that.

Too late now.  I've already sent the last available board to someone else
who said here they were serious about using it a few days ago.  He should
have it by now.  Sorry, but he was the first to speak up clearly that he
wanted it and would use it.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2010\05\05@230950 by William \Chops\ Westfield

face picon face

On May 4, 2010, at 11:48 AM, Vitaliy wrote:

> "How to Design the Most Terrible Schematic in the World".

I didn't think it was that bad.  It's too simple to be that bad.
For better or worse, this "style" of schematic, with essentially  
labels instead of actually interconnects, seems to be pretty popular,  
especially as the pin count per chip gets larger.  For example this  
Freescale schematic: cache.freescale.com/files/microcontrollers/hardware_tools/schematics/TWR-MCF51CN-SCH.pdf
You can look at Martin's example:

> I think this wins the prize for the obfuscated schematic contest:
> http://wacco.mveas.com/img/schema1d.png

and understand why.  I guess.  Something in between is best (Olin's  
schematic is pretty nice.)

BillW

2010\05\06@104614 by M.L.

flavicon
face
On Wed, May 5, 2010 at 4:29 PM, Vitaliy <RemoveMEpiclistspamTakeThisOuTmaksimov.org> wrote:

> M.L. wrote:
> > I think this wins the prize for the obfuscated schematic contest:
> > http://wacco.mveas.com/img/schema1d.png
>
> Mr. Meeuwisse doesn't know how to use buses, but I think the schematic was
> still done with more care (parts/nets are aligned, diodes don't look like
> they're going to beat up/stab the tiny resistors, etc).
>
> Plus, it says "v1.0 UNFINISHED"
>
> :)
>
>

If that's how he starts schematics then I hope he isn't looking for a job in
electronics!

--
Martin K.

2010\05\06@110940 by Herbert Graf

picon face
On Wed, 2010-05-05 at 20:09 -0700, William "Chops" Westfield wrote:
> On May 4, 2010, at 11:48 AM, Vitaliy wrote:
>
> > "How to Design the Most Terrible Schematic in the World".
>
> I didn't think it was that bad.  It's too simple to be that bad.
> For better or worse, this "style" of schematic, with essentially  
> labels instead of actually interconnects, seems to be pretty popular,  
> especially as the pin count per chip gets larger.  For example this  
> Freescale schematic: http://cache.freescale.com/files/microcontrollers/hardware_tools/schematics/TWR-MCF51CN-SCH.pdf

Very true. While for smaller simpler circuits it can be a little
"worse", the fact that it's scalable makes it win out for most of us.

There's simply no way to do an 40 page schematic without that style of
interconnect.

The way I always do things is any connections on the same page are done
with wires (unless it's REALLY unwieldy) while off pages use a specific
symbol.

The most important thing to keep in mind with this style schematic is to
label your nets intelligently, i.e. net34 is useless, fpga_pic_2 is VERY
useful.

TTYL

2010\05\06@123203 by Vitaliy

face
flavicon
face
M.L. wrote:
>> > I think this wins the prize for the obfuscated schematic contest:
>> > http://wacco.mveas.com/img/schema1d.png
>>
>> Mr. Meeuwisse doesn't know how to use buses, but I think the schematic
>> was
>> still done with more care (parts/nets are aligned, diodes don't look like
>> they're going to beat up/stab the tiny resistors, etc).
>>
>> Plus, it says "v1.0 UNFINISHED"
>>
>> :)
>>
>>
>
> If that's how he starts schematics then I hope he isn't looking for a job
> in
> electronics!

Don't be so harsh, Martin. We all had to start at one point or another, and
we were proud of what we've acoomplished -- even though we laugh at our own
work now. He just needs to learn how to use buses, that's all.

Vitaliy

2010\05\06@124407 by Vitaliy

face
flavicon
face
Herbert Graf wrote:
>> > "How to Design the Most Terrible Schematic in the World".
>>
>> I didn't think it was that bad.  It's too simple to be that bad.
>> For better or worse, this "style" of schematic, with essentially
>> labels instead of actually interconnects, seems to be pretty popular,
>> especially as the pin count per chip gets larger.  For example this
>> Freescale schematic:
>> http://cache.freescale.com/files/microcontrollers/hardware_tools/schematics/TWR-MCF51CN-SCH.pdf
>
> Very true. While for smaller simpler circuits it can be a little
> "worse", the fact that it's scalable makes it win out for most of us.
>
> There's simply no way to do an 40 page schematic without that style of
> interconnect.

Herbert, Bill: I think you both misunderstood what I said. I'm not at all
against "labels instead of interconnects" (which we call "ports"), in fact
we use them all the time.


> The way I always do things is any connections on the same page are done
> with wires (unless it's REALLY unwieldy) while off pages use a specific
> symbol.

We use what makes sense. Sometimes having ports on the same page make sense,
because instead of following 20 wires you can just cross-check the names.


> The most important thing to keep in mind with this style schematic is to
> label your nets intelligently, i.e. net34 is useless, fpga_pic_2 is VERY
> useful.

Most of ours are named after pin names: UART_RX, AN1, etc.

Vitaliy

2010\05\06@134529 by M.L.

flavicon
face
On Thu, May 6, 2010 at 12:31 PM, Vitaliy <piclistEraseMEspam.....maksimov.org> wrote:

{Quote hidden}

I wouldn't be very proud to show that to someone. He was either hasty or
honestly couldn't figure out how to make the schematic legible. Neither is a
very good excuse. The first schematics I did in college may not have been
very pretty (or had 100+ pin devices) but I knew if it was unreadable and I
knew there were ways of improving it.

--
Martin K.

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