> While working on my next book, I've built a small general-purpose
> prototyping board. This PCB is also intended to be useful for those
Okay - I'm running a bit behind schedule, but not much; I'll be
ordering boards this week, just not Monday. An updated schematic and
component layout are posted at <http://www.larwe.com/zws/products/
polyceph/index.html> - this will be the permanent home for the
project. I think I've incorporated everything except the CPLD; no room
to fanout those I/Os on a 2-layer board [at least not with my mediocre
routing skills].
Reply by Jim Granville●April 19, 20072007-04-19
larwe wrote:
> On Apr 19, 4:48 am, Clifford Heath <n...@spam.please.net> wrote:
>>Nice idea, BTW. Would be nice with a CPLD as Jim suggested.
>
>
> All right, all right, what is with the CPLD? CPLD talk is not going to
> make it into my book, but just supposing I were to add it to this
> board, how would you want it wired? All the pins coming to headers, or
> half the I/Os going to a micro and the other half to a header?
OK, here is one suggestion:
Wire 4 CPLD pins to the uC(s), as SPI
SPI_DI
SPI_DO
SPI_SS
SPI_CK
and some of the others can go to pin headers,
- you can work out from their names, what they
are used for, and some header candidates :)
Pin Name Resource/Direction
43 on LCD_RWn Dge--
44 on LCD_RS Dge--
1 -- TDI INPUT
2 PT DB6 Dge--
3 PT DB5 Dge--
5 PT DB7 Dge--
6 PT DB4 Dge--
7 -- TMS INPUT
8 PT DB1 Dge--
10 PT DB3 Dge--
11 PT DB2 Dge--
12 PT DB0 Dge--
13 on LCD_E Tg-g-
14 -- SPI_DI INPUT
15 on SPI_DO C----
32 -- TDO C----
26 -- TCK INPUT
39 SPI_SS INPUT << Locked Pin
37 SPI_CK INPUT << Locked Pin
Spares could go to backlight, and buttons - depends on
board space really.
and the programming pin header - IDC10
IDC10 CPLD pin
--------+-----------------------
JTAG.1 S PIN26_C62_TCK_B
JTAG.2 S GND
JTAG.3 S PIN32_C73_TDO
JTAG.4 S VCCIO
JTAG.5 S PIN7_C15_TMS_B
JTAG.6 E PIN40_C90_GCLK2B
JTAG.7 E PIN39_C89_GCLRB
JTAG.8 E PIN37_C87_GCLK1B
JTAG.9 S PIN1_C4_TDI_B
JTAG.10 E GND_OR_VCCINT Jumper Selected. Allows JTAG unlock, Some
PCBs GND.10
Reply by larwe●April 19, 20072007-04-19
On Apr 19, 4:48 am, Clifford Heath <n...@spam.please.net> wrote:
> > - SD socket moved to overhang edge of board by ~80 mil in order to
> > protrude through edge of 1591ESBK box if desired.
>
> Is the back of this part of the board free, in case you want to
> mount the SD socket on the back, rotated 180 degrees, so the SD
> card doesn't overlap?
There are currently no footprints at all on the back of the board,
partly because for cost reasons I'm only putting silkscreen on the top
side. That's a pretty good idea, though.
> Nice idea, BTW. Would be nice with a CPLD as Jim suggested.
All right, all right, what is with the CPLD? CPLD talk is not going to
make it into my book, but just supposing I were to add it to this
board, how would you want it wired? All the pins coming to headers, or
half the I/Os going to a micro and the other half to a header?
Reply by Clifford Heath●April 19, 20072007-04-19
larwe wrote:
> - SD socket moved to overhang edge of board by ~80 mil in order to
> protrude through edge of 1591ESBK box if desired.
Is the back of this part of the board free, in case you want to
mount the SD socket on the back, rotated 180 degrees, so the SD
card doesn't overlap?
Nice idea, BTW. Would be nice with a CPLD as Jim suggested.
Reply by Jim Granville●April 17, 20072007-04-17
larwe wrote:
> On Apr 17, 6:17 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
>
>
>>.. Probably because the software goal arrives in the form of some arm
>>waving from marketing! :)
>
>
> :)
>
>
>>Since this is about hardware selection to match design goals, can you
>>add a CPLD footprint ?
>
>
> In an earlier incarnation I was going to use a high-end FPGA, but it's
> just too complex for my book. I'm already wondering how I'll get it
> finished in time and in roughly the page limit required.
Yes FPGAs are complex things to learn, and the tools are large, and
also a moving target.
CPLDs are simpler, and a good stepping stone; the tools are stable, and
relatively easy to learn and even easier to run.
We have them setup to launch from a text editor, and single key
compile/fit/simulate take 1-2 seconds. PGM is sub 10s.
-jg
Reply by larwe●April 17, 20072007-04-17
On Apr 17, 6:17 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> .. Probably because the software goal arrives in the form of some arm
> waving from marketing! :)
:)
> Since this is about hardware selection to match design goals, can you
> add a CPLD footprint ?
In an earlier incarnation I was going to use a high-end FPGA, but it's
just too complex for my book. I'm already wondering how I'll get it
finished in time and in roughly the page limit required.
Reply by Jim Granville●April 17, 20072007-04-17
larwe wrote:
>>Maybe this isn't going to fit within the context of your book, but I
>>have recently become aware of an open source Java Virtual Machine for
>
>
> No, it really doesn't. Though, it might make an interesting appendix.
> My next book is about dimensioning your hardware choice for a desired
> software goal, a task that most of the engineers I know don't do very
> scientifically.
.. Probably because the software goal arrives in the form of some arm
waving from marketing! :)
Another suggestion, if you have room....
Since this is about hardware selection to match design goals, can you
add a CPLD footprint ?
These are usefull for pushing the peripheral space, or just more IO,
or higher drive....
I'd suggest an ATF1502BE from Atmel. Digikey part, JTAG ISP,
TQFP44 package + IDC10 JTAG header cost. Tools are small [<10MB] and free.
-jg
Reply by larwe●April 17, 20072007-04-17
On Apr 17, 4:36 pm, Eric <englere_...@yahoo.com> wrote:
> > > It's a pet peeve of mine to have SD slots if there's no SD filesystem
>
> > I can feel utterly insulated against this peeve, since I have
>
> Wow, that's cool!
*preen* It's quite satisfying indeed to have such an effective
rebuttal to a complaint! :)
> I also like the C8051 devices from SiLabs that another poster has
> talked about. I don't use the 8051 much, but SiLabs has some
I haven't used them in years, honestly, but adding the footprint costs
very little in terms of board space, given that I've made the area
larger anyway to fit that jiffy box.
> Maybe this isn't going to fit within the context of your book, but I
> have recently become aware of an open source Java Virtual Machine for
No, it really doesn't. Though, it might make an interesting appendix.
My next book is about dimensioning your hardware choice for a desired
software goal, a task that most of the engineers I know don't do very
scientifically.
That is an interesting project, though - thanks for the link.
> I also have a gcc IDE for Freescale 16 bit processors, and I'm
Oh dear me no, I don't do those any more. My last tangle with Motorola
[not counting POWER architecture chips] was the 68000 in the Amiga :).
Reply by Eric●April 17, 20072007-04-17
On Apr 16, 10:24 pm, larwe <zwsdot...@gmail.com> wrote:
> > It's a pet peeve of mine to have SD slots if there's no SD filesystem
> > software. Of the hundreds of DEV boards that have a slot, only a
> > couple have open software to utilize the slot. I'm not sure if the AVR
> > world has this kind of open software?
>
> I can feel utterly insulated against this peeve, since I have
> published a public domain FAT12/16/32 filesystem and have tested it on
> AVR and MSP430, among other platforms ;)
> <http://www.zws.com/products/dosfs/index.html>
Wow, that's cool!
I also like the C8051 devices from SiLabs that another poster has
talked about. I don't use the 8051 much, but SiLabs has some
compelling parts in that space. Their royalty-free USB and Ethernet
stacks are extremely good. SiLabs is also one of the best companies
when it comes to analog integration on their chips. They can do better
A/D than most others.
Maybe this isn't going to fit within the context of your book, but I
have recently become aware of an open source Java Virtual Machine for
Atmel AVRs. This is written in C (using gcc), and should be portable
to other processors also. The main requirement when porting it is to
provide native methods specific to the target device to provide
support for on-chip peripherals. The goal of this effort is
standardization at the software level to allow people to program all
kinds of devices in Java. Later, other source languages will target
the same virtual machine. Here's a link:
http://www.EricEngler.com/NanoVM.aspx
I also have a gcc IDE for Freescale 16 bit processors, and I'm
considering how best to move that effort forward. I'll likely port it
to .NET using my Pluto code base, where it will run on both linux and
Windows, and I'll integrate Java support also.
http://www.EricEngler.com/EmbeddedGNU.aspxhttp://www.EricEngler.com/Pluto.aspx
By the way, I'm not advocating that you put a Freescale 16 bit
processor on your board because they no longer market this family to
the general purpose sector, even though it still has some compelling
features. Freescale now considers this to be an automotive family
almost exclusively.
Eric
Reply by linnix●April 17, 20072007-04-17
On Apr 17, 8:46 am, larwe <zwsdot...@gmail.com> wrote:
> On Apr 17, 11:36 am, linnix <m...@linnix.info-for.us> wrote:
>
> > I suggest AT90USB1287 compatible. Only 7 pins needed for USB.
>
> Okay, but I don't use that part, and both that part and the 64K
> version are hard to get.
We can provide you with the chip for $10 each and your board for $2
each. We can also pre-mount the chip for you. I am heading to the
factory in a few weeks anyway.