Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #46348 > unrolled thread
| Started by | rickman <gnuarm@gmail.com> |
|---|---|
| First post | 2016-03-30 21:39 -0400 |
| Last post | 2016-03-31 23:23 -0700 |
| Articles | 20 on this page of 119 — 10 participants |
Back to article view | Back to comp.lang.forth
New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-03-30 21:39 -0400
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-03-30 18:52 -0700
Re: New "Forth" MCU Board, ChipStick visualforth@rocketmail.com - 2016-03-30 20:31 -0700
Re: New "Forth" MCU Board, ChipStick JUERGEN <epldfpga@aol.com> - 2016-03-30 23:41 -0700
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-03-31 00:37 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-03-31 14:36 -0400
Re: New "Forth" MCU Board, ChipStick JUERGEN <epldfpga@aol.com> - 2016-04-01 00:42 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-04-01 13:09 -0400
Re: New "Forth" MCU Board, ChipStick Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-01 23:43 +0000
Re: New "Forth" MCU Board, ChipStick visualforth@rocketmail.com - 2016-04-01 17:28 -0700
Re: New "Forth" MCU Board, ChipStick Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-02 12:10 +0000
Re: New "Forth" MCU Board, ChipStick David Schultz <abuse@127.0.0.1> - 2016-03-31 17:07 -0500
Re: New "Forth" MCU Board, ChipStick Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-31 23:59 +0000
Re: New "Forth" MCU Board, ChipStick JUERGEN <epldfpga@aol.com> - 2016-04-01 00:52 -0700
Re: New "Forth" MCU Board, ChipStick David Schultz <abuse@127.0.0.1> - 2016-04-01 12:47 -0500
Re: New "Forth" MCU Board, ChipStick visualforth@rocketmail.com - 2016-03-31 18:54 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-03-31 22:08 -0400
Re: New "Forth" MCU Board, ChipStick visualforth@rocketmail.com - 2016-03-31 19:36 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-03-31 23:28 -0400
Re: New "Forth" MCU Board, ChipStick visualforth@rocketmail.com - 2016-03-31 22:32 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-04-01 02:39 -0400
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-01 04:42 -0700
Re: New "Forth" MCU Board, ChipStick josv@planet.nl - 2016-04-01 04:48 -0700
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-01 05:50 -0700
Re: New "Forth" MCU Board, ChipStick anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-01 13:35 +0000
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-04-01 13:11 -0400
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-02 01:58 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-04-02 10:15 -0400
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-02 08:02 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-04-02 12:39 -0400
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-04-02 12:54 -0400
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-04-02 15:14 -0700
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-02 22:14 -0700
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-04-02 23:08 -0700
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-03 02:11 -0700
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-04-03 22:54 -0700
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-04 02:50 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-04-04 16:37 -0400
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-04 23:15 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-04-05 02:21 -0400
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-05 00:01 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-04-05 03:17 -0400
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-05 01:15 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-04-05 12:50 -0400
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-04-04 23:21 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-04-05 02:29 -0400
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-05 00:02 -0700
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-04-05 02:07 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-04-05 13:12 -0400
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-05 00:12 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-04-05 03:22 -0400
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-05 01:22 -0700
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-04-05 02:12 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-04-05 13:15 -0400
Re: New "Forth" MCU Board, ChipStick David Schultz <abuse@127.0.0.1> - 2016-04-05 17:14 -0500
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-04 03:03 -0700
Re: New "Forth" MCU Board, ChipStick visualforth@rocketmail.com - 2016-04-04 19:51 -0700
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-04-04 20:18 -0700
Re: New "Forth" MCU Board, ChipStick visualforth@rocketmail.com - 2016-04-04 20:44 -0700
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-04-04 22:39 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-04-05 02:25 -0400
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-04-04 16:23 -0400
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-04 23:18 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-04-05 13:22 -0400
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-04-05 13:34 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-04-05 21:28 -0400
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-05 22:34 -0700
Re: New "Forth" MCU Board, ChipStick visualforth@rocketmail.com - 2016-04-01 15:52 -0700
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-02 01:55 -0700
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-05-04 22:38 -0700
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-05-04 23:10 -0700
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-05-05 16:28 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-05-05 22:35 -0400
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-05-05 21:40 -0700
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-05-05 22:13 -0700
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-05-05 22:44 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-05-06 02:41 -0400
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-05-06 01:26 -0700
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-05-06 02:02 -0700
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-05-06 09:06 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-05-06 05:09 -0400
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-05-06 03:50 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-05-06 19:23 -0400
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-05-06 16:29 -0700
Re: New "Forth" MCU Board, ChipStick Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-07 11:32 +0000
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-05-07 15:38 -0400
Re: New "Forth" MCU Board, ChipStick Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-08 09:45 +0000
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-05-08 11:04 -0400
Re: New "Forth" MCU Board, ChipStick Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-08 17:36 +0000
Re: New "Forth" MCU Board, ChipStick Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-08 17:39 +0000
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-05-08 14:08 -0400
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-05-08 10:52 -0700
Re: New "Forth" MCU Board, ChipStick David Schultz <abuse@127.0.0.1> - 2016-05-08 14:57 -0500
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-05-08 13:23 -0700
Re: New "Forth" MCU Board, ChipStick Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-09 09:26 +0000
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-05-09 10:26 -0400
Re: New "Forth" MCU Board, ChipStick Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-05-09 09:38 -0700
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-05-09 12:58 -0400
Re: New "Forth" MCU Board, ChipStick Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-09 22:53 +0000
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-05-09 22:41 -0400
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-05-09 11:08 -0700
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-05-09 13:21 -0700
Re: New "Forth" MCU Board, ChipStick Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-09 23:39 +0000
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-05-09 19:03 -0700
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-05-09 21:44 -0700
Re: New "Forth" MCU Board, ChipStick Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-10 08:28 +0000
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-05-10 12:34 -0400
Re: New "Forth" MCU Board, ChipStick Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-10 22:27 +0000
Re: New "Forth" MCU Board, ChipStick Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-09 09:16 +0000
Re: New "Forth" MCU Board, ChipStick rickman <gnuarm@gmail.com> - 2016-05-08 14:01 -0400
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-03-31 23:26 -0700
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-03-31 19:09 -0700
Re: New "Forth" MCU Board, ChipStick David Schultz <abuse@127.0.0.1> - 2016-03-31 21:41 -0500
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-03-31 23:10 -0700
Re: New "Forth" MCU Board, ChipStick David Schultz <abuse@127.0.0.1> - 2016-04-01 12:37 -0500
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-04-01 15:35 -0700
Re: New "Forth" MCU Board, ChipStick David Schultz <abuse@127.0.0.1> - 2016-04-01 18:11 -0500
Re: New "Forth" MCU Board, ChipStick visualforth@rocketmail.com - 2016-03-31 19:47 -0700
Re: New "Forth" MCU Board, ChipStick Paul Rubin <no.email@nospam.invalid> - 2016-03-31 23:23 -0700
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-06 05:09 -0400 |
| Message-ID | <nghmpo$bth$1@dont-email.me> |
| In reply to | #46929 |
On 5/6/2016 4:26 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> Maybe I missed something. Why is powering from a LiPo cell assumed? > > It says right in the blurb that you can power it from USB or a lipo > cell. Lipo is obviously one of the intended power sources. So? It can be powered from *any* source that meets the voltage requirement. If they didn't include any circuitry unique to a LiPo cell, this board is no different from any other board that has a regulator on board. Do any of the other boards say you *can't* use a LiPo cell to power it? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2016-05-06 03:50 -0700 |
| Message-ID | <d861399b-bead-4abf-a8aa-c9c289776a26@googlegroups.com> |
| In reply to | #46932 |
vineri, 6 mai 2016, 12:09:31 UTC+3, rickman a scris: > On 5/6/2016 4:26 AM, Paul Rubin wrote: > > rickman <gnuarm@gmail.com> writes: > >> Maybe I missed something. Why is powering from a LiPo cell assumed? > > > > It says right in the blurb that you can power it from USB or a lipo > > cell. Lipo is obviously one of the intended power sources. > > So? It can be powered from *any* source that meets the voltage > requirement. If they didn't include any circuitry unique to a LiPo > cell, this board is no different from any other board that has a > regulator on board. Do any of the other boards say you *can't* use a > LiPo cell to power it? > > -- > > Rick C Rick, you argue with the wrong guy :D Tell this to the board manufacturer. Paul Rubin basically said that given the spec (a lipo input) it would have been nice to have a charger.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-06 19:23 -0400 |
| Message-ID | <ngj8rh$2a2$1@dont-email.me> |
| In reply to | #46933 |
On 5/6/2016 6:50 AM, Raimond Dragomir wrote: > vineri, 6 mai 2016, 12:09:31 UTC+3, rickman a scris: >> On 5/6/2016 4:26 AM, Paul Rubin wrote: >>> rickman <gnuarm@gmail.com> writes: >>>> Maybe I missed something. Why is powering from a LiPo cell assumed? >>> >>> It says right in the blurb that you can power it from USB or a lipo >>> cell. Lipo is obviously one of the intended power sources. >> >> So? It can be powered from *any* source that meets the voltage >> requirement. If they didn't include any circuitry unique to a LiPo >> cell, this board is no different from any other board that has a >> regulator on board. Do any of the other boards say you *can't* use a >> LiPo cell to power it? >> >> -- >> >> Rick C > > Rick, you argue with the wrong guy :D > Tell this to the board manufacturer. > Paul Rubin basically said that given the spec (a lipo input) it would > have been nice to have a charger. And my point is there are *many* things that would be nice to have, but easy to add separately. The fact that the board is stated to work with a Lipo cell doesn't imply it is lacking if it doesn't charge the cell. Power management is a complicated and many pronged aspect of MCUs. Why limit an MCU board by building it in? If you really need that it is easy enough to spin one with the features you need at a low cost these days. That's why we see so may MCU boards out there, some with nothing on them but the absolute minimum. Those are the ones that are sold a lot. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-06 16:29 -0700 |
| Message-ID | <877ff6bwa4.fsf@nightsong.com> |
| In reply to | #46961 |
rickman <gnuarm@gmail.com> writes: > That's why we see so may MCU boards out there, some with nothing on > them but the absolute minimum. Those are the ones that are sold a > lot. The minimalistic ones sell a lot because they're cheap. This one is expensive and rather maximalistic. The purpose of the maximalism, as mentioned, is to get rid of extra boards. If your device is going to need a charger anyway, then that's an obvious extra board to get rid of. It's possible that the designer intended for the user to disconnect the battery for charging--the supercap backing up the RTC would seem to help that. The Adafruit Feathers all have chargers, so it's obviously considered a useful feature by someone. I think there's a level of maker courtesy to not copy each others' features too much, so that might be part of what's going on here. I can respect it if that's the case. For my own purposes I don't care about the SPI flash that much, but I do care about the RTC, which is a separate board for the Feathers. There's also currently no Cortex M4 Feather, just some M0's and some Atmegas.
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-05-07 11:32 +0000 |
| Message-ID | <slrnniro3b.5v1.albert@cherry.spenarnc.xs4all.nl> |
| In reply to | #46963 |
On 2016-05-06, Paul Rubin <no.email@nospam.invalid> wrote: > rickman <gnuarm@gmail.com> writes: >> That's why we see so may MCU boards out there, some with nothing on >> them but the absolute minimum. Those are the ones that are sold a >> lot. > > The minimalistic ones sell a lot because they're cheap. This one is > expensive and rather maximalistic. The purpose of the maximalism, as > mentioned, is to get rid of extra boards. If your device is going to > need a charger anyway, then that's an obvious extra board to get rid of. > It's possible that the designer intended for the user to disconnect the > battery for charging--the supercap backing up the RTC would seem to help > that. > > The Adafruit Feathers all have chargers, so it's obviously considered a > useful feature by someone. I think there's a level of maker courtesy to > not copy each others' features too much, so that might be part of what's > going on here. I can respect it if that's the case. For my own > purposes I don't care about the SPI flash that much, but I do care about > the RTC, which is a separate board for the Feathers. There's also > currently no Cortex M4 Feather, just some M0's and some Atmegas. If one of the purpose is ultralight aviation, it is easy it understand. During operation you can't charge. So why have the charger on the board? We have a great many robots built at Fig Holland. None of them uses a board with a charger. It just adds extra weight. -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-07 15:38 -0400 |
| Message-ID | <nglg1n$8e5$1@dont-email.me> |
| In reply to | #46969 |
On 5/7/2016 7:32 AM, Albert van der Horst wrote: > On 2016-05-06, Paul Rubin <no.email@nospam.invalid> wrote: >> rickman <gnuarm@gmail.com> writes: >>> That's why we see so may MCU boards out there, some with nothing on >>> them but the absolute minimum. Those are the ones that are sold a >>> lot. >> >> The minimalistic ones sell a lot because they're cheap. This one is >> expensive and rather maximalistic. The purpose of the maximalism, as >> mentioned, is to get rid of extra boards. If your device is going to >> need a charger anyway, then that's an obvious extra board to get rid of. >> It's possible that the designer intended for the user to disconnect the >> battery for charging--the supercap backing up the RTC would seem to help >> that. >> >> The Adafruit Feathers all have chargers, so it's obviously considered a >> useful feature by someone. I think there's a level of maker courtesy to >> not copy each others' features too much, so that might be part of what's >> going on here. I can respect it if that's the case. For my own >> purposes I don't care about the SPI flash that much, but I do care about >> the RTC, which is a separate board for the Feathers. There's also >> currently no Cortex M4 Feather, just some M0's and some Atmegas. > > If one of the purpose is ultralight aviation, it is easy it understand. > During operation you can't charge. So why have the charger on the board? > We have a great many robots built at Fig Holland. None of them uses > a board with a charger. It just adds extra weight. Are your boards off the shelf or custom made for your robots? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-05-08 09:45 +0000 |
| Message-ID | <slrnniu66p.eu3.albert@cherry.spenarnc.xs4all.nl> |
| In reply to | #46979 |
On 2016-05-07, rickman <gnuarm@gmail.com> wrote: > On 5/7/2016 7:32 AM, Albert van der Horst wrote: >> On 2016-05-06, Paul Rubin <no.email@nospam.invalid> wrote: >>> rickman <gnuarm@gmail.com> writes: >>>> That's why we see so may MCU boards out there, some with nothing on >>>> them but the absolute minimum. Those are the ones that are sold a >>>> lot. >>> >>> The minimalistic ones sell a lot because they're cheap. This one is >>> expensive and rather maximalistic. The purpose of the maximalism, as >>> mentioned, is to get rid of extra boards. If your device is going to >>> need a charger anyway, then that's an obvious extra board to get rid of. >>> It's possible that the designer intended for the user to disconnect the >>> battery for charging--the supercap backing up the RTC would seem to help >>> that. >>> >>> The Adafruit Feathers all have chargers, so it's obviously considered a >>> useful feature by someone. I think there's a level of maker courtesy to >>> not copy each others' features too much, so that might be part of what's >>> going on here. I can respect it if that's the case. For my own >>> purposes I don't care about the SPI flash that much, but I do care about >>> the RTC, which is a separate board for the Feathers. There's also >>> currently no Cortex M4 Feather, just some M0's and some Atmegas. >> >> If one of the purpose is ultralight aviation, it is easy it understand. >> During operation you can't charge. So why have the charger on the board? >> We have a great many robots built at Fig Holland. None of them uses >> a board with a charger. It just adds extra weight. > > Are your boards off the shelf or custom made for your robots? We use all kinds of boards. The Forth gg has a tradition of making their own boards. The latest is the Egelboard which is a clone of the Launchboard, sans the USB. (I have one, the first SMD kit I soldered.) The project is tightly coupled to noforth. http://home.hccnet.nl/anij/nof/noforth.html With a description of the kit: http://home.hccnet.nl/anij/nof/boards/msp430g2553%20egel%20kit.pdf Mind the spaces! Albert Nijhof is very stubborn. He insists on having spaces in file names, because it doesn't bother *him*. I'm currently writing a bit-banging flasher for the Egelboard. It works as loaded on lina64 5.x but I want it to make it a turnkey. Making a turnkey that works on the same system is trivial with ciforth, but I want to have a turnkey that can be placed in a linux distribution, without the need to install ciforth. (A similar flasher already works on the Launchpad/Egel written by Willem Ouwerwerkerk.) http://home.hccnet.nl/anij/nof/boards/msp430g2553%20egel%20kit.pdf Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-08 11:04 -0400 |
| Message-ID | <ngnkau$vo8$1@dont-email.me> |
| In reply to | #46985 |
On 5/8/2016 5:45 AM, Albert van der Horst wrote: > On 2016-05-07, rickman <gnuarm@gmail.com> wrote: >> On 5/7/2016 7:32 AM, Albert van der Horst wrote: >>> On 2016-05-06, Paul Rubin <no.email@nospam.invalid> wrote: >>>> rickman <gnuarm@gmail.com> writes: >>>>> That's why we see so may MCU boards out there, some with nothing on >>>>> them but the absolute minimum. Those are the ones that are sold a >>>>> lot. >>>> >>>> The minimalistic ones sell a lot because they're cheap. This one is >>>> expensive and rather maximalistic. The purpose of the maximalism, as >>>> mentioned, is to get rid of extra boards. If your device is going to >>>> need a charger anyway, then that's an obvious extra board to get rid of. >>>> It's possible that the designer intended for the user to disconnect the >>>> battery for charging--the supercap backing up the RTC would seem to help >>>> that. >>>> >>>> The Adafruit Feathers all have chargers, so it's obviously considered a >>>> useful feature by someone. I think there's a level of maker courtesy to >>>> not copy each others' features too much, so that might be part of what's >>>> going on here. I can respect it if that's the case. For my own >>>> purposes I don't care about the SPI flash that much, but I do care about >>>> the RTC, which is a separate board for the Feathers. There's also >>>> currently no Cortex M4 Feather, just some M0's and some Atmegas. >>> >>> If one of the purpose is ultralight aviation, it is easy it understand. >>> During operation you can't charge. So why have the charger on the board? >>> We have a great many robots built at Fig Holland. None of them uses >>> a board with a charger. It just adds extra weight. >> >> Are your boards off the shelf or custom made for your robots? > > We use all kinds of boards. The Forth gg has a tradition of making > their own boards. The latest is the Egelboard which is a clone > of the Launchboard, sans the USB. > (I have one, the first SMD kit I soldered.) > The project is tightly coupled to noforth. > http://home.hccnet.nl/anij/nof/noforth.html > With a description of the kit: > http://home.hccnet.nl/anij/nof/boards/msp430g2553%20egel%20kit.pdf > > Mind the spaces! > Albert Nijhof is very stubborn. He insists on having spaces in file > names, because it doesn't bother *him*. > > I'm currently writing a bit-banging flasher for the Egelboard. > It works as loaded on lina64 5.x but I want it to make it a turnkey. > Making a turnkey that works on the same system is trivial with ciforth, > but I want to have a turnkey that can be placed in a linux distribution, > without the need to install ciforth. > > (A similar flasher already works on the Launchpad/Egel written by > Willem Ouwerwerkerk.) > > http://home.hccnet.nl/anij/nof/boards/msp430g2553%20egel%20kit.pdf Yeah, Albert sounds like a real rebel! lol Damn the spaces, full speed ahead!!! The egg board looks pretty minimal. I guess it is custom so you get exactly the connectors you need? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-05-08 17:36 +0000 |
| Message-ID | <slrnniv1pt.hrs.albert@cherry.spenarnc.xs4all.nl> |
| In reply to | #46988 |
On 2016-05-08, rickman <gnuarm@gmail.com> wrote: > On 5/8/2016 5:45 AM, Albert van der Horst wrote: >> On 2016-05-07, rickman <gnuarm@gmail.com> wrote: >>> On 5/7/2016 7:32 AM, Albert van der Horst wrote: >>>> On 2016-05-06, Paul Rubin <no.email@nospam.invalid> wrote: >>>>> rickman <gnuarm@gmail.com> writes: >>>>>> That's why we see so may MCU boards out there, some with nothing on >>>>>> them but the absolute minimum. Those are the ones that are sold a >>>>>> lot. >>>>> >>>>> The minimalistic ones sell a lot because they're cheap. This one is >>>>> expensive and rather maximalistic. The purpose of the maximalism, as >>>>> mentioned, is to get rid of extra boards. If your device is going to >>>>> need a charger anyway, then that's an obvious extra board to get rid of. >>>>> It's possible that the designer intended for the user to disconnect the >>>>> battery for charging--the supercap backing up the RTC would seem to help >>>>> that. >>>>> >>>>> The Adafruit Feathers all have chargers, so it's obviously considered a >>>>> useful feature by someone. I think there's a level of maker courtesy to >>>>> not copy each others' features too much, so that might be part of what's >>>>> going on here. I can respect it if that's the case. For my own >>>>> purposes I don't care about the SPI flash that much, but I do care about >>>>> the RTC, which is a separate board for the Feathers. There's also >>>>> currently no Cortex M4 Feather, just some M0's and some Atmegas. >>>> >>>> If one of the purpose is ultralight aviation, it is easy it understand. >>>> During operation you can't charge. So why have the charger on the board? >>>> We have a great many robots built at Fig Holland. None of them uses >>>> a board with a charger. It just adds extra weight. >>> >>> Are your boards off the shelf or custom made for your robots? >> >> We use all kinds of boards. The Forth gg has a tradition of making >> their own boards. The latest is the Egelboard which is a clone >> of the Launchboard, sans the USB. >> (I have one, the first SMD kit I soldered.) >> The project is tightly coupled to noforth. >> http://home.hccnet.nl/anij/nof/noforth.html >> With a description of the kit: >> http://home.hccnet.nl/anij/nof/boards/msp430g2553%20egel%20kit.pdf >> >> Mind the spaces! >> Albert Nijhof is very stubborn. He insists on having spaces in file >> names, because it doesn't bother *him*. >> >> I'm currently writing a bit-banging flasher for the Egelboard. >> It works as loaded on lina64 5.x but I want it to make it a turnkey. >> Making a turnkey that works on the same system is trivial with ciforth, >> but I want to have a turnkey that can be placed in a linux distribution, >> without the need to install ciforth. >> >> (A similar flasher already works on the Launchpad/Egel written by >> Willem Ouwerwerkerk.) >> >> http://home.hccnet.nl/anij/nof/boards/msp430g2553%20egel%20kit.pdf > > Yeah, Albert sounds like a real rebel! lol Damn the spaces, full speed > ahead!!! > > The egg board looks pretty minimal. I guess it is custom so you get > exactly the connectors you need? It's not egg, egel (Dutch for porcupine). It is as minimal as the original Launchpad, minus the usb interface that you don't need for turnkeys, such as a robots. We only have distributed the kit internally (few dozen). Of course that kit contained all the connectors. There is one small defect, which it shares with the Launchpad. For truely reliable turnkey applications there must be a brown out detector added. The definitive version will have that fixed. It is very custom. You can download the gerber files, change the hole size, have one board made, and then order all the smd components from manufacturers that don't use child labour. Is that what you meant? > Groetjes Albert -- Albert van der Horst, UTRECHT Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-05-08 17:39 +0000 |
| Message-ID | <slrnniv20e.hue.albert@cherry.spenarnc.xs4all.nl> |
| In reply to | #46989 |
On 2016-05-08, Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote: > On 2016-05-08, rickman <gnuarm@gmail.com> wrote: <SNIP> >> The egg board looks pretty minimal. I guess it is custom so you get >> exactly the connectors you need? > > It's not egg, egel (Dutch for porcupine). Must be hedgehog. > Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-08 14:08 -0400 |
| Message-ID | <ngnv3o$8o7$1@dont-email.me> |
| In reply to | #46990 |
On 5/8/2016 1:39 PM, Albert van der Horst wrote: > On 2016-05-08, Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote: >> On 2016-05-08, rickman <gnuarm@gmail.com> wrote: > <SNIP> >>> The egg board looks pretty minimal. I guess it is custom so you get >>> exactly the connectors you need? >> >> It's not egg, egel (Dutch for porcupine). > > Must be hedgehog. When I look up a translation it comes up hedgehog. Porcupines are larger and not so cute. We have Opossums here while look similar to porcupines but even less cute when you run into one. They bare their teeth and look very mean. So egel is a much nicer name. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-08 10:52 -0700 |
| Message-ID | <87lh3k77yi.fsf@jester.gateway.pace.com> |
| In reply to | #46989 |
Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> writes: > It's not egg, egel (Dutch for porcupine). > It is as minimal as the original Launchpad, minus the usb interface > that you don't need for turnkeys, such as a robots. http://home.hccnet.nl/anij/nof/noforth.html is pretty cool, particularly http://home.hccnet.nl/anij/nof/how%20noforth%20is%20made.pdf . Does TI still care about the MSP430? It would be great if they made a 2553 compatible part that had comparable resources to the Atmega328, i.e. 32k flash and 2k ram. The 430 is certainly a nicer architecture.
[toc] | [prev] | [next] | [standalone]
| From | David Schultz <abuse@127.0.0.1> |
|---|---|
| Date | 2016-05-08 14:57 -0500 |
| Message-ID | <joKdnUlyBJ7aB7LKnZ2dnUU7-RvNnZ2d@earthlink.com> |
| In reply to | #46991 |
On 05/08/2016 12:52 PM, Paul Rubin wrote: > Does TI still care about the MSP430? It would be great if they made a > 2553 compatible part that had comparable resources to the Atmega328, > i.e. 32k flash and 2k ram. The 430 is certainly a nicer architecture. > It depends on what you mean by "compatible". -- David W. Schultz http://home.earthlink.net/~david.schultz Returned for Regrooving
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-08 13:23 -0700 |
| Message-ID | <87d1ow70zp.fsf@jester.gateway.pace.com> |
| In reply to | #46995 |
>> 2553 compatible part that had comparable resources to the Atmega328, > It depends on what you mean by "compatible". Value Line PDIP part that plugs into the Launchpad just like the 2553.
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-05-09 09:26 +0000 |
| Message-ID | <slrnnj0pge.o0t.albert@cherry.spenarnc.xs4all.nl> |
| In reply to | #46996 |
On 2016-05-08, Paul Rubin <no.email@nospam.invalid> wrote: >>> 2553 compatible part that had comparable resources to the Atmega328, >> It depends on what you mean by "compatible". > > Value Line PDIP part that plugs into the Launchpad just like the 2553. That is ridiculous. If you've a more powerful part, you need more pins. The Dupont board has a total of 48 pins, 2K RAM 61K flash. It is compatible enough. All io that is available on the launchpad is there. The noforth needed just a few small adaptations. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-09 10:26 -0400 |
| Message-ID | <ngq6g3$62g$1@dont-email.me> |
| In reply to | #46999 |
On 5/9/2016 5:26 AM, Albert van der Horst wrote: > On 2016-05-08, Paul Rubin <no.email@nospam.invalid> wrote: >>>> 2553 compatible part that had comparable resources to the Atmega328, >>> It depends on what you mean by "compatible". >> >> Value Line PDIP part that plugs into the Launchpad just like the 2553. > > That is ridiculous. If you've a more powerful part, you need more pins. > The Dupont board has a total of 48 pins, 2K RAM 61K flash. > It is compatible enough. All io that is available on the launchpad > is there. The noforth needed just a few small adaptations. Why would the need for more processing power automatically go with the need for more pins? What is to say the pin count is a driver in all designs? Manufacturers tend to draw the same conclusion you do, but they are shooting for the sweet spot of a market. That does not imply *all* users have the same needs. I often fight the pin count problem from the other direction where I want a part with the same pins, but a *lot* more guts. This is an especially strong problem in the FPGA world. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2016-05-09 09:38 -0700 |
| Message-ID | <6e27d743-15f9-450b-b13d-b4913e19d7cf@googlegroups.com> |
| In reply to | #47000 |
luni, 9 mai 2016, 17:26:31 UTC+3, rickman a scris: > On 5/9/2016 5:26 AM, Albert van der Horst wrote: > > On 2016-05-08, Paul Rubin <no.email@nospam.invalid> wrote: > >>>> 2553 compatible part that had comparable resources to the Atmega328, > >>> It depends on what you mean by "compatible". > >> > >> Value Line PDIP part that plugs into the Launchpad just like the 2553. > > > > That is ridiculous. If you've a more powerful part, you need more pins. > > The Dupont board has a total of 48 pins, 2K RAM 61K flash. > > It is compatible enough. All io that is available on the launchpad > > is there. The noforth needed just a few small adaptations. > > Why would the need for more processing power automatically go with the > need for more pins? What is to say the pin count is a driver in all > designs? Manufacturers tend to draw the same conclusion you do, but > they are shooting for the sweet spot of a market. That does not imply > *all* users have the same needs. I often fight the pin count problem > from the other direction where I want a part with the same pins, but a > *lot* more guts. This is an especially strong problem in the FPGA world. > > -- > > Rick C I've seen lately device families with the same processing power on different packages. For example an Atmel cortex-m0 family have 256K flash and 32K ram on a 32pin chip, as well as on 48pin and 64pin chips. In fact they produce a very orthogonal family of any combination of memory sizes and packages. They have 32k/4k, 64k/8k, 128k/16k, 256k/32k memory options on any 32/48/64 pin options... Also, the peripherals are the same for any combination, maybe except the analog input pins number which are less on the smaller packages. An example of an application where you need big power but few pins are protocol converters. Few pins because there are serial interfaces, big power depending on the protocols complexity. Some status leds and/or dipswitches/buttons may be required too, but overall the pin numbers needed for such a converter is small.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-09 12:58 -0400 |
| Message-ID | <ngqfdu$80t$1@dont-email.me> |
| In reply to | #47001 |
On 5/9/2016 12:38 PM, Raimond Dragomir wrote: > luni, 9 mai 2016, 17:26:31 UTC+3, rickman a scris: >> On 5/9/2016 5:26 AM, Albert van der Horst wrote: >>> On 2016-05-08, Paul Rubin <no.email@nospam.invalid> wrote: >>>>>> 2553 compatible part that had comparable resources to the Atmega328, >>>>> It depends on what you mean by "compatible". >>>> >>>> Value Line PDIP part that plugs into the Launchpad just like the 2553. >>> >>> That is ridiculous. If you've a more powerful part, you need more pins. >>> The Dupont board has a total of 48 pins, 2K RAM 61K flash. >>> It is compatible enough. All io that is available on the launchpad >>> is there. The noforth needed just a few small adaptations. >> >> Why would the need for more processing power automatically go with the >> need for more pins? What is to say the pin count is a driver in all >> designs? Manufacturers tend to draw the same conclusion you do, but >> they are shooting for the sweet spot of a market. That does not imply >> *all* users have the same needs. I often fight the pin count problem >> from the other direction where I want a part with the same pins, but a >> *lot* more guts. This is an especially strong problem in the FPGA world. >> >> -- >> >> Rick C > > I've seen lately device families with the same processing power on > different packages. For example an Atmel cortex-m0 family have 256K > flash and 32K ram on a 32pin chip, as well as on 48pin and 64pin chips. > In fact they produce a very orthogonal family of any combination > of memory sizes and packages. They have 32k/4k, 64k/8k, 128k/16k, 256k/32k > memory options on any 32/48/64 pin options... > Also, the peripherals are the same for any combination, maybe except the > analog input pins number which are less on the smaller packages. > > An example of an application where you need big power but few pins are > protocol converters. Few pins because there are serial interfaces, big > power depending on the protocols complexity. Some status leds and/or > dipswitches/buttons may be required too, but overall the pin numbers > needed for such a converter is small. Signal processing can require a lot of RAM and MIPS, but not so much I/O. There are plenty of apps for a range of pin count and feature combinations. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-05-09 22:53 +0000 |
| Message-ID | <slrnnj28pb.260.albert@cherry.spenarnc.xs4all.nl> |
| In reply to | #47000 |
On 2016-05-09, rickman <gnuarm@gmail.com> wrote: > On 5/9/2016 5:26 AM, Albert van der Horst wrote: >> On 2016-05-08, Paul Rubin <no.email@nospam.invalid> wrote: >>>>> 2553 compatible part that had comparable resources to the Atmega328, >>>> It depends on what you mean by "compatible". >>> >>> Value Line PDIP part that plugs into the Launchpad just like the 2553. >> >> That is ridiculous. If you've a more powerful part, you need more pins. >> The Dupont board has a total of 48 pins, 2K RAM 61K flash. >> It is compatible enough. All io that is available on the launchpad >> is there. The noforth needed just a few small adaptations. > > Why would the need for more processing power automatically go with the > need for more pins? What is to say the pin count is a driver in all > designs? Manufacturers tend to draw the same conclusion you do, but > they are shooting for the sweet spot of a market. That does not imply > *all* users have the same needs. I often fight the pin count problem > from the other direction where I want a part with the same pins, but a > *lot* more guts. This is an especially strong problem in the FPGA world. > Not automatically, but in general the sweet spots are a good balance between RAM,flash and I/O capabilities. That is the reason that a F149 has about 4 times the RAM , 4 times the Flash and 4 times the io pins of the 2553. [Maybe I was a bit rude about it.] Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-09 22:41 -0400 |
| Message-ID | <ngrhi9$rfg$1@dont-email.me> |
| In reply to | #47006 |
On 5/9/2016 6:53 PM, Albert van der Horst wrote: > On 2016-05-09, rickman <gnuarm@gmail.com> wrote: >> On 5/9/2016 5:26 AM, Albert van der Horst wrote: >>> On 2016-05-08, Paul Rubin <no.email@nospam.invalid> wrote: >>>>>> 2553 compatible part that had comparable resources to the Atmega328, >>>>> It depends on what you mean by "compatible". >>>> >>>> Value Line PDIP part that plugs into the Launchpad just like the 2553. >>> >>> That is ridiculous. If you've a more powerful part, you need more pins. >>> The Dupont board has a total of 48 pins, 2K RAM 61K flash. >>> It is compatible enough. All io that is available on the launchpad >>> is there. The noforth needed just a few small adaptations. >> >> Why would the need for more processing power automatically go with the >> need for more pins? What is to say the pin count is a driver in all >> designs? Manufacturers tend to draw the same conclusion you do, but >> they are shooting for the sweet spot of a market. That does not imply >> *all* users have the same needs. I often fight the pin count problem >> from the other direction where I want a part with the same pins, but a >> *lot* more guts. This is an especially strong problem in the FPGA world. >> > > Not automatically, but in general the sweet spots are a > good balance between RAM,flash and I/O capabilities. > That is the reason that a F149 has about 4 times the RAM , > 4 times the Flash and 4 times the io pins of the 2553. > > [Maybe I was a bit rude about it.] Emphatic perhaps, but not really rude. I just don't agree that this is a useful generalization. I find the combinations vary widely with the application. I think that's why Digikey lists 61057 "Embedded Microcontrollers". MCU makers do a *much* better job of covering all the bases than the FPGA vendors. -- Rick C
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web