Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #13136 > unrolled thread
| Started by | Joerg <invalid@invalid.invalid> |
|---|---|
| First post | 2013-08-19 13:14 -0700 |
| Last post | 2013-09-02 22:27 +0200 |
| Articles | 20 on this page of 146 — 17 participants |
Back to article view | Back to comp.arch.embedded
AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-08-19 13:14 -0700
Re: AREF bypass capacitance on ATMega2560? John Devereux <john@devereux.me.uk> - 2013-08-20 20:16 +0100
Re: AREF bypass capacitance on ATMega2560? Vladimir Vassilevsky <nospam@nowhere.com> - 2013-08-21 14:47 -0500
Re: AREF bypass capacitance on ATMega2560? Jim Stewart <jstewart@jkmicro.com> - 2013-08-21 13:18 -0700
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-08-21 16:38 -0700
Re: AREF bypass capacitance on ATMega2560? "Tim Williams" <tmoranwms@charter.net> - 2013-08-21 21:30 -0500
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-08-22 10:51 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-06 16:26 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-06 13:33 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-06 17:12 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-06 16:10 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-06 23:59 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 08:10 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 13:03 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 10:59 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 14:54 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 12:39 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 16:44 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 14:48 -0700
Re: AREF bypass capacitance on ATMega2560? "Tim Williams" <tmoranwms@charter.net> - 2013-09-07 17:10 -0500
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 15:34 -0700
Re: AREF bypass capacitance on ATMega2560? Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2013-09-08 00:57 +0200
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 16:56 -0700
Re: AREF bypass capacitance on ATMega2560? Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2013-09-09 17:07 +0200
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-09 10:19 -0700
Re: AREF bypass capacitance on ATMega2560? Paul <paul@pcserviceselectronics.co.uk> - 2013-09-09 20:27 +0100
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-09 12:55 -0700
Re: AREF bypass capacitance on ATMega2560? Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2013-09-11 09:44 +0200
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-11 07:27 -0700
Re: AREF bypass capacitance on ATMega2560? Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2013-09-13 12:42 +0200
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-14 11:56 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 19:38 -0400
Re: AREF bypass capacitance on ATMega2560? Paul Rubin <no.email@nospam.invalid> - 2013-09-07 17:39 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 23:20 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-08 07:41 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-07 11:17 -0400
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 13:23 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 11:19 -0400
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-08 14:03 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 19:42 -0400
Re: AREF bypass capacitance on ATMega2560? Paul Rubin <no.email@nospam.invalid> - 2013-09-08 17:18 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-09 13:13 -0400
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-10 20:21 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-10 23:42 -0400
Re: AREF bypass capacitance on ATMega2560? John Devereux <john@devereux.me.uk> - 2013-09-07 09:24 +0100
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 10:00 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-07 11:32 -0400
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 13:35 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 11:30 -0400
Re: AREF bypass capacitance on ATMega2560? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2013-09-09 09:56 -0400
Re: AREF bypass capacitance on ATMega2560? Robert Wessel <robertwessel2@yahoo.com> - 2013-09-12 11:50 -0500
Re: AREF bypass capacitance on ATMega2560? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2013-09-12 15:06 -0400
Re: AREF bypass capacitance on ATMega2560? Piotr Wyderski <peter.pan@neverland.mil> - 2013-09-12 14:57 +0200
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-13 00:21 -0400
Re: AREF bypass capacitance on ATMega2560? Piotr Wyderski <peter.pan@neverland.mil> - 2013-09-13 14:08 +0200
Re: AREF bypass capacitance on ATMega2560? Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-13 15:15 +0100
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-13 11:46 -0400
Re: AREF bypass capacitance on ATMega2560? Piotr Wyderski <peter.pan@neverland.mil> - 2013-09-13 18:43 +0200
Re: AREF bypass capacitance on ATMega2560? Piotr Wyderski <peter.pan@neverland.mil> - 2013-09-13 19:14 +0200
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-13 15:26 -0400
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-13 15:24 -0400
Re: AREF bypass capacitance on ATMega2560? David Brown <david.brown@removethis.hesbynett.no> - 2013-09-13 20:22 +0200
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 09:32 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 13:44 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 12:46 -0700
Re: AREF bypass capacitance on ATMega2560? Paul Rubin <no.email@nospam.invalid> - 2013-09-07 13:33 -0700
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 13:46 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 17:05 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 15:23 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 19:02 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 16:45 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 23:16 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-08 08:05 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-08 14:27 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-08 12:56 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-10 23:07 -0400
Re: AREF bypass capacitance on ATMega2560? Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-11 10:05 +0100
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-11 07:49 -0700
Re: AREF bypass capacitance on ATMega2560? Paul <paul@pcserviceselectronics.co.uk> - 2013-09-11 16:54 +0100
Re: AREF bypass capacitance on ATMega2560? "Tim Williams" <tmoranwms@charter.net> - 2013-09-11 11:25 -0500
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-11 09:49 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 11:40 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 11:38 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-08 09:34 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-08 14:29 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-08 13:01 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 16:22 -0400
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-10 23:09 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 16:15 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-08 14:20 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 18:15 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-08 15:57 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 19:46 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-08 17:15 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 20:20 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-09 07:17 -0700
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-09 12:17 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-09 19:30 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-09 16:38 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-10 14:02 -0400
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-10 23:41 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-11 00:04 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-11 07:53 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-11 21:50 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-12 09:58 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-12 18:54 -0400
Re: AREF bypass capacitance on ATMega2560? Piotr Wyderski <peter.pan@neverland.mil> - 2013-09-12 16:17 +0200
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-12 10:03 -0700
Re: AREF bypass capacitance on ATMega2560? Piotr Wyderski <peter.pan@neverland.mil> - 2013-09-12 19:24 +0200
Re: AREF bypass capacitance on ATMega2560? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2013-09-12 20:38 +0300
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-12 11:23 -0700
Re: AREF bypass capacitance on ATMega2560? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2013-09-12 22:36 +0300
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-12 12:41 -0700
Re: AREF bypass capacitance on ATMega2560? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2013-09-12 23:08 +0300
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-12 11:19 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-12 18:59 -0400
Re: AREF bypass capacitance on ATMega2560? Piotr Wyderski <peter.pan@neverland.mil> - 2013-09-13 13:00 +0200
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-14 12:05 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-12 16:03 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-12 14:42 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-13 00:24 -0400
Re: AREF bypass capacitance on ATMega2560? Piotr Wyderski <peter.pan@neverland.mil> - 2013-09-13 14:27 +0200
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-14 12:07 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-15 02:26 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-15 09:51 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-13 20:06 -0400
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 16:50 -0400
Re: AREF bypass capacitance on ATMega2560? Paul Rubin <no.email@nospam.invalid> - 2013-09-07 14:33 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 19:07 -0400
Re: AREF bypass capacitance on ATMega2560? Paul Rubin <no.email@nospam.invalid> - 2013-09-07 16:31 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 23:38 -0400
Re: AREF bypass capacitance on ATMega2560? Paul Rubin <no.email@nospam.invalid> - 2013-09-08 20:19 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-10 23:36 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 11:46 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 11:36 -0400
Re: AREF bypass capacitance on ATMega2560? John Devereux <john@devereux.me.uk> - 2013-09-08 09:04 +0100
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-08 13:42 -0400
Re: AREF bypass capacitance on ATMega2560? John Devereux <john@devereux.me.uk> - 2013-09-08 19:04 +0100
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-08 07:29 -0400
Re: AREF bypass capacitance on ATMega2560? John Devereux <john@devereux.me.uk> - 2013-09-09 08:56 +0100
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-10 23:54 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 16:24 -0400
Re: AREF bypass capacitance on ATMega2560? Ulf Samuelsson <ulf_samuelsson@invalid.telia.com> - 2013-09-07 20:11 +0200
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 15:06 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 12:54 -0700
Re: AREF bypass capacitance on ATMega2560? Ulf Samuelsson <ulf_samuelsson@invalid.telia.com> - 2013-09-02 22:27 +0200
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-08-19 13:14 -0700 |
| Subject | AREF bypass capacitance on ATMega2560? |
| Message-ID | <b7fcl9Ffqf7U1@mid.individual.net> |
Folks, What's the usual capacitance? Any stability issues there? I was planning on using a 1uF X7R ceramic cap on the AREF pin of an ATMega2560, in order to be able to use its internal bandgap reference. I saw people using 0.1uF and 0.47uF. The datasheet is silent about stuff like that, as usual. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [next] | [standalone]
| From | John Devereux <john@devereux.me.uk> |
|---|---|
| Date | 2013-08-20 20:16 +0100 |
| Message-ID | <87ioz08961.fsf@devereux.me.uk> |
| In reply to | #13136 |
Joerg <invalid@invalid.invalid> writes: > Folks, > > What's the usual capacitance? Any stability issues there? I was planning > on using a 1uF X7R ceramic cap on the AREF pin of an ATMega2560, in > order to be able to use its internal bandgap reference. I saw people > using 0.1uF and 0.47uF. The datasheet is silent about stuff like that, > as usual. MCU manufacturers are so generally so clueless with respect to the analog aspects... I would just experiment with a devkit if at all worried. -- John Devereux
[toc] | [prev] | [next] | [standalone]
| From | Vladimir Vassilevsky <nospam@nowhere.com> |
|---|---|
| Date | 2013-08-21 14:47 -0500 |
| Message-ID | <hdidneZGvImjhIjPnZ2dnUVZ5tmdnZ2d@giganews.com> |
| In reply to | #13136 |
On 8/19/2013 3:14 PM, Joerg wrote: > Folks, > What's the usual capacitance? 0.1uF > Any stability issues there? Nothing special. > I was planning > on using a 1uF X7R ceramic cap on the AREF pin of an ATMega2560, in > order to be able to use its internal bandgap reference. Do not. Use Vcc as reference. Internal reference is inaccurate. > I saw people > using 0.1uF and 0.47uF. The datasheet is silent about stuff like that, > as usual. It doesn't really matter. Vladimir Vassilevsky DSP and Mixed Signal Designs www.abvolt.com
[toc] | [prev] | [next] | [standalone]
| From | Jim Stewart <jstewart@jkmicro.com> |
|---|---|
| Date | 2013-08-21 13:18 -0700 |
| Message-ID | <kv37b0$jh5$1@dont-email.me> |
| In reply to | #13141 |
Vladimir Vassilevsky wrote: > On 8/19/2013 3:14 PM, Joerg wrote: > > > Folks, > > What's the usual capacitance? > > 0.1uF > > > Any stability issues there? > > Nothing special. > > > I was planning > > on using a 1uF X7R ceramic cap on the AREF pin of an ATMega2560, in > > order to be able to use its internal bandgap reference. > > Do not. Use Vcc as reference. > Internal reference is inaccurate. I noticed that awhile ago. The specs on my LDO regulator were about 5x better than the specs on the internal "reference".
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-08-21 16:38 -0700 |
| Message-ID | <b7l1blFlu93U2@mid.individual.net> |
| In reply to | #13141 |
Vladimir Vassilevsky wrote: > On 8/19/2013 3:14 PM, Joerg wrote: > >> Folks, >> What's the usual capacitance? > > 0.1uF > >> Any stability issues there? > > Nothing special. > >> I was planning >> on using a 1uF X7R ceramic cap on the AREF pin of an ATMega2560, in >> order to be able to use its internal bandgap reference. > > Do not. Use Vcc as reference. > Internal reference is inaccurate. > Yeah, sure looks ghastly. I provided my own reference from another board and filtered it with 0.1uF. >> I saw people >> using 0.1uF and 0.47uF. The datasheet is silent about stuff like that, >> as usual. > > It doesn't really matter. > However, not everyone knows that because they don't say much about the innards of the chip. It's my first ATMega case, or maybe the 2nd. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | "Tim Williams" <tmoranwms@charter.net> |
|---|---|
| Date | 2013-08-21 21:30 -0500 |
| Message-ID | <kv3t3p$mh$1@dont-email.me> |
| In reply to | #13143 |
"Joerg" <invalid@invalid.invalid> wrote in message news:b7l1blFlu93U2@mid.individual.net... >>> I saw people >>> using 0.1uF and 0.47uF. The datasheet is silent about stuff like that, >>> as usual. >> >> It doesn't really matter. >> > > However, not everyone knows that because they don't say much about the > innards of the chip. It's my first ATMega case, or maybe the 2nd. Finally gave up and bit the uC bullet? ;-) Tim -- Deep Friar: a very philosophical monk. Website: http://seventransistorlabs.com
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-08-22 10:51 -0700 |
| Message-ID | <b7n1d9F4bj0U1@mid.individual.net> |
| In reply to | #13144 |
Tim Williams wrote: > "Joerg" <invalid@invalid.invalid> wrote in message > news:b7l1blFlu93U2@mid.individual.net... >>>> I saw people >>>> using 0.1uF and 0.47uF. The datasheet is silent about stuff like that, >>>> as usual. >>> It doesn't really matter. >>> >> However, not everyone knows that because they don't say much about the >> innards of the chip. It's my first ATMega case, or maybe the 2nd. > > Finally gave up and bit the uC bullet? ;-) > Sometimes you need it. A while ago I even had a switcher design that would have been totally impossible to do without a uC. But it does raise eyebrows if I request timers and port pins and MIPS, probably because of my analog background. "YOU want some of the uC resources? What for?" -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-06 16:26 -0400 |
| Message-ID | <l0ddpd$14k$1@dont-email.me> |
| In reply to | #13151 |
On 8/22/2013 1:51 PM, Joerg wrote: > Tim Williams wrote: >> "Joerg"<invalid@invalid.invalid> wrote in message >> news:b7l1blFlu93U2@mid.individual.net... >>>>> I saw people >>>>> using 0.1uF and 0.47uF. The datasheet is silent about stuff like that, >>>>> as usual. >>>> It doesn't really matter. >>>> >>> However, not everyone knows that because they don't say much about the >>> innards of the chip. It's my first ATMega case, or maybe the 2nd. >> >> Finally gave up and bit the uC bullet? ;-) >> > > Sometimes you need it. A while ago I even had a switcher design that > would have been totally impossible to do without a uC. But it does raise > eyebrows if I request timers and port pins and MIPS, probably because of > my analog background. "YOU want some of the uC resources? What for?" Sounds to me like you need FPGA resources moreso than an MCU. Are you using the ADC or DAC, guess so or are you using the reference for the brownout or something else? DACs are easy in FPGAs, ADCs not as easy. Otherwise FPGAs do everything an MCU does plus... -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-06 13:33 -0700 |
| Message-ID | <b8ushnFif3nU1@mid.individual.net> |
| In reply to | #13334 |
rickman wrote: > On 8/22/2013 1:51 PM, Joerg wrote: >> Tim Williams wrote: >>> "Joerg"<invalid@invalid.invalid> wrote in message >>> news:b7l1blFlu93U2@mid.individual.net... >>>>>> I saw people >>>>>> using 0.1uF and 0.47uF. The datasheet is silent about stuff like >>>>>> that, >>>>>> as usual. >>>>> It doesn't really matter. >>>>> >>>> However, not everyone knows that because they don't say much about the >>>> innards of the chip. It's my first ATMega case, or maybe the 2nd. >>> >>> Finally gave up and bit the uC bullet? ;-) >>> >> >> Sometimes you need it. A while ago I even had a switcher design that >> would have been totally impossible to do without a uC. But it does raise >> eyebrows if I request timers and port pins and MIPS, probably because of >> my analog background. "YOU want some of the uC resources? What for?" > > Sounds to me like you need FPGA resources moreso than an MCU. Are you > using the ADC or DAC, guess so or are you using the reference for the > brownout or something else? DACs are easy in FPGAs, ADCs not as easy. > Otherwise FPGAs do everything an MCU does plus... > I nearly always need ADC capability. Not for the brownout, I never trust anything on those chips for that, the POR/BOR/WDT goes external. FPGA have some downsides, they tend to become large, expensive and sometimes power-hungry when you need math capability or an MCU core. But the main issue for many projects is people. If the client has the experts in house like in this case, fine. But if not then one is better off using a uC where one can find a programmer in nearly every town. This is one reason I am often partial to the 8051. Of course the beauty of FPGA is that the availability of very fast glue logic. Most uC are sorely lacking in that domain. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-06 17:12 -0400 |
| Message-ID | <l0dggl$i7r$1@dont-email.me> |
| In reply to | #13336 |
On 9/6/2013 4:33 PM, Joerg wrote: > rickman wrote: >> On 8/22/2013 1:51 PM, Joerg wrote: >>> Tim Williams wrote: >>>> "Joerg"<invalid@invalid.invalid> wrote in message >>>> news:b7l1blFlu93U2@mid.individual.net... >>>>>>> I saw people >>>>>>> using 0.1uF and 0.47uF. The datasheet is silent about stuff like >>>>>>> that, >>>>>>> as usual. >>>>>> It doesn't really matter. >>>>>> >>>>> However, not everyone knows that because they don't say much about the >>>>> innards of the chip. It's my first ATMega case, or maybe the 2nd. >>>> >>>> Finally gave up and bit the uC bullet? ;-) >>>> >>> >>> Sometimes you need it. A while ago I even had a switcher design that >>> would have been totally impossible to do without a uC. But it does raise >>> eyebrows if I request timers and port pins and MIPS, probably because of >>> my analog background. "YOU want some of the uC resources? What for?" >> >> Sounds to me like you need FPGA resources moreso than an MCU. Are you >> using the ADC or DAC, guess so or are you using the reference for the >> brownout or something else? DACs are easy in FPGAs, ADCs not as easy. >> Otherwise FPGAs do everything an MCU does plus... >> > > I nearly always need ADC capability. Not for the brownout, I never trust > anything on those chips for that, the POR/BOR/WDT goes external. FPGA > have some downsides, they tend to become large, expensive and sometimes > power-hungry when you need math capability or an MCU core. If your FPGA designs are expensive or power hungry, then you are doing things you can't do in an MCU or you are not using FPGAs properly. They don't need to use any more power than an MCU and in many cases less. They certainly don't need to be significantly more expensive unless you consider every dollar in your designs. At the very low end MCUs can be under $1 and still have reasonable performance. For $1 you can't get much in the way of programmable logic. For $3 however, you can get a chip large enough for a CPU (with math) and room for your special logic. > But the main > issue for many projects is people. If the client has the experts in > house like in this case, fine. But if not then one is better off using a > uC where one can find a programmer in nearly every town. This is one > reason I am often partial to the 8051. Do you work in *every* town? I find if I need a skill, it doesn't matter where the worker is. I also find FPGA design is pretty common these days. If you are ever short on FPGA design skills, give me a shout. > Of course the beauty of FPGA is that the availability of very fast glue > logic. Most uC are sorely lacking in that domain. Yes, the ideal chip would add a section of FPGA fabric to a conventional MCU and vary the size just as they do the RAM and Flash. I think at this point the problem is cultural. Most FPGA companies are all about the big iron selling for $100 a chip min and the MCU makers don't understand programmable logic. Xilinx and Cypress is good examples. Zync is a very high end solution, great if it matches your problem. PSOC is not a bad idea, but their idea of programmable logic isn't worth much. Give me a good $10 MCU/FPGA combo and I'll design the world! In the meantime I'll be using soft cores. They are a lot easier to program than an MCU anyway. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-06 16:10 -0700 |
| Message-ID | <b8v5o1Fk9f7U1@mid.individual.net> |
| In reply to | #13337 |
rickman wrote: > On 9/6/2013 4:33 PM, Joerg wrote: >> rickman wrote: >>> On 8/22/2013 1:51 PM, Joerg wrote: >>>> Tim Williams wrote: >>>>> "Joerg"<invalid@invalid.invalid> wrote in message >>>>> news:b7l1blFlu93U2@mid.individual.net... >>>>>>>> I saw people >>>>>>>> using 0.1uF and 0.47uF. The datasheet is silent about stuff like >>>>>>>> that, >>>>>>>> as usual. >>>>>>> It doesn't really matter. >>>>>>> >>>>>> However, not everyone knows that because they don't say much about >>>>>> the >>>>>> innards of the chip. It's my first ATMega case, or maybe the 2nd. >>>>> >>>>> Finally gave up and bit the uC bullet? ;-) >>>>> >>>> >>>> Sometimes you need it. A while ago I even had a switcher design that >>>> would have been totally impossible to do without a uC. But it does >>>> raise >>>> eyebrows if I request timers and port pins and MIPS, probably >>>> because of >>>> my analog background. "YOU want some of the uC resources? What for?" >>> >>> Sounds to me like you need FPGA resources moreso than an MCU. Are you >>> using the ADC or DAC, guess so or are you using the reference for the >>> brownout or something else? DACs are easy in FPGAs, ADCs not as easy. >>> Otherwise FPGAs do everything an MCU does plus... >>> >> >> I nearly always need ADC capability. Not for the brownout, I never trust >> anything on those chips for that, the POR/BOR/WDT goes external. FPGA >> have some downsides, they tend to become large, expensive and sometimes >> power-hungry when you need math capability or an MCU core. > > If your FPGA designs are expensive or power hungry, then you are doing > things you can't do in an MCU or you are not using FPGAs properly. They > don't need to use any more power than an MCU and in many cases less. > They certainly don't need to be significantly more expensive unless you > consider every dollar in your designs. At the very low end MCUs can be > under $1 and still have reasonable performance. For $1 you can't get > much in the way of programmable logic. ... That is often the problem. Sometimes a buck fifty is the pain threshold. Not in this ATMega case, the 2560 is very expensive but comes with lots of ADC and analog muxes and all that. Things that will cost extra with a FPGA solution and eat real estate. For $3 however, you can get a > chip large enough for a CPU (with math) and room for your special logic. > For $3 I can get a big DSP. > >> But the main >> issue for many projects is people. If the client has the experts in >> house like in this case, fine. But if not then one is better off using a >> uC where one can find a programmer in nearly every town. This is one >> reason I am often partial to the 8051. > > Do you work in *every* town? I find if I need a skill, it doesn't > matter where the worker is. ... Not in every town but sometimes way out there. For most work it doesn't matter where the worker is but with uC programming that is often not so. Mainly because things have to be optimized right there at the big machine which for one reason or the other can't be moved into a programmer's bedroom corner in Upper Sendusky. Then it does begin to matter whether or not you have to start flying in people. It's the same with myself. For many assigments I could as well live on East Rarotonga. But not for EMC or noise fixing jobs with larger installations. > ... I also find FPGA design is pretty common > these days. If you are ever short on FPGA design skills, give me a shout. > Could happen. What I often find is people only doing Altera or only Xilinx. With uC it's a bit easier, a PIC guy can be cajoled into programming an AVR, usually. > >> Of course the beauty of FPGA is that the availability of very fast glue >> logic. Most uC are sorely lacking in that domain. > > Yes, the ideal chip would add a section of FPGA fabric to a conventional > MCU and vary the size just as they do the RAM and Flash. I think at > this point the problem is cultural. Most FPGA companies are all about > the big iron selling for $100 a chip min and the MCU makers don't > understand programmable logic. Xilinx and Cypress is good examples. > Zync is a very high end solution, great if it matches your problem. PSOC > is not a bad idea, but their idea of programmable logic isn't worth much. > > Give me a good $10 MCU/FPGA combo and I'll design the world! In the > meantime I'll be using soft cores. They are a lot easier to program > than an MCU anyway. > Things quickly unravel when you start relying on real hardware that is on uC but not on FPGA. Comparators, ADCs, analog muxes, for example. Last week I reviewed a design with some larger FPGA on there. What I found fairly disgusting was how much they had to be babied with the power sequencing. uCs don't have that problem. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-06 23:59 -0400 |
| Message-ID | <l0e8cm$2i7$1@dont-email.me> |
| In reply to | #13338 |
On 9/6/2013 7:10 PM, Joerg wrote: > rickman wrote: >> On 9/6/2013 4:33 PM, Joerg wrote: >>> rickman wrote: >>>> On 8/22/2013 1:51 PM, Joerg wrote: >>>>> Tim Williams wrote: >>>>>> "Joerg"<invalid@invalid.invalid> wrote in message >>>>>> news:b7l1blFlu93U2@mid.individual.net... >>>>>>>>> I saw people >>>>>>>>> using 0.1uF and 0.47uF. The datasheet is silent about stuff like >>>>>>>>> that, >>>>>>>>> as usual. >>>>>>>> It doesn't really matter. >>>>>>>> >>>>>>> However, not everyone knows that because they don't say much about >>>>>>> the >>>>>>> innards of the chip. It's my first ATMega case, or maybe the 2nd. >>>>>> >>>>>> Finally gave up and bit the uC bullet? ;-) >>>>>> >>>>> >>>>> Sometimes you need it. A while ago I even had a switcher design that >>>>> would have been totally impossible to do without a uC. But it does >>>>> raise >>>>> eyebrows if I request timers and port pins and MIPS, probably >>>>> because of >>>>> my analog background. "YOU want some of the uC resources? What for?" >>>> >>>> Sounds to me like you need FPGA resources moreso than an MCU. Are you >>>> using the ADC or DAC, guess so or are you using the reference for the >>>> brownout or something else? DACs are easy in FPGAs, ADCs not as easy. >>>> Otherwise FPGAs do everything an MCU does plus... >>>> >>> >>> I nearly always need ADC capability. Not for the brownout, I never trust >>> anything on those chips for that, the POR/BOR/WDT goes external. FPGA >>> have some downsides, they tend to become large, expensive and sometimes >>> power-hungry when you need math capability or an MCU core. >> >> If your FPGA designs are expensive or power hungry, then you are doing >> things you can't do in an MCU or you are not using FPGAs properly. They >> don't need to use any more power than an MCU and in many cases less. >> They certainly don't need to be significantly more expensive unless you >> consider every dollar in your designs. At the very low end MCUs can be >> under $1 and still have reasonable performance. For $1 you can't get >> much in the way of programmable logic. ... > > > That is often the problem. Sometimes a buck fifty is the pain threshold. > Not in this ATMega case, the 2560 is very expensive but comes with lots > of ADC and analog muxes and all that. Things that will cost extra with a > FPGA solution and eat real estate. > > > For $3 however, you can get a >> chip large enough for a CPU (with math) and room for your special logic. >> > > For $3 I can get a big DSP. What "big" DSP can you get for $3? It has been a while since I looked hard at DSP chips, but I don't recall any I would call remotely "big" for $3. The TI chips that would be "big" are the TMS6xxx line which start somewhere around $20 the last time I looked and that requires all memory and I/O to be separate. The smaller DSP chips that you can get for the $3 range are not "big" in any sense and only a very few of them include Flash memory. So you still need another chip. Even a "small" FPGA can run rings around a DSP when it comes to performance. Usually "big" in DSPs means fast and when you want really fast DSP you use an FPGA with all the parallelism you can handle. DSPs can't touch FPGAs for speed, even with low power. >>> But the main >>> issue for many projects is people. If the client has the experts in >>> house like in this case, fine. But if not then one is better off using a >>> uC where one can find a programmer in nearly every town. This is one >>> reason I am often partial to the 8051. >> >> Do you work in *every* town? I find if I need a skill, it doesn't >> matter where the worker is. ... > > > Not in every town but sometimes way out there. For most work it doesn't > matter where the worker is but with uC programming that is often not so. > Mainly because things have to be optimized right there at the big > machine which for one reason or the other can't be moved into a > programmer's bedroom corner in Upper Sendusky. Then it does begin to > matter whether or not you have to start flying in people. > > It's the same with myself. For many assigments I could as well live on > East Rarotonga. But not for EMC or noise fixing jobs with larger > installations. I'm confused. Are you saying that on most jobs you don't care where the programmer lives and works? I think that is what you said, but it sounds like you are trying to disagree with me. >> ... I also find FPGA design is pretty common >> these days. If you are ever short on FPGA design skills, give me a shout. >> > > Could happen. > > What I often find is people only doing Altera or only Xilinx. With uC > it's a bit easier, a PIC guy can be cajoled into programming an AVR, > usually. I'm totally device agnostic. I have worked with all brands other than MicroSemi (formerly Actel). I even worked with Lucent which was bought by Lattice and I believe is still sold and supported (but not the GD XP line which I had designed into a cash cow product and will have to redesign now). Ever hear of Concurrent? They were bought by Atmel. Their devices were followed by the AT40K. I worked with the Concurrent devices. lol So you can see I go way back. I've used schematic based tools and both VHDL and Verilog. I've worked with the vendor's tools and third party tools including the NeoCAD tools which became Xilinx tools when Xilinx bought them. If anyone tells you they only know one brand of FPGA you are talking to an FPGA weenie. I find MCUs to vary a *great* deal more than FPGAs in terms of usage. MCUs need all sorts of start up code and peripheral drivers, clock control, etc, etc, etc. FPGAs not so much. They mostly have the same features and most of that can be inferred from the HDL so you never need to look too hard under the hood. In short, there is a lot of FUD about FPGAs. Talk to someone who doesn't buy into the FUD. >>> Of course the beauty of FPGA is that the availability of very fast glue >>> logic. Most uC are sorely lacking in that domain. >> >> Yes, the ideal chip would add a section of FPGA fabric to a conventional >> MCU and vary the size just as they do the RAM and Flash. I think at >> this point the problem is cultural. Most FPGA companies are all about >> the big iron selling for $100 a chip min and the MCU makers don't >> understand programmable logic. Xilinx and Cypress is good examples. >> Zync is a very high end solution, great if it matches your problem. PSOC >> is not a bad idea, but their idea of programmable logic isn't worth much. >> >> Give me a good $10 MCU/FPGA combo and I'll design the world! In the >> meantime I'll be using soft cores. They are a lot easier to program >> than an MCU anyway. >> > > Things quickly unravel when you start relying on real hardware that is > on uC but not on FPGA. Comparators, ADCs, analog muxes, for example. If you really need it all on a single chip, then yes, you won't find that on so many FPGAs although Microsemi has their Fusion line with analog. My cash cow uses a single FPGA and a stereo CODEC. That was smaller than any MCU design because the MCU would still require the CODEC (CD quality) and some of the control logic and interface could not be done with any conventional MCU. I had to vary the speed of the CODEC clock via an ADPLL to synchronize it with an incoming data stream. I don't know how to do that with an MCU and no logic. But I can do it all with FPGA logic and no MCU. > Last week I reviewed a design with some larger FPGA on there. What I > found fairly disgusting was how much they had to be babied with the > power sequencing. uCs don't have that problem. If you want to work with the wrong device, then you will find it hard to work with. There are still single voltage devices on the market. If this was an old design, most likely it was a Spartan 3 or similar era device when they (for still unknown reasons) used three, yes, count them, *three* voltages on the FPGA. The 2.5 volt aux supply was there solely for the configuration interface which was normally to a 3.3 volt device! Only from Xilinx... If this was a new device, then I guess they picked one based on something other than ease of use, eh? Don't assume all FPGAs are the same. You are aware that there are Flash based FPGAs that don't require the external Flash chip, right? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-07 08:10 -0700 |
| Message-ID | <b90u09Fj0uU1@mid.individual.net> |
| In reply to | #13339 |
rickman wrote: > On 9/6/2013 7:10 PM, Joerg wrote: >> rickman wrote: >>> On 9/6/2013 4:33 PM, Joerg wrote: >>>> rickman wrote: >>>>> On 8/22/2013 1:51 PM, Joerg wrote: >>>>>> Tim Williams wrote: >>>>>>> "Joerg"<invalid@invalid.invalid> wrote in message >>>>>>> news:b7l1blFlu93U2@mid.individual.net... >>>>>>>>>> I saw people >>>>>>>>>> using 0.1uF and 0.47uF. The datasheet is silent about stuff like >>>>>>>>>> that, >>>>>>>>>> as usual. >>>>>>>>> It doesn't really matter. >>>>>>>>> >>>>>>>> However, not everyone knows that because they don't say much about >>>>>>>> the >>>>>>>> innards of the chip. It's my first ATMega case, or maybe the 2nd. >>>>>>> >>>>>>> Finally gave up and bit the uC bullet? ;-) >>>>>>> >>>>>> >>>>>> Sometimes you need it. A while ago I even had a switcher design that >>>>>> would have been totally impossible to do without a uC. But it does >>>>>> raise >>>>>> eyebrows if I request timers and port pins and MIPS, probably >>>>>> because of >>>>>> my analog background. "YOU want some of the uC resources? What for?" >>>>> >>>>> Sounds to me like you need FPGA resources moreso than an MCU. Are you >>>>> using the ADC or DAC, guess so or are you using the reference for the >>>>> brownout or something else? DACs are easy in FPGAs, ADCs not as easy. >>>>> Otherwise FPGAs do everything an MCU does plus... >>>>> >>>> >>>> I nearly always need ADC capability. Not for the brownout, I never >>>> trust >>>> anything on those chips for that, the POR/BOR/WDT goes external. FPGA >>>> have some downsides, they tend to become large, expensive and sometimes >>>> power-hungry when you need math capability or an MCU core. >>> >>> If your FPGA designs are expensive or power hungry, then you are doing >>> things you can't do in an MCU or you are not using FPGAs properly. They >>> don't need to use any more power than an MCU and in many cases less. >>> They certainly don't need to be significantly more expensive unless you >>> consider every dollar in your designs. At the very low end MCUs can be >>> under $1 and still have reasonable performance. For $1 you can't get >>> much in the way of programmable logic. ... >> >> >> That is often the problem. Sometimes a buck fifty is the pain threshold. >> Not in this ATMega case, the 2560 is very expensive but comes with lots >> of ADC and analog muxes and all that. Things that will cost extra with a >> FPGA solution and eat real estate. >> >> >> For $3 however, you can get a >>> chip large enough for a CPU (with math) and room for your special logic. >>> >> >> For $3 I can get a big DSP. > > What "big" DSP can you get for $3? ... For example, this: http://www.ti.com/lit/ds/symlink/tms320c5535.pdf > ... It has been a while since I looked > hard at DSP chips, but I don't recall any I would call remotely "big" > for $3. The TI chips that would be "big" are the TMS6xxx line which > start somewhere around $20 the last time I looked and that requires all > memory and I/O to be separate. The smaller DSP chips that you can get > for the $3 range are not "big" in any sense and only a very few of them > include Flash memory. So you still need another chip. > It has tons of memory on board. > Even a "small" FPGA can run rings around a DSP when it comes to > performance. Usually "big" in DSPs means fast and when you want really > fast DSP you use an FPGA with all the parallelism you can handle. DSPs > can't touch FPGAs for speed, even with low power. > Most of the really powerful FPGA that I connected to or had to review designs with them in there were painfully expensive. > >>>> But the main >>>> issue for many projects is people. If the client has the experts in >>>> house like in this case, fine. But if not then one is better off >>>> using a >>>> uC where one can find a programmer in nearly every town. This is one >>>> reason I am often partial to the 8051. >>> >>> Do you work in *every* town? I find if I need a skill, it doesn't >>> matter where the worker is. ... >> >> >> Not in every town but sometimes way out there. For most work it doesn't >> matter where the worker is but with uC programming that is often not so. >> Mainly because things have to be optimized right there at the big >> machine which for one reason or the other can't be moved into a >> programmer's bedroom corner in Upper Sendusky. Then it does begin to >> matter whether or not you have to start flying in people. >> >> It's the same with myself. For many assigments I could as well live on >> East Rarotonga. But not for EMC or noise fixing jobs with larger >> installations. > > I'm confused. Are you saying that on most jobs you don't care where the > programmer lives and works? ... Yes, on most but _not_ all. That's key. > ... I think that is what you said, but it > sounds like you are trying to disagree with me. > I disagree with the statement "it doesn't matter where the worker is". Because sometimes (not always) it does matter. And when it does, close proximity is very important. Then you need to literally work side-by-side. Done it many times. Our local SW guy sold his horse ranch and moved out of California. Only to Reno which is under 2h drive but that's already a bit far. And in winter you might not get through the pass or can't get back home. > >>> ... I also find FPGA design is pretty common >>> these days. If you are ever short on FPGA design skills, give me a >>> shout. >>> >> >> Could happen. >> >> What I often find is people only doing Altera or only Xilinx. With uC >> it's a bit easier, a PIC guy can be cajoled into programming an AVR, >> usually. > > I'm totally device agnostic. I have worked with all brands other than > MicroSemi (formerly Actel). I even worked with Lucent which was bought > by Lattice and I believe is still sold and supported (but not the GD XP > line which I had designed into a cash cow product and will have to > redesign now). Ever hear of Concurrent? They were bought by Atmel. > Their devices were followed by the AT40K. I worked with the Concurrent > devices. lol So you can see I go way back. > My only foray into the world of programmable logic was an old Intel series. Because it was the first that didn't guzzle power as if it was free. But in hindsight I was glad I abandoned that. Because Intel did. > I've used schematic based tools and both VHDL and Verilog. I've worked > with the vendor's tools and third party tools including the NeoCAD tools > which became Xilinx tools when Xilinx bought them. > > If anyone tells you they only know one brand of FPGA you are talking to > an FPGA weenie. I find MCUs to vary a *great* deal more than FPGAs in > terms of usage. MCUs need all sorts of start up code and peripheral > drivers, clock control, etc, etc, etc. FPGAs not so much. They mostly > have the same features and most of that can be inferred from the HDL so > you never need to look too hard under the hood. > > In short, there is a lot of FUD about FPGAs. Talk to someone who > doesn't buy into the FUD. > Yeah, maybe next time I need major logic we should talk. But better not about politics :-) > >>>> Of course the beauty of FPGA is that the availability of very fast glue >>>> logic. Most uC are sorely lacking in that domain. >>> >>> Yes, the ideal chip would add a section of FPGA fabric to a conventional >>> MCU and vary the size just as they do the RAM and Flash. I think at >>> this point the problem is cultural. Most FPGA companies are all about >>> the big iron selling for $100 a chip min and the MCU makers don't >>> understand programmable logic. Xilinx and Cypress is good examples. >>> Zync is a very high end solution, great if it matches your problem. PSOC >>> is not a bad idea, but their idea of programmable logic isn't worth >>> much. >>> >>> Give me a good $10 MCU/FPGA combo and I'll design the world! In the >>> meantime I'll be using soft cores. They are a lot easier to program >>> than an MCU anyway. >>> >> >> Things quickly unravel when you start relying on real hardware that is >> on uC but not on FPGA. Comparators, ADCs, analog muxes, for example. > > If you really need it all on a single chip, then yes, you won't find > that on so many FPGAs although Microsemi has their Fusion line with > analog. My cash cow uses a single FPGA and a stereo CODEC. That was > smaller than any MCU design because the MCU would still require the > CODEC (CD quality) and some of the control logic and interface could not > be done with any conventional MCU. I had to vary the speed of the CODEC > clock via an ADPLL to synchronize it with an incoming data stream. I > don't know how to do that with an MCU and no logic. But I can do it all > with FPGA logic and no MCU. > Hmm, I was looking at audio interfacing just yesterday because I am going to need that on one new project. There's plenty out there that should be directly adressable via MCU. For me it's probably going to be something from the PCM290x series but there's also SPI variants and so on. Anyhow, I am also going to need ADC and comparator, including muxes for them, so this one will likely be a uC case again because otherwise all this has to be added externally. > >> Last week I reviewed a design with some larger FPGA on there. What I >> found fairly disgusting was how much they had to be babied with the >> power sequencing. uCs don't have that problem. > > If you want to work with the wrong device, then you will find it hard to > work with. There are still single voltage devices on the market. If > this was an old design, most likely it was a Spartan 3 or similar era > device when they (for still unknown reasons) used three, yes, count > them, *three* voltages on the FPGA. The 2.5 volt aux supply was there > solely for the configuration interface which was normally to a 3.3 volt > device! Only from Xilinx... > > If this was a new device, then I guess they picked one based on > something other than ease of use, eh? Don't assume all FPGAs are the same. > Well, this guy is a real expert on high-end FPGA and the project requires stuff with tons of horsepower. > You are aware that there are Flash based FPGAs that don't require the > external Flash chip, right? > Same with uCs, since a very long time :-) -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-07 13:03 -0400 |
| Message-ID | <l0fm8f$uts$1@dont-email.me> |
| In reply to | #13343 |
On 9/7/2013 11:10 AM, Joerg wrote: > rickman wrote: >> On 9/6/2013 7:10 PM, Joerg wrote: >>> >>> That is often the problem. Sometimes a buck fifty is the pain threshold. >>> Not in this ATMega case, the 2560 is very expensive but comes with lots >>> of ADC and analog muxes and all that. Things that will cost extra with a >>> FPGA solution and eat real estate. >>> >>> >>> For $3 however, you can get a >>>> chip large enough for a CPU (with math) and room for your special logic. >>>> >>> >>> For $3 I can get a big DSP. >> >> What "big" DSP can you get for $3? ... > > > For example, this: > > http://www.ti.com/lit/ds/symlink/tms320c5535.pdf I don't see it for $3. Did you get a quote for your project? TI says it is $5 to $8 at qty 1k depending on the flavor. You still need to add Flash. >> ... It has been a while since I looked >> hard at DSP chips, but I don't recall any I would call remotely "big" >> for $3. The TI chips that would be "big" are the TMS6xxx line which >> start somewhere around $20 the last time I looked and that requires all >> memory and I/O to be separate. The smaller DSP chips that you can get >> for the $3 range are not "big" in any sense and only a very few of them >> include Flash memory. So you still need another chip. >> > > It has tons of memory on board. Yes, and many FPGAs have "tons" of memory on board although not for $3... but then this isn't a $3 part either... >> Even a "small" FPGA can run rings around a DSP when it comes to >> performance. Usually "big" in DSPs means fast and when you want really >> fast DSP you use an FPGA with all the parallelism you can handle. DSPs >> can't touch FPGAs for speed, even with low power. >> > > Most of the really powerful FPGA that I connected to or had to review > designs with them in there were painfully expensive. Because you were looking at FPGAs that were "painfully" large I'm sure. How many pins, 256, 400+...? 20,000 LUTs, 40,000 LUTs? >>> It's the same with myself. For many assigments I could as well live on >>> East Rarotonga. But not for EMC or noise fixing jobs with larger >>> installations. >> >> I'm confused. Are you saying that on most jobs you don't care where the >> programmer lives and works? ... > > > Yes, on most but _not_ all. That's key. So you could use FPGA instead of an MCU on most of your designs? I'm still confused. Are you saying if you can't use a part on all of your designs you don't want to use it on any? >> ... I think that is what you said, but it >> sounds like you are trying to disagree with me. >> > > I disagree with the statement "it doesn't matter where the worker is". > Because sometimes (not always) it does matter. And when it does, close > proximity is very important. Then you need to literally work > side-by-side. Done it many times. > > Our local SW guy sold his horse ranch and moved out of California. Only > to Reno which is under 2h drive but that's already a bit far. And in > winter you might not get through the pass or can't get back home. I have done many jobs remotely and it has *never* been a problem. If debugging is needed in the field, that is not the same thing as saying the developer has to be in the field. You are welcome to disagree on this. I can only remember one time where I iterated through design changes in the field and that was actually a case where I could have done it all remotely, but I was pleasing the customer to be there. Turns out he wasn't initializing the design right and it was hard to detect. One big advantage to FPGAs is the ability to simulate at a low level. it is very easy to emulate the I/O in an HDL simulation. I don't know how they do that with MCUs, but in the FPGA world I've never had a problem. >>>> ... I also find FPGA design is pretty common >>>> these days. If you are ever short on FPGA design skills, give me a >>>> shout. >>>> >>> >>> Could happen. >>> >>> What I often find is people only doing Altera or only Xilinx. With uC >>> it's a bit easier, a PIC guy can be cajoled into programming an AVR, >>> usually. >> >> I'm totally device agnostic. I have worked with all brands other than >> MicroSemi (formerly Actel). I even worked with Lucent which was bought >> by Lattice and I believe is still sold and supported (but not the GD XP >> line which I had designed into a cash cow product and will have to >> redesign now). Ever hear of Concurrent? They were bought by Atmel. >> Their devices were followed by the AT40K. I worked with the Concurrent >> devices. lol So you can see I go way back. >> > > My only foray into the world of programmable logic was an old Intel > series. Because it was the first that didn't guzzle power as if it was > free. But in hindsight I was glad I abandoned that. Because Intel did. Wow! That was a *long* time ago. FPGAs have changed a lot. Just not so much from Xilinx. >> I've used schematic based tools and both VHDL and Verilog. I've worked >> with the vendor's tools and third party tools including the NeoCAD tools >> which became Xilinx tools when Xilinx bought them. >> >> If anyone tells you they only know one brand of FPGA you are talking to >> an FPGA weenie. I find MCUs to vary a *great* deal more than FPGAs in >> terms of usage. MCUs need all sorts of start up code and peripheral >> drivers, clock control, etc, etc, etc. FPGAs not so much. They mostly >> have the same features and most of that can be inferred from the HDL so >> you never need to look too hard under the hood. >> >> In short, there is a lot of FUD about FPGAs. Talk to someone who >> doesn't buy into the FUD. >> > > Yeah, maybe next time I need major logic we should talk. But better not > about politics :-) Yeah... Even if you need minor logic let's talk. I find the real advantage to FPGAs is in the fact that I can do almost *anything* in one. I don't need to add stuff unless it is very application specific like the CD quality CODEC on my current production board. I could get CD quality from an FPGA design, but it wouldn't be worth the work to save a $3 part. >>> Things quickly unravel when you start relying on real hardware that is >>> on uC but not on FPGA. Comparators, ADCs, analog muxes, for example. >> >> If you really need it all on a single chip, then yes, you won't find >> that on so many FPGAs although Microsemi has their Fusion line with >> analog. My cash cow uses a single FPGA and a stereo CODEC. That was >> smaller than any MCU design because the MCU would still require the >> CODEC (CD quality) and some of the control logic and interface could not >> be done with any conventional MCU. I had to vary the speed of the CODEC >> clock via an ADPLL to synchronize it with an incoming data stream. I >> don't know how to do that with an MCU and no logic. But I can do it all >> with FPGA logic and no MCU. >> > > Hmm, I was looking at audio interfacing just yesterday because I am > going to need that on one new project. There's plenty out there that > should be directly adressable via MCU. For me it's probably going to be > something from the PCM290x series but there's also SPI variants and so on. > > Anyhow, I am also going to need ADC and comparator, including muxes for > them, so this one will likely be a uC case again because otherwise all > this has to be added externally. You do know that it is not hard to add an ADC to an FPGA? No need for a mux if all the inputs can be connected to separate pins. It all depends on the resolution you need. 8 bits is easy, 16 bits - not so easy. >>> Last week I reviewed a design with some larger FPGA on there. What I >>> found fairly disgusting was how much they had to be babied with the >>> power sequencing. uCs don't have that problem. >> >> If you want to work with the wrong device, then you will find it hard to >> work with. There are still single voltage devices on the market. If >> this was an old design, most likely it was a Spartan 3 or similar era >> device when they (for still unknown reasons) used three, yes, count >> them, *three* voltages on the FPGA. The 2.5 volt aux supply was there >> solely for the configuration interface which was normally to a 3.3 volt >> device! Only from Xilinx... >> >> If this was a new device, then I guess they picked one based on >> something other than ease of use, eh? Don't assume all FPGAs are the same. >> > > Well, this guy is a real expert on high-end FPGA and the project > requires stuff with tons of horsepower. That's fine, just don't judge all FPGAs by the ones you have seen. If the only MCU you had worked with were ARM 11s using 3 Watts and running a cell phone down in 8 hours, would you think the PIC MCUs were the same? >> You are aware that there are Flash based FPGAs that don't require the >> external Flash chip, right? >> > > Same with uCs, since a very long time :-) You are missing my point. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-07 10:59 -0700 |
| Message-ID | <b917s1F2k40U1@mid.individual.net> |
| In reply to | #13347 |
rickman wrote: > On 9/7/2013 11:10 AM, Joerg wrote: >> rickman wrote: >>> On 9/6/2013 7:10 PM, Joerg wrote: >>>> >>>> That is often the problem. Sometimes a buck fifty is the pain >>>> threshold. >>>> Not in this ATMega case, the 2560 is very expensive but comes with lots >>>> of ADC and analog muxes and all that. Things that will cost extra >>>> with a >>>> FPGA solution and eat real estate. >>>> >>>> >>>> For $3 however, you can get a >>>>> chip large enough for a CPU (with math) and room for your special >>>>> logic. >>>>> >>>> >>>> For $3 I can get a big DSP. >>> >>> What "big" DSP can you get for $3? ... >> >> >> For example, this: >> >> http://www.ti.com/lit/ds/symlink/tms320c5535.pdf > > I don't see it for $3. Did you get a quote for your project? TI says > it is $5 to $8 at qty 1k depending on the flavor. You still need to add > Flash. > 1k qty is $3.67 at Digikey: http://www.digikey.com/product-detail/en/TMS320C5532AZHH10/296-32741-ND/2749713 $3.02 with 12wks leadtime at Arrow: http://components.arrow.com/part/detail/51425505S8988412N7713?region=na ROM is included. > >>> ... It has been a while since I looked >>> hard at DSP chips, but I don't recall any I would call remotely "big" >>> for $3. The TI chips that would be "big" are the TMS6xxx line which >>> start somewhere around $20 the last time I looked and that requires all >>> memory and I/O to be separate. The smaller DSP chips that you can get >>> for the $3 range are not "big" in any sense and only a very few of them >>> include Flash memory. So you still need another chip. >>> >> >> It has tons of memory on board. > > Yes, and many FPGAs have "tons" of memory on board although not for > $3... but then this isn't a $3 part either... > It is a $3 part. See above. > >>> Even a "small" FPGA can run rings around a DSP when it comes to >>> performance. Usually "big" in DSPs means fast and when you want really >>> fast DSP you use an FPGA with all the parallelism you can handle. DSPs >>> can't touch FPGAs for speed, even with low power. >>> >> >> Most of the really powerful FPGA that I connected to or had to review >> designs with them in there were painfully expensive. > > Because you were looking at FPGAs that were "painfully" large I'm sure. > How many pins, 256, 400+...? 20,000 LUTs, 40,000 LUTs? > Sure, that's why I wrote "powerful". The less powerful ones have never impressed me much but I have to admit that I haven't looked the last five years. So, tell us, which FPGA can fully replace the above DSP for three bucks and where could one buy it off the shelf? > >>>> It's the same with myself. For many assigments I could as well live on >>>> East Rarotonga. But not for EMC or noise fixing jobs with larger >>>> installations. >>> >>> I'm confused. Are you saying that on most jobs you don't care where the >>> programmer lives and works? ... >> >> >> Yes, on most but _not_ all. That's key. > > So you could use FPGA instead of an MCU on most of your designs? I'm > still confused. Are you saying if you can't use a part on all of your > designs you don't want to use it on any? > No, what I am saying is the it doesn't matter much which parts I use (my clients decide that anyhow) but that finding a programmer locally can be important. Some projects will not really come off the ground if the programmer isn't local. Or it can take forever. > >>> ... I think that is what you said, but it >>> sounds like you are trying to disagree with me. >>> >> >> I disagree with the statement "it doesn't matter where the worker is". >> Because sometimes (not always) it does matter. And when it does, close >> proximity is very important. Then you need to literally work >> side-by-side. Done it many times. >> >> Our local SW guy sold his horse ranch and moved out of California. Only >> to Reno which is under 2h drive but that's already a bit far. And in >> winter you might not get through the pass or can't get back home. > > I have done many jobs remotely and it has *never* been a problem. If > debugging is needed in the field, that is not the same thing as saying > the developer has to be in the field. You are welcome to disagree on this. > I do disagree. > I can only remember one time where I iterated through design changes in > the field and that was actually a case where I could have done it all > remotely, but I was pleasing the customer to be there. Turns out he > wasn't initializing the design right and it was hard to detect. > Well, if you are standing next to a huge roaring engine and this, that and the other subtle disturbance has to be ironed out it would be a major problem if the programmer is three time zones away. You don't have to believe me but that's how it is with some of my assignments. Just like EMC jobs on large gear can simply not be done remotely. Which is why I bought the Signalhound analyzer (fits into carry-on). > One big advantage to FPGAs is the ability to simulate at a low level. it > is very easy to emulate the I/O in an HDL simulation. I don't know how > they do that with MCUs, but in the FPGA world I've never had a problem. > That is undoubtedly true. Plus probably less in errata headaches. [...] >>> I've used schematic based tools and both VHDL and Verilog. I've worked >>> with the vendor's tools and third party tools including the NeoCAD tools >>> which became Xilinx tools when Xilinx bought them. >>> >>> If anyone tells you they only know one brand of FPGA you are talking to >>> an FPGA weenie. I find MCUs to vary a *great* deal more than FPGAs in >>> terms of usage. MCUs need all sorts of start up code and peripheral >>> drivers, clock control, etc, etc, etc. FPGAs not so much. They mostly >>> have the same features and most of that can be inferred from the HDL so >>> you never need to look too hard under the hood. >>> >>> In short, there is a lot of FUD about FPGAs. Talk to someone who >>> doesn't buy into the FUD. >>> >> >> Yeah, maybe next time I need major logic we should talk. But better not >> about politics :-) > > Yeah... Even if you need minor logic let's talk. I find the real > advantage to FPGAs is in the fact that I can do almost *anything* in > one. I don't need to add stuff unless it is very application specific > like the CD quality CODEC on my current production board. I could get > CD quality from an FPGA design, but it wouldn't be worth the work to > save a $3 part. > So far the next project on the books that will contain logic is 2nd half of next year. It will need a 16-bit audio codec as well but we can use an external chip for that, PCM29xx series et cetera. Would (probably) even keep it external with a uC because the 16-bit ADCs on those aren't very quiet. > >>>> Things quickly unravel when you start relying on real hardware that is >>>> on uC but not on FPGA. Comparators, ADCs, analog muxes, for example. >>> >>> If you really need it all on a single chip, then yes, you won't find >>> that on so many FPGAs although Microsemi has their Fusion line with >>> analog. My cash cow uses a single FPGA and a stereo CODEC. That was >>> smaller than any MCU design because the MCU would still require the >>> CODEC (CD quality) and some of the control logic and interface could not >>> be done with any conventional MCU. I had to vary the speed of the CODEC >>> clock via an ADPLL to synchronize it with an incoming data stream. I >>> don't know how to do that with an MCU and no logic. But I can do it all >>> with FPGA logic and no MCU. >>> >> >> Hmm, I was looking at audio interfacing just yesterday because I am >> going to need that on one new project. There's plenty out there that >> should be directly adressable via MCU. For me it's probably going to be >> something from the PCM290x series but there's also SPI variants and so >> on. >> >> Anyhow, I am also going to need ADC and comparator, including muxes for >> them, so this one will likely be a uC case again because otherwise all >> this has to be added externally. > > You do know that it is not hard to add an ADC to an FPGA? No need for a > mux if all the inputs can be connected to separate pins. It all depends > on the resolution you need. 8 bits is easy, 16 bits - not so easy. > Mine are never less than 12-bit, often 16-bit. > >>>> Last week I reviewed a design with some larger FPGA on there. What I >>>> found fairly disgusting was how much they had to be babied with the >>>> power sequencing. uCs don't have that problem. >>> >>> If you want to work with the wrong device, then you will find it hard to >>> work with. There are still single voltage devices on the market. If >>> this was an old design, most likely it was a Spartan 3 or similar era >>> device when they (for still unknown reasons) used three, yes, count >>> them, *three* voltages on the FPGA. The 2.5 volt aux supply was there >>> solely for the configuration interface which was normally to a 3.3 volt >>> device! Only from Xilinx... >>> >>> If this was a new device, then I guess they picked one based on >>> something other than ease of use, eh? Don't assume all FPGAs are the >>> same. >>> >> >> Well, this guy is a real expert on high-end FPGA and the project >> requires stuff with tons of horsepower. > > That's fine, just don't judge all FPGAs by the ones you have seen. If > the only MCU you had worked with were ARM 11s using 3 Watts and running > a cell phone down in 8 hours, would you think the PIC MCUs were the same? > Well, give us all here an example of a FPGA that can fully emulate a TSM320 and costs $3 :-) > >>> You are aware that there are Flash based FPGAs that don't require the >>> external Flash chip, right? >>> >> >> Same with uCs, since a very long time :-) > > You are missing my point. > I guess then I don't see your point. Flash is available on almost everything nowadays. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-07 14:54 -0400 |
| Message-ID | <l0fspa$3ot$1@dont-email.me> |
| In reply to | #13351 |
On 9/7/2013 1:59 PM, Joerg wrote: > rickman wrote: >> On 9/7/2013 11:10 AM, Joerg wrote: >>> rickman wrote: >>>> On 9/6/2013 7:10 PM, Joerg wrote: >>>>> >>>>> That is often the problem. Sometimes a buck fifty is the pain >>>>> threshold. >>>>> Not in this ATMega case, the 2560 is very expensive but comes with lots >>>>> of ADC and analog muxes and all that. Things that will cost extra >>>>> with a >>>>> FPGA solution and eat real estate. >>>>> >>>>> >>>>> For $3 however, you can get a >>>>>> chip large enough for a CPU (with math) and room for your special >>>>>> logic. >>>>>> >>>>> >>>>> For $3 I can get a big DSP. >>>> >>>> What "big" DSP can you get for $3? ... >>> >>> >>> For example, this: >>> >>> http://www.ti.com/lit/ds/symlink/tms320c5535.pdf >> >> I don't see it for $3. Did you get a quote for your project? TI says >> it is $5 to $8 at qty 1k depending on the flavor. You still need to add >> Flash. >> > > 1k qty is $3.67 at Digikey: > > http://www.digikey.com/product-detail/en/TMS320C5532AZHH10/296-32741-ND/2749713 Not the same part pal. You're trying to pull a fast one on me? Are we talking about the TMS320C5535 with "tons" of memory or the TMS320C5532 with *much* less memory? > $3.02 with 12wks leadtime at Arrow: > > http://components.arrow.com/part/detail/51425505S8988412N7713?region=na > > ROM is included. ROM is not Flash.. is it? Are you thinking in terms of a mask ROM? >>>> ... It has been a while since I looked >>>> hard at DSP chips, but I don't recall any I would call remotely "big" >>>> for $3. The TI chips that would be "big" are the TMS6xxx line which >>>> start somewhere around $20 the last time I looked and that requires all >>>> memory and I/O to be separate. The smaller DSP chips that you can get >>>> for the $3 range are not "big" in any sense and only a very few of them >>>> include Flash memory. So you still need another chip. >>>> >>> >>> It has tons of memory on board. >> >> Yes, and many FPGAs have "tons" of memory on board although not for >> $3... but then this isn't a $3 part either... >> > > It is a $3 part. See above. No, you need to pick a part number and stick with it. >>>> Even a "small" FPGA can run rings around a DSP when it comes to >>>> performance. Usually "big" in DSPs means fast and when you want really >>>> fast DSP you use an FPGA with all the parallelism you can handle. DSPs >>>> can't touch FPGAs for speed, even with low power. >>>> >>> >>> Most of the really powerful FPGA that I connected to or had to review >>> designs with them in there were painfully expensive. >> >> Because you were looking at FPGAs that were "painfully" large I'm sure. >> How many pins, 256, 400+...? 20,000 LUTs, 40,000 LUTs? >> > > Sure, that's why I wrote "powerful". The less powerful ones have never > impressed me much but I have to admit that I haven't looked the last > five years. So, tell us, which FPGA can fully replace the above DSP for > three bucks and where could one buy it off the shelf? Lol, I don't know where you are coming from now. You don't like the large FPGAs because they use power like they are... well, large. You don't like the small FPGAs because they are, well... small. When you stop using terms like "powerful" and want to actually consider an FPGA for a design I can help you. Gut feel is nice as long as it is based in fact. >>>>> It's the same with myself. For many assigments I could as well live on >>>>> East Rarotonga. But not for EMC or noise fixing jobs with larger >>>>> installations. >>>> >>>> I'm confused. Are you saying that on most jobs you don't care where the >>>> programmer lives and works? ... >>> >>> >>> Yes, on most but _not_ all. That's key. >> >> So you could use FPGA instead of an MCU on most of your designs? I'm >> still confused. Are you saying if you can't use a part on all of your >> designs you don't want to use it on any? >> > > No, what I am saying is the it doesn't matter much which parts I use (my > clients decide that anyhow) but that finding a programmer locally can be > important. Some projects will not really come off the ground if the > programmer isn't local. Or it can take forever. That is the point I am trying to dispute. My experience has been that a remote team is a very capable team and can do pretty much any job. Colocation is seldom an important issue. So far your statements have all supported that with a few exceptions. At least that is how I have read the words. "Some projects", "For most work it doesn't matter where the worker is", etc... YMMV >>>> ... I think that is what you said, but it >>>> sounds like you are trying to disagree with me. >>>> >>> >>> I disagree with the statement "it doesn't matter where the worker is". >>> Because sometimes (not always) it does matter. And when it does, close >>> proximity is very important. Then you need to literally work >>> side-by-side. Done it many times. >>> >>> Our local SW guy sold his horse ranch and moved out of California. Only >>> to Reno which is under 2h drive but that's already a bit far. And in >>> winter you might not get through the pass or can't get back home. >> >> I have done many jobs remotely and it has *never* been a problem. If >> debugging is needed in the field, that is not the same thing as saying >> the developer has to be in the field. You are welcome to disagree on this. >> > > I do disagree. Ok, but the examples you give tend to support remote work except in a few cases. I'm just reading the words you wrote, I'm not putting them in your mouth. >> I can only remember one time where I iterated through design changes in >> the field and that was actually a case where I could have done it all >> remotely, but I was pleasing the customer to be there. Turns out he >> wasn't initializing the design right and it was hard to detect. >> > > Well, if you are standing next to a huge roaring engine and this, that > and the other subtle disturbance has to be ironed out it would be a > major problem if the programmer is three time zones away. You don't have > to believe me but that's how it is with some of my assignments. > > Just like EMC jobs on large gear can simply not be done remotely. Which > is why I bought the Signalhound analyzer (fits into carry-on). I don't argue your needs. You keep saying these special jobs are a small percentage of your work. So most assignments will work just fine with remote support, no? >> One big advantage to FPGAs is the ability to simulate at a low level. it >> is very easy to emulate the I/O in an HDL simulation. I don't know how >> they do that with MCUs, but in the FPGA world I've never had a problem. >> > > That is undoubtedly true. Plus probably less in errata headaches. > > [...] > > >>>> I've used schematic based tools and both VHDL and Verilog. I've worked >>>> with the vendor's tools and third party tools including the NeoCAD tools >>>> which became Xilinx tools when Xilinx bought them. >>>> >>>> If anyone tells you they only know one brand of FPGA you are talking to >>>> an FPGA weenie. I find MCUs to vary a *great* deal more than FPGAs in >>>> terms of usage. MCUs need all sorts of start up code and peripheral >>>> drivers, clock control, etc, etc, etc. FPGAs not so much. They mostly >>>> have the same features and most of that can be inferred from the HDL so >>>> you never need to look too hard under the hood. >>>> >>>> In short, there is a lot of FUD about FPGAs. Talk to someone who >>>> doesn't buy into the FUD. >>>> >>> >>> Yeah, maybe next time I need major logic we should talk. But better not >>> about politics :-) >> >> Yeah... Even if you need minor logic let's talk. I find the real >> advantage to FPGAs is in the fact that I can do almost *anything* in >> one. I don't need to add stuff unless it is very application specific >> like the CD quality CODEC on my current production board. I could get >> CD quality from an FPGA design, but it wouldn't be worth the work to >> save a $3 part. >> > > So far the next project on the books that will contain logic is 2nd half > of next year. It will need a 16-bit audio codec as well but we can use > an external chip for that, PCM29xx series et cetera. Would (probably) > even keep it external with a uC because the 16-bit ADCs on those aren't > very quiet. Not sure what the requirements are for your CODEC, but I have been using the AKM parts with good results. Minimal or *no* programming, configuration is done by a small number of select pins, very simple. I have yet to find another one as small, AK4552, AK4556. >>>>> Things quickly unravel when you start relying on real hardware that is >>>>> on uC but not on FPGA. Comparators, ADCs, analog muxes, for example. >>>> >>>> If you really need it all on a single chip, then yes, you won't find >>>> that on so many FPGAs although Microsemi has their Fusion line with >>>> analog. My cash cow uses a single FPGA and a stereo CODEC. That was >>>> smaller than any MCU design because the MCU would still require the >>>> CODEC (CD quality) and some of the control logic and interface could not >>>> be done with any conventional MCU. I had to vary the speed of the CODEC >>>> clock via an ADPLL to synchronize it with an incoming data stream. I >>>> don't know how to do that with an MCU and no logic. But I can do it all >>>> with FPGA logic and no MCU. >>>> >>> >>> Hmm, I was looking at audio interfacing just yesterday because I am >>> going to need that on one new project. There's plenty out there that >>> should be directly adressable via MCU. For me it's probably going to be >>> something from the PCM290x series but there's also SPI variants and so >>> on. >>> >>> Anyhow, I am also going to need ADC and comparator, including muxes for >>> them, so this one will likely be a uC case again because otherwise all >>> this has to be added externally. >> >> You do know that it is not hard to add an ADC to an FPGA? No need for a >> mux if all the inputs can be connected to separate pins. It all depends >> on the resolution you need. 8 bits is easy, 16 bits - not so easy. >> > > Mine are never less than 12-bit, often 16-bit. What about delay time? Is sigma-delta ok? >>>>> Last week I reviewed a design with some larger FPGA on there. What I >>>>> found fairly disgusting was how much they had to be babied with the >>>>> power sequencing. uCs don't have that problem. >>>> >>>> If you want to work with the wrong device, then you will find it hard to >>>> work with. There are still single voltage devices on the market. If >>>> this was an old design, most likely it was a Spartan 3 or similar era >>>> device when they (for still unknown reasons) used three, yes, count >>>> them, *three* voltages on the FPGA. The 2.5 volt aux supply was there >>>> solely for the configuration interface which was normally to a 3.3 volt >>>> device! Only from Xilinx... >>>> >>>> If this was a new device, then I guess they picked one based on >>>> something other than ease of use, eh? Don't assume all FPGAs are the >>>> same. >>>> >>> >>> Well, this guy is a real expert on high-end FPGA and the project >>> requires stuff with tons of horsepower. >> >> That's fine, just don't judge all FPGAs by the ones you have seen. If >> the only MCU you had worked with were ARM 11s using 3 Watts and running >> a cell phone down in 8 hours, would you think the PIC MCUs were the same? >> > > Well, give us all here an example of a FPGA that can fully emulate a > TSM320 and costs $3 :-) There are a number of $3 FPGAs. I can't imagine why you would want to emulate a DSP in an FPGA. I would rather design a project using an FPGA. TI likely has a restriction about running their code compiled with their tools in an FPGA softcore. So what is your project? >>>> You are aware that there are Flash based FPGAs that don't require the >>>> external Flash chip, right? >>>> >>> >>> Same with uCs, since a very long time :-) >> >> You are missing my point. >> > > I guess then I don't see your point. Flash is available on almost > everything nowadays. I was comparing FPGAs to FPGAs. Many FPGAs require external Flash, some don't. Just like most DSPs require external flash, most MCUs don't. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-07 12:39 -0700 |
| Message-ID | <b91docF3r46U1@mid.individual.net> |
| In reply to | #13353 |
rickman wrote: > On 9/7/2013 1:59 PM, Joerg wrote: >> rickman wrote: >>> On 9/7/2013 11:10 AM, Joerg wrote: >>>> rickman wrote: >>>>> On 9/6/2013 7:10 PM, Joerg wrote: >>>>>> >>>>>> That is often the problem. Sometimes a buck fifty is the pain >>>>>> threshold. >>>>>> Not in this ATMega case, the 2560 is very expensive but comes with >>>>>> lots >>>>>> of ADC and analog muxes and all that. Things that will cost extra >>>>>> with a >>>>>> FPGA solution and eat real estate. >>>>>> >>>>>> >>>>>> For $3 however, you can get a >>>>>>> chip large enough for a CPU (with math) and room for your special >>>>>>> logic. >>>>>>> >>>>>> >>>>>> For $3 I can get a big DSP. >>>>> >>>>> What "big" DSP can you get for $3? ... >>>> >>>> >>>> For example, this: >>>> >>>> http://www.ti.com/lit/ds/symlink/tms320c5535.pdf >>> >>> I don't see it for $3. Did you get a quote for your project? TI says >>> it is $5 to $8 at qty 1k depending on the flavor. You still need to add >>> Flash. >>> >> >> 1k qty is $3.67 at Digikey: >> >> http://www.digikey.com/product-detail/en/TMS320C5532AZHH10/296-32741-ND/2749713 >> > > Not the same part pal. You're trying to pull a fast one on me? Are we > talking about the TMS320C5535 with "tons" of memory or the TMS320C5532 > with *much* less memory? > It doesn't have the single access RAM but it does have 64k dual access RAM. That's a lot of RAM in embedded. > >> $3.02 with 12wks leadtime at Arrow: >> >> http://components.arrow.com/part/detail/51425505S8988412N7713?region=na >> >> ROM is included. > > ROM is not Flash.. is it? Are you thinking in terms of a mask ROM? > You can use the bootloader or OTP your own bootloader if you don't want to store your programming in ROM. In most situations this is part of a larger computerized system from where it can download its programming. > >>>>> ... It has been a while since I looked >>>>> hard at DSP chips, but I don't recall any I would call remotely "big" >>>>> for $3. The TI chips that would be "big" are the TMS6xxx line which >>>>> start somewhere around $20 the last time I looked and that requires >>>>> all >>>>> memory and I/O to be separate. The smaller DSP chips that you can get >>>>> for the $3 range are not "big" in any sense and only a very few of >>>>> them >>>>> include Flash memory. So you still need another chip. >>>>> >>>> >>>> It has tons of memory on board. >>> >>> Yes, and many FPGAs have "tons" of memory on board although not for >>> $3... but then this isn't a $3 part either... >>> >> >> It is a $3 part. See above. > > No, you need to pick a part number and stick with it. > I gave a part number. Still waiting for your $3 FPGA part number :-) > >>>>> Even a "small" FPGA can run rings around a DSP when it comes to >>>>> performance. Usually "big" in DSPs means fast and when you want >>>>> really >>>>> fast DSP you use an FPGA with all the parallelism you can handle. >>>>> DSPs >>>>> can't touch FPGAs for speed, even with low power. >>>>> >>>> >>>> Most of the really powerful FPGA that I connected to or had to review >>>> designs with them in there were painfully expensive. >>> >>> Because you were looking at FPGAs that were "painfully" large I'm sure. >>> How many pins, 256, 400+...? 20,000 LUTs, 40,000 LUTs? >>> >> >> Sure, that's why I wrote "powerful". The less powerful ones have never >> impressed me much but I have to admit that I haven't looked the last >> five years. So, tell us, which FPGA can fully replace the above DSP for >> three bucks and where could one buy it off the shelf? > > Lol, I don't know where you are coming from now. You don't like the > large FPGAs because they use power like they are... well, large. You > don't like the small FPGAs because they are, well... small. > > When you stop using terms like "powerful" and want to actually consider > an FPGA for a design I can help you. Gut feel is nice as long as it is > based in fact. > So then, what would be an FPGA that can fully contain the above TMS320 and what does it cost? Which one could replace the MSP430F6733 including its ADCs and all, for around $3? http://www.ti.com/lit/ds/symlink/msp430f6720.pdf [...] >>> I can only remember one time where I iterated through design changes in >>> the field and that was actually a case where I could have done it all >>> remotely, but I was pleasing the customer to be there. Turns out he >>> wasn't initializing the design right and it was hard to detect. >>> >> >> Well, if you are standing next to a huge roaring engine and this, that >> and the other subtle disturbance has to be ironed out it would be a >> major problem if the programmer is three time zones away. You don't have >> to believe me but that's how it is with some of my assignments. >> >> Just like EMC jobs on large gear can simply not be done remotely. Which >> is why I bought the Signalhound analyzer (fits into carry-on). > > I don't argue your needs. You keep saying these special jobs are a > small percentage of your work. So most assignments will work just fine > with remote support, no? > Yes, for myself I'd say it's >90%. For firmware and software support, much lower percentage. Currently <50% of cases. Meaning I (or some other folks) and the programmers have to literally work side-by-side. Mostly this simply has to do with the fact that gear is too large to ship and often also because operation by someone not used to it can become dangerous. When pressures are several thousand psi and someone screws up people could die. > >>> One big advantage to FPGAs is the ability to simulate at a low level. it >>> is very easy to emulate the I/O in an HDL simulation. I don't know how >>> they do that with MCUs, but in the FPGA world I've never had a problem. >>> >> >> That is undoubtedly true. Plus probably less in errata headaches. >> >> [...] >> >> >>>>> I've used schematic based tools and both VHDL and Verilog. I've >>>>> worked >>>>> with the vendor's tools and third party tools including the NeoCAD >>>>> tools >>>>> which became Xilinx tools when Xilinx bought them. >>>>> >>>>> If anyone tells you they only know one brand of FPGA you are >>>>> talking to >>>>> an FPGA weenie. I find MCUs to vary a *great* deal more than FPGAs in >>>>> terms of usage. MCUs need all sorts of start up code and peripheral >>>>> drivers, clock control, etc, etc, etc. FPGAs not so much. They >>>>> mostly >>>>> have the same features and most of that can be inferred from the >>>>> HDL so >>>>> you never need to look too hard under the hood. >>>>> >>>>> In short, there is a lot of FUD about FPGAs. Talk to someone who >>>>> doesn't buy into the FUD. >>>>> >>>> >>>> Yeah, maybe next time I need major logic we should talk. But better not >>>> about politics :-) >>> >>> Yeah... Even if you need minor logic let's talk. I find the real >>> advantage to FPGAs is in the fact that I can do almost *anything* in >>> one. I don't need to add stuff unless it is very application specific >>> like the CD quality CODEC on my current production board. I could get >>> CD quality from an FPGA design, but it wouldn't be worth the work to >>> save a $3 part. >>> >> >> So far the next project on the books that will contain logic is 2nd half >> of next year. It will need a 16-bit audio codec as well but we can use >> an external chip for that, PCM29xx series et cetera. Would (probably) >> even keep it external with a uC because the 16-bit ADCs on those aren't >> very quiet. > > Not sure what the requirements are for your CODEC, but I have been using > the AKM parts with good results. Minimal or *no* programming, > configuration is done by a small number of select pins, very simple. I > have yet to find another one as small, AK4552, AK4556. > Plus their prices are quite good. [...] >>> You do know that it is not hard to add an ADC to an FPGA? No need for a >>> mux if all the inputs can be connected to separate pins. It all depends >>> on the resolution you need. 8 bits is easy, 16 bits - not so easy. >>> >> >> Mine are never less than 12-bit, often 16-bit. > > What about delay time? Is sigma-delta ok? > As long as I can get into the tens of ksps. > >>>>>> Last week I reviewed a design with some larger FPGA on there. What I >>>>>> found fairly disgusting was how much they had to be babied with the >>>>>> power sequencing. uCs don't have that problem. >>>>> >>>>> If you want to work with the wrong device, then you will find it >>>>> hard to >>>>> work with. There are still single voltage devices on the market. If >>>>> this was an old design, most likely it was a Spartan 3 or similar era >>>>> device when they (for still unknown reasons) used three, yes, count >>>>> them, *three* voltages on the FPGA. The 2.5 volt aux supply was there >>>>> solely for the configuration interface which was normally to a 3.3 >>>>> volt >>>>> device! Only from Xilinx... >>>>> >>>>> If this was a new device, then I guess they picked one based on >>>>> something other than ease of use, eh? Don't assume all FPGAs are the >>>>> same. >>>>> >>>> >>>> Well, this guy is a real expert on high-end FPGA and the project >>>> requires stuff with tons of horsepower. >>> >>> That's fine, just don't judge all FPGAs by the ones you have seen. If >>> the only MCU you had worked with were ARM 11s using 3 Watts and running >>> a cell phone down in 8 hours, would you think the PIC MCUs were the >>> same? >>> >> >> Well, give us all here an example of a FPGA that can fully emulate a >> TSM320 and costs $3 :-) > > There are a number of $3 FPGAs. I can't imagine why you would want to > emulate a DSP in an FPGA. I would rather design a project using an > FPGA. TI likely has a restriction about running their code compiled > with their tools in an FPGA softcore. So what is your project? > I wasn't referring to a specific project, just your claim that FPGA can do the same job as processors at the same price. One project will probably require something of the caliber of a MSP430F6733. Whether this kind or a DSP, what is key is that we are able to use pre-coooked library routines. In my case for complex (I/Q) signal processing, FFT, non-linear filtering and so on. Sometimes legacy routines must be kept and in an FPGA that would require an IP block that can emulate the respective processor well enough. But what I see most is this: The respective client has in-house talent for writing code. They are familiar with a particular architecture, have a vast arsenal of re-usable code built up, and naturally they do not wish to give this up. If it's a dsPIC like last year, then that goes in there. If it's Atmel and MSP430 like this year, then that is used. Has to be, the customer is king. [...] -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-07 16:44 -0400 |
| Message-ID | <l0g38d$9ad$1@dont-email.me> |
| In reply to | #13355 |
On 9/7/2013 3:39 PM, Joerg wrote: > rickman wrote: >> On 9/7/2013 1:59 PM, Joerg wrote: >>> rickman wrote: >>>> On 9/7/2013 11:10 AM, Joerg wrote: >>>>> rickman wrote: >>>>>> On 9/6/2013 7:10 PM, Joerg wrote: >>>>>>> >>>>>>> That is often the problem. Sometimes a buck fifty is the pain >>>>>>> threshold. >>>>>>> Not in this ATMega case, the 2560 is very expensive but comes with >>>>>>> lots >>>>>>> of ADC and analog muxes and all that. Things that will cost extra >>>>>>> with a >>>>>>> FPGA solution and eat real estate. >>>>>>> >>>>>>> >>>>>>> For $3 however, you can get a >>>>>>>> chip large enough for a CPU (with math) and room for your special >>>>>>>> logic. >>>>>>>> >>>>>>> >>>>>>> For $3 I can get a big DSP. >>>>>> >>>>>> What "big" DSP can you get for $3? ... >>>>> >>>>> >>>>> For example, this: >>>>> >>>>> http://www.ti.com/lit/ds/symlink/tms320c5535.pdf >>>> >>>> I don't see it for $3. Did you get a quote for your project? TI says >>>> it is $5 to $8 at qty 1k depending on the flavor. You still need to add >>>> Flash. >>>> >>> >>> 1k qty is $3.67 at Digikey: >>> >>> http://www.digikey.com/product-detail/en/TMS320C5532AZHH10/296-32741-ND/2749713 >>> >> >> Not the same part pal. You're trying to pull a fast one on me? Are we >> talking about the TMS320C5535 with "tons" of memory or the TMS320C5532 >> with *much* less memory? >> > > It doesn't have the single access RAM but it does have 64k dual access > RAM. That's a lot of RAM in embedded. You do this often. Start talking about one thing and shift the context to another. Projects have design requirements. I often am able to meet my design requirements with an FPGA and no MCU. I often can't say the opposite, being able to use an MCU without the FPGA. >>> $3.02 with 12wks leadtime at Arrow: >>> >>> http://components.arrow.com/part/detail/51425505S8988412N7713?region=na >>> >>> ROM is included. >> >> ROM is not Flash.. is it? Are you thinking in terms of a mask ROM? >> > > You can use the bootloader or OTP your own bootloader if you don't want > to store your programming in ROM. In most situations this is part of a > larger computerized system from where it can download its programming. That's a different wrinkle. It is common to have a micro load an FPGA, many don't contain their own Flash. But I haven't seen this done with DSPs as often and almost never with MCUs. But if that works for your project, great. You certainly wouldn't have a problem loading an FPGA then. >>>>>> ... It has been a while since I looked >>>>>> hard at DSP chips, but I don't recall any I would call remotely "big" >>>>>> for $3. The TI chips that would be "big" are the TMS6xxx line which >>>>>> start somewhere around $20 the last time I looked and that requires >>>>>> all >>>>>> memory and I/O to be separate. The smaller DSP chips that you can get >>>>>> for the $3 range are not "big" in any sense and only a very few of >>>>>> them >>>>>> include Flash memory. So you still need another chip. >>>>>> >>>>> >>>>> It has tons of memory on board. >>>> >>>> Yes, and many FPGAs have "tons" of memory on board although not for >>>> $3... but then this isn't a $3 part either... >>>> >>> >>> It is a $3 part. See above. >> >> No, you need to pick a part number and stick with it. >> > > I gave a part number. Still waiting for your $3 FPGA part number :-) Actually you gave me two part numbers, one for $5 and one for just over $3. What's your point? I gave you info to find the iCE40 line. Xilinx also makes FPGAs that are very affordable and does Altera and Lattice. >>>>>> Even a "small" FPGA can run rings around a DSP when it comes to >>>>>> performance. Usually "big" in DSPs means fast and when you want >>>>>> really >>>>>> fast DSP you use an FPGA with all the parallelism you can handle. >>>>>> DSPs >>>>>> can't touch FPGAs for speed, even with low power. >>>>>> >>>>> >>>>> Most of the really powerful FPGA that I connected to or had to review >>>>> designs with them in there were painfully expensive. >>>> >>>> Because you were looking at FPGAs that were "painfully" large I'm sure. >>>> How many pins, 256, 400+...? 20,000 LUTs, 40,000 LUTs? >>>> >>> >>> Sure, that's why I wrote "powerful". The less powerful ones have never >>> impressed me much but I have to admit that I haven't looked the last >>> five years. So, tell us, which FPGA can fully replace the above DSP for >>> three bucks and where could one buy it off the shelf? >> >> Lol, I don't know where you are coming from now. You don't like the >> large FPGAs because they use power like they are... well, large. You >> don't like the small FPGAs because they are, well... small. >> >> When you stop using terms like "powerful" and want to actually consider >> an FPGA for a design I can help you. Gut feel is nice as long as it is >> based in fact. >> > > So then, what would be an FPGA that can fully contain the above TMS320 > and what does it cost? > > Which one could replace the MSP430F6733 including its ADCs and all, for > around $3? > > http://www.ti.com/lit/ds/symlink/msp430f6720.pdf I have already explained that I would never do a design in an FPGA to wholly incorporate a DSP or MCU. That would be absurd. So why do you keep asking about that? Depending on your design requirements there are any number of FPGAs that will do the job and some may be $3. What are your design requirements? >>>> I can only remember one time where I iterated through design changes in >>>> the field and that was actually a case where I could have done it all >>>> remotely, but I was pleasing the customer to be there. Turns out he >>>> wasn't initializing the design right and it was hard to detect. >>>> >>> >>> Well, if you are standing next to a huge roaring engine and this, that >>> and the other subtle disturbance has to be ironed out it would be a >>> major problem if the programmer is three time zones away. You don't have >>> to believe me but that's how it is with some of my assignments. >>> >>> Just like EMC jobs on large gear can simply not be done remotely. Which >>> is why I bought the Signalhound analyzer (fits into carry-on). >> >> I don't argue your needs. You keep saying these special jobs are a >> small percentage of your work. So most assignments will work just fine >> with remote support, no? >> > > Yes, for myself I'd say it's>90%. For firmware and software support, > much lower percentage. Currently<50% of cases. Meaning I (or some other > folks) and the programmers have to literally work side-by-side. > > Mostly this simply has to do with the fact that gear is too large to > ship and often also because operation by someone not used to it can > become dangerous. When pressures are several thousand psi and someone > screws up people could die. I understand the concept of work that can't be moved. You don't need to continue to explain that. I was asking why you said most of your word didn't have that requirement and yet you still were debating the point. Now I get it, you are talking about two different things, work that can be moved and work that can't be moved. >>>> One big advantage to FPGAs is the ability to simulate at a low level. it >>>> is very easy to emulate the I/O in an HDL simulation. I don't know how >>>> they do that with MCUs, but in the FPGA world I've never had a problem. >>>> >>> >>> That is undoubtedly true. Plus probably less in errata headaches. >>> >>> [...] >>> >>> >>>>>> I've used schematic based tools and both VHDL and Verilog. I've >>>>>> worked >>>>>> with the vendor's tools and third party tools including the NeoCAD >>>>>> tools >>>>>> which became Xilinx tools when Xilinx bought them. >>>>>> >>>>>> If anyone tells you they only know one brand of FPGA you are >>>>>> talking to >>>>>> an FPGA weenie. I find MCUs to vary a *great* deal more than FPGAs in >>>>>> terms of usage. MCUs need all sorts of start up code and peripheral >>>>>> drivers, clock control, etc, etc, etc. FPGAs not so much. They >>>>>> mostly >>>>>> have the same features and most of that can be inferred from the >>>>>> HDL so >>>>>> you never need to look too hard under the hood. >>>>>> >>>>>> In short, there is a lot of FUD about FPGAs. Talk to someone who >>>>>> doesn't buy into the FUD. >>>>>> >>>>> >>>>> Yeah, maybe next time I need major logic we should talk. But better not >>>>> about politics :-) >>>> >>>> Yeah... Even if you need minor logic let's talk. I find the real >>>> advantage to FPGAs is in the fact that I can do almost *anything* in >>>> one. I don't need to add stuff unless it is very application specific >>>> like the CD quality CODEC on my current production board. I could get >>>> CD quality from an FPGA design, but it wouldn't be worth the work to >>>> save a $3 part. >>>> >>> >>> So far the next project on the books that will contain logic is 2nd half >>> of next year. It will need a 16-bit audio codec as well but we can use >>> an external chip for that, PCM29xx series et cetera. Would (probably) >>> even keep it external with a uC because the 16-bit ADCs on those aren't >>> very quiet. >> >> Not sure what the requirements are for your CODEC, but I have been using >> the AKM parts with good results. Minimal or *no* programming, >> configuration is done by a small number of select pins, very simple. I >> have yet to find another one as small, AK4552, AK4556. >> > > Plus their prices are quite good. Which, AKM or the other? I'd like to think I can get a CD quality CODEC for $3 from nearly anyone. I mainly picked AKM because of the size, 6x6 mm without going to a microBGA. >>>> You do know that it is not hard to add an ADC to an FPGA? No need for a >>>> mux if all the inputs can be connected to separate pins. It all depends >>>> on the resolution you need. 8 bits is easy, 16 bits - not so easy. >>>> >>> >>> Mine are never less than 12-bit, often 16-bit. >> >> What about delay time? Is sigma-delta ok? >> > > As long as I can get into the tens of ksps. High 10's or low 10's. Up to say, 20 or 30 ksps is easy to do in an FPGA with decent resolution, 12 bits. Getting 16 bits is harder, I've not tried it, but should be possible. I was looking at using a LVDS input for a comparator and Xilinx did it in a demo of a SDR. They are very short on details, but they talk about 1 mV on the input. I know that's not anything special, I'm hoping to do better, much better. >>>>>>> Last week I reviewed a design with some larger FPGA on there. What I >>>>>>> found fairly disgusting was how much they had to be babied with the >>>>>>> power sequencing. uCs don't have that problem. >>>>>> >>>>>> If you want to work with the wrong device, then you will find it >>>>>> hard to >>>>>> work with. There are still single voltage devices on the market. If >>>>>> this was an old design, most likely it was a Spartan 3 or similar era >>>>>> device when they (for still unknown reasons) used three, yes, count >>>>>> them, *three* voltages on the FPGA. The 2.5 volt aux supply was there >>>>>> solely for the configuration interface which was normally to a 3.3 >>>>>> volt >>>>>> device! Only from Xilinx... >>>>>> >>>>>> If this was a new device, then I guess they picked one based on >>>>>> something other than ease of use, eh? Don't assume all FPGAs are the >>>>>> same. >>>>>> >>>>> >>>>> Well, this guy is a real expert on high-end FPGA and the project >>>>> requires stuff with tons of horsepower. >>>> >>>> That's fine, just don't judge all FPGAs by the ones you have seen. If >>>> the only MCU you had worked with were ARM 11s using 3 Watts and running >>>> a cell phone down in 8 hours, would you think the PIC MCUs were the >>>> same? >>>> >>> >>> Well, give us all here an example of a FPGA that can fully emulate a >>> TSM320 and costs $3 :-) >> >> There are a number of $3 FPGAs. I can't imagine why you would want to >> emulate a DSP in an FPGA. I would rather design a project using an >> FPGA. TI likely has a restriction about running their code compiled >> with their tools in an FPGA softcore. So what is your project? >> > > I wasn't referring to a specific project, just your claim that FPGA can > do the same job as processors at the same price. Yes, that is my claim. The obvious exception is when some feature is needed that just isn't available in an FPGA. I'm not saying *every* project can be done better in an FPGA. I'm saying that designers tend to just not consider FPGAs when they are often viable solutions. > One project will probably require something of the caliber of a > MSP430F6733. Whether this kind or a DSP, what is key is that we are able > to use pre-coooked library routines. In my case for complex (I/Q) signal > processing, FFT, non-linear filtering and so on. Sometimes legacy > routines must be kept and in an FPGA that would require an IP block that > can emulate the respective processor well enough. Ok, that is likely a no-go. If you really want to emulate a DSP chip then an FPGA is not likely to be a useful way to proceed. Wanting to run DSP precompiled library code is a bit of an extreme requirement. If the customer wants a DSP, then by all means give them a DSP. But don't automatically exclude an FPGA from the task. > But what I see most is this: The respective client has in-house talent > for writing code. They are familiar with a particular architecture, have > a vast arsenal of re-usable code built up, and naturally they do not > wish to give this up. If it's a dsPIC like last year, then that goes in > there. If it's Atmel and MSP430 like this year, then that is used. Has > to be, the customer is king. Yeah, well that is a deal killer for *any* other alternative. That is not related to what I was saying. My point is that if you don't have any specific requirement that dictates the use of a given chip, an FPGA has as good a chance at meeting the requirements as an MCU or DSP. In fact, FPGAs are what get used when DSPs aren't fast enough. My point is you don't have to limit them to the high end. They also do very well at the low end. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-07 14:48 -0700 |
| Message-ID | <b91lacF5bvnU1@mid.individual.net> |
| In reply to | #13359 |
rickman wrote: > On 9/7/2013 3:39 PM, Joerg wrote: >> rickman wrote: >>> On 9/7/2013 1:59 PM, Joerg wrote: >>>> rickman wrote: >>>>> On 9/7/2013 11:10 AM, Joerg wrote: >>>>>> rickman wrote: >>>>>>> On 9/6/2013 7:10 PM, Joerg wrote: >>>>>>>> >>>>>>>> That is often the problem. Sometimes a buck fifty is the pain >>>>>>>> threshold. >>>>>>>> Not in this ATMega case, the 2560 is very expensive but comes with >>>>>>>> lots >>>>>>>> of ADC and analog muxes and all that. Things that will cost extra >>>>>>>> with a >>>>>>>> FPGA solution and eat real estate. >>>>>>>> >>>>>>>> >>>>>>>> For $3 however, you can get a >>>>>>>>> chip large enough for a CPU (with math) and room for your special >>>>>>>>> logic. >>>>>>>>> >>>>>>>> >>>>>>>> For $3 I can get a big DSP. >>>>>>> >>>>>>> What "big" DSP can you get for $3? ... >>>>>> >>>>>> >>>>>> For example, this: >>>>>> >>>>>> http://www.ti.com/lit/ds/symlink/tms320c5535.pdf >>>>> >>>>> I don't see it for $3. Did you get a quote for your project? TI says >>>>> it is $5 to $8 at qty 1k depending on the flavor. You still need >>>>> to add >>>>> Flash. >>>>> >>>> >>>> 1k qty is $3.67 at Digikey: >>>> >>>> http://www.digikey.com/product-detail/en/TMS320C5532AZHH10/296-32741-ND/2749713 >>>> >>>> >>> >>> Not the same part pal. You're trying to pull a fast one on me? Are we >>> talking about the TMS320C5535 with "tons" of memory or the TMS320C5532 >>> with *much* less memory? >>> >> >> It doesn't have the single access RAM but it does have 64k dual access >> RAM. That's a lot of RAM in embedded. > > You do this often. Start talking about one thing and shift the context > to another. ... I didn't. I said it is a DSP with large memory, which it is. > ... Projects have design requirements. I often am able to meet > my design requirements with an FPGA and no MCU. I often can't say the > opposite, being able to use an MCU without the FPGA. > > >>>> $3.02 with 12wks leadtime at Arrow: >>>> >>>> http://components.arrow.com/part/detail/51425505S8988412N7713?region=na >>>> >>>> ROM is included. >>> >>> ROM is not Flash.. is it? Are you thinking in terms of a mask ROM? >>> >> >> You can use the bootloader or OTP your own bootloader if you don't want >> to store your programming in ROM. In most situations this is part of a >> larger computerized system from where it can download its programming. > > That's a different wrinkle. It is common to have a micro load an FPGA, > many don't contain their own Flash. But I haven't seen this done with > DSPs as often and almost never with MCUs. But if that works for your > project, great. You certainly wouldn't have a problem loading an FPGA > then. > The fact that most FPGA don't have flash is fine ... but ... there must be a decent bootloader inside. In one of the upcoming projects it must be able to bootload via USB. So the device must wake up with a certain minimum in brain functionality to handle the USB stuff. With FPGA that can become a challenge unless you provide a serial memory device (which adds cost). > >>>>>>> ... It has been a while since I looked >>>>>>> hard at DSP chips, but I don't recall any I would call remotely >>>>>>> "big" >>>>>>> for $3. The TI chips that would be "big" are the TMS6xxx line which >>>>>>> start somewhere around $20 the last time I looked and that requires >>>>>>> all >>>>>>> memory and I/O to be separate. The smaller DSP chips that you >>>>>>> can get >>>>>>> for the $3 range are not "big" in any sense and only a very few of >>>>>>> them >>>>>>> include Flash memory. So you still need another chip. >>>>>>> >>>>>> >>>>>> It has tons of memory on board. >>>>> >>>>> Yes, and many FPGAs have "tons" of memory on board although not for >>>>> $3... but then this isn't a $3 part either... >>>>> >>>> >>>> It is a $3 part. See above. >>> >>> No, you need to pick a part number and stick with it. >>> >> >> I gave a part number. Still waiting for your $3 FPGA part number :-) > > Actually you gave me two part numbers, one for $5 and one for just over > $3. What's your point? I gave you info to find the iCE40 line. Xilinx > also makes FPGAs that are very affordable and does Altera and Lattice. > Both of the ones I gave you are $3. The DSP costs $3.02 and the MSP430 is $3.09. These are over-the-counter no-haggle prices. Can a $3 iCE40 device emulate a TMS320 or a big MSP430? I can't tell because I don't know this Lattice series and I am not an FPGA expert. But it sure looks like they'd have a hard time. > >>>>>>> Even a "small" FPGA can run rings around a DSP when it comes to >>>>>>> performance. Usually "big" in DSPs means fast and when you want >>>>>>> really >>>>>>> fast DSP you use an FPGA with all the parallelism you can handle. >>>>>>> DSPs >>>>>>> can't touch FPGAs for speed, even with low power. >>>>>>> >>>>>> >>>>>> Most of the really powerful FPGA that I connected to or had to review >>>>>> designs with them in there were painfully expensive. >>>>> >>>>> Because you were looking at FPGAs that were "painfully" large I'm >>>>> sure. >>>>> How many pins, 256, 400+...? 20,000 LUTs, 40,000 LUTs? >>>>> >>>> >>>> Sure, that's why I wrote "powerful". The less powerful ones have never >>>> impressed me much but I have to admit that I haven't looked the last >>>> five years. So, tell us, which FPGA can fully replace the above DSP for >>>> three bucks and where could one buy it off the shelf? >>> >>> Lol, I don't know where you are coming from now. You don't like the >>> large FPGAs because they use power like they are... well, large. You >>> don't like the small FPGAs because they are, well... small. >>> >>> When you stop using terms like "powerful" and want to actually consider >>> an FPGA for a design I can help you. Gut feel is nice as long as it is >>> based in fact. >>> >> >> So then, what would be an FPGA that can fully contain the above TMS320 >> and what does it cost? >> >> Which one could replace the MSP430F6733 including its ADCs and all, for >> around $3? >> >> http://www.ti.com/lit/ds/symlink/msp430f6720.pdf > > I have already explained that I would never do a design in an FPGA to > wholly incorporate a DSP or MCU. That would be absurd. So why do you > keep asking about that? > Because you wrote yesterday, quote "For $3 however, you can get a chip large enough for a CPU (with math) and room for your special logic". > Depending on your design requirements there are any number of FPGAs that > will do the job and some may be $3. What are your design requirements? > As I said, I do not have any hammered out ones yet but it'll come. This was just about you $3 claim. So I gave some examples of devices that cost $3. > >>>>> I can only remember one time where I iterated through design >>>>> changes in >>>>> the field and that was actually a case where I could have done it all >>>>> remotely, but I was pleasing the customer to be there. Turns out he >>>>> wasn't initializing the design right and it was hard to detect. >>>>> >>>> >>>> Well, if you are standing next to a huge roaring engine and this, that >>>> and the other subtle disturbance has to be ironed out it would be a >>>> major problem if the programmer is three time zones away. You don't >>>> have >>>> to believe me but that's how it is with some of my assignments. >>>> >>>> Just like EMC jobs on large gear can simply not be done remotely. Which >>>> is why I bought the Signalhound analyzer (fits into carry-on). >>> >>> I don't argue your needs. You keep saying these special jobs are a >>> small percentage of your work. So most assignments will work just fine >>> with remote support, no? >>> >> >> Yes, for myself I'd say it's>90%. For firmware and software support, >> much lower percentage. Currently<50% of cases. Meaning I (or some other >> folks) and the programmers have to literally work side-by-side. >> >> Mostly this simply has to do with the fact that gear is too large to >> ship and often also because operation by someone not used to it can >> become dangerous. When pressures are several thousand psi and someone >> screws up people could die. > > I understand the concept of work that can't be moved. You don't need to > continue to explain that. I was asking why you said most of your word > didn't have that requirement and yet you still were debating the point. > Now I get it, you are talking about two different things, work that can > be moved and work that can't be moved. > Yup. Hence the need for availability of local programmer talent. Less local availability means potential problems. That is because (where possible) I like to use architectures I am familiar with. Programmer talent means longterm. For example, if a client has an issue with an 8051 design long after the original programmer has moved on I could find programmers within a 10-mile radius. Try that with an FPGA. In San Jose it may be possible but not out here. [...] >>> Not sure what the requirements are for your CODEC, but I have been using >>> the AKM parts with good results. Minimal or *no* programming, >>> configuration is done by a small number of select pins, very simple. I >>> have yet to find another one as small, AK4552, AK4556. >>> >> >> Plus their prices are quite good. > > Which, AKM or the other? I'd like to think I can get a CD quality CODEC > for $3 from nearly anyone. I mainly picked AKM because of the size, 6x6 > mm without going to a microBGA. > AKM has good prices. > >>>>> You do know that it is not hard to add an ADC to an FPGA? No need >>>>> for a >>>>> mux if all the inputs can be connected to separate pins. It all >>>>> depends >>>>> on the resolution you need. 8 bits is easy, 16 bits - not so easy. >>>>> >>>> >>>> Mine are never less than 12-bit, often 16-bit. >>> >>> What about delay time? Is sigma-delta ok? >>> >> >> As long as I can get into the tens of ksps. > > High 10's or low 10's. Up to say, 20 or 30 ksps is easy to do in an > FPGA with decent resolution, 12 bits. Getting 16 bits is harder, I've > not tried it, but should be possible. > Mostly I need 40-50ksps. But 20 is often ok. > I was looking at using a LVDS input for a comparator and Xilinx did it > in a demo of a SDR. They are very short on details, but they talk about > 1 mV on the input. I know that's not anything special, I'm hoping to do > better, much better. > If you can keep substrate noise in check it could work. Try to remain fully differential as much as you can. Not sure if FPGA design suites still let you hand-place blocks so you can avoid making a big racket right next to the ADC area. > >>>>>>>> Last week I reviewed a design with some larger FPGA on there. >>>>>>>> What I >>>>>>>> found fairly disgusting was how much they had to be babied with the >>>>>>>> power sequencing. uCs don't have that problem. >>>>>>> >>>>>>> If you want to work with the wrong device, then you will find it >>>>>>> hard to >>>>>>> work with. There are still single voltage devices on the >>>>>>> market. If >>>>>>> this was an old design, most likely it was a Spartan 3 or similar >>>>>>> era >>>>>>> device when they (for still unknown reasons) used three, yes, count >>>>>>> them, *three* voltages on the FPGA. The 2.5 volt aux supply was >>>>>>> there >>>>>>> solely for the configuration interface which was normally to a 3.3 >>>>>>> volt >>>>>>> device! Only from Xilinx... >>>>>>> >>>>>>> If this was a new device, then I guess they picked one based on >>>>>>> something other than ease of use, eh? Don't assume all FPGAs are >>>>>>> the >>>>>>> same. >>>>>>> >>>>>> >>>>>> Well, this guy is a real expert on high-end FPGA and the project >>>>>> requires stuff with tons of horsepower. >>>>> >>>>> That's fine, just don't judge all FPGAs by the ones you have seen. If >>>>> the only MCU you had worked with were ARM 11s using 3 Watts and >>>>> running >>>>> a cell phone down in 8 hours, would you think the PIC MCUs were the >>>>> same? >>>>> >>>> >>>> Well, give us all here an example of a FPGA that can fully emulate a >>>> TSM320 and costs $3 :-) >>> >>> There are a number of $3 FPGAs. I can't imagine why you would want to >>> emulate a DSP in an FPGA. I would rather design a project using an >>> FPGA. TI likely has a restriction about running their code compiled >>> with their tools in an FPGA softcore. So what is your project? >>> >> >> I wasn't referring to a specific project, just your claim that FPGA can >> do the same job as processors at the same price. > > Yes, that is my claim. The obvious exception is when some feature is > needed that just isn't available in an FPGA. I'm not saying *every* > project can be done better in an FPGA. I'm saying that designers tend > to just not consider FPGAs when they are often viable solutions. > In most of my apps I need much of the functionality that a decent uC affords, like the $3 device from the MSP430 series I mentioned. > >> One project will probably require something of the caliber of a >> MSP430F6733. Whether this kind or a DSP, what is key is that we are able >> to use pre-coooked library routines. In my case for complex (I/Q) signal >> processing, FFT, non-linear filtering and so on. Sometimes legacy >> routines must be kept and in an FPGA that would require an IP block that >> can emulate the respective processor well enough. > > Ok, that is likely a no-go. If you really want to emulate a DSP chip > then an FPGA is not likely to be a useful way to proceed. Wanting to > run DSP precompiled library code is a bit of an extreme requirement. If > the customer wants a DSP, then by all means give them a DSP. But don't > automatically exclude an FPGA from the task. > Sometimes it would also be ok if there were similar pre-cooked FPGA routines (I/Q signal processing, non-linear filters et cetera). > >> But what I see most is this: The respective client has in-house talent >> for writing code. They are familiar with a particular architecture, have >> a vast arsenal of re-usable code built up, and naturally they do not >> wish to give this up. If it's a dsPIC like last year, then that goes in >> there. If it's Atmel and MSP430 like this year, then that is used. Has >> to be, the customer is king. > > Yeah, well that is a deal killer for *any* other alternative. That is > not related to what I was saying. My point is that if you don't have > any specific requirement that dictates the use of a given chip, an FPGA > has as good a chance at meeting the requirements as an MCU or DSP. In > fact, FPGAs are what get used when DSPs aren't fast enough. My point is > you don't have to limit them to the high end. They also do very well at > the low end. > No disagreement there, programables have come a long way since the days of GALs. Which I never used because they were expensive power guzzlers. One other challenge that needs to be met in most of my cases is longevity of the design. A FPGA would have to remain available for more than just a few years. For example, one of my uC-based designs from the mid 90's is still in production. Since I kind of had a hunch that this would happen I used an 8051 family uC. Is there something similar in the world of FPGA? -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | "Tim Williams" <tmoranwms@charter.net> |
|---|---|
| Date | 2013-09-07 17:10 -0500 |
| Message-ID | <l0g86a$8mr$1@dont-email.me> |
| In reply to | #13364 |
"Joerg" <invalid@invalid.invalid> wrote in message news:b91lacF5bvnU1@mid.individual.net... > One other challenge that needs to be met in most of my cases is > longevity of the design. A FPGA would have to remain available for more > than just a few years. For example, one of my uC-based designs from the > mid 90's is still in production. Since I kind of had a hunch that this > would happen I used an 8051 family uC. Is there something similar in the > world of FPGA? Interjecting what little experience I have here; MAX7000s are still available, and they were introduced in 1995; http://www.altera.com/devices/cpld/max-about/max-about.html although I think they've finally gone out of stock (not that you'd want to use them, they also guzzle power like they're NMOS). FLEX 10K FPGAs don't appear on their website, but they're still quite available. Can't seem to find when they were introduced? I'm seeing documents since at least 1996 referencing them. At least between the big two (Altera that I know of, and I would assume Xilinx too), FPGAs look to have excellent support over time. And VHDL doesn't age. The library blocks might, but I'd be willing to guess that those are synthesized as well, so as long as your toolchain supports whatever code format, you can migrate chips easily when they do finally die. And really, if you have to support something for over 20 years, it's probably time it does die and gets a redesign. Like that VAX or whatever it was NASA's still supporting. Tim -- Deep Friar: a very philosophical monk. Website: http://seventransistorlabs.com
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web