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 | 19 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 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-09 11:08 -0700 |
| Message-ID | <87posv5ckh.fsf@jester.gateway.pace.com> |
| In reply to | #46999 |
Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> writes: >> 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. 1. That's some weird board that I have to order from .NL? Seems like a pain compared to a Launchpad. Also, it uses an SMT part instead of a convenient PDIP that I can use on a breadboard or easily hand solder in my own circuits. 2. Even if you're right that there's a correspondence between an application's memory requirements and the number of pins it needs, the chip vendor probably assumes most applications are written in C. If writing my app in C uses 10k of ram and 300 bytes of flash, the 2553 can easily run it, and maybe the pin count also comes out right for the app. But now if we want to write the app in Forth, that will take another 10k(?) of flash for the interpreter and another 0.25k or so of ram as well, so it no longer fits. What we want is a more powerful chip with the same pins. 3. The Atmeta328 (32k flash, 2k ram)'s popularity shows there is high demand for a PDIP part with those resources. It does have a few more pins than the 2553 but it would be fine without the extra ones. 4. The ATTiny85 (8k flash, 0.5k ram) is also popular in the maker community and it's available in DIP-8 format, showing high pin counts are not always needed. It has enough flash+ram to run plenty of small C applications. But again, if we want to include a Forth interpreter, we need at least 2553-like capacity and preferably more. 5. In fact one of the attractions of Forth is that the complete interpreter and dev environment (editor etc.) written in Forth so the user can modify it and rebuild it. I think historical environments like that wanted around 64k of ram and 1MB of disk, which is doable with some of the Cortex-M parts: if that was available in a 2553-like package and cheap enough, I'd use it! 6. Even further, one of the boards we're discussing here, the Dragonfly, has a Cortex M4 cpu with 128k ram and 512M flash on the chip, plus 16MB of on-board SPI flash. That's enough for a complete dev environment with files, documentation, source code to everything, revision control, etc. One thing not really needed is more pins! There's no technical obstacle to putting it all in a 2553-sized PDIP. 7. In fact, ... , well you get the idea.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-09 13:21 -0700 |
| Message-ID | <87h9e756e6.fsf@jester.gateway.pace.com> |
| In reply to | #47003 |
Paul Rubin <no.email@nospam.invalid> writes: > 10k of ram and 300 bytes of flash, the 2553 can easily run it : oops ram flash SWAP ; oops ok
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-05-09 23:39 +0000 |
| Message-ID | <slrnnj2bfq.260.albert@cherry.spenarnc.xs4all.nl> |
| In reply to | #47003 |
On 2016-05-09, Paul Rubin <no.email@nospam.invalid> wrote: > Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> writes: > <SNIP> > 2. Even if you're right that there's a correspondence between an > application's memory requirements and the number of pins it needs, the > chip vendor probably assumes most applications are written in C. If > writing my app in C uses 10k of ram and 300 bytes of flash, the 2553 can > easily run it, and maybe the pin count also comes out right for the app. > But now if we want to write the app in Forth, that will take another > 10k(?) of flash for the interpreter and another 0.25k or so of ram as > well, so it no longer fits. What we want is a more powerful chip with > the same pins. If anything Forh applications are more compact, the interpreter consists for the most part of sensible library functions. <SNIP> > > 4. The ATTiny85 (8k flash, 0.5k ram) is also popular in the maker > community and it's available in DIP-8 format, showing high pin counts > are not always needed. It has enough flash+ram to run plenty of small C > applications. But again, if we want to include a Forth interpreter, we > need at least 2553-like capacity and preferably more. Forth Chapter Holland has been there and done that. ByteForth is available for ages and has proven to be practical on DIP-8 chips. With all the known advantages of Forth over C. > > 5. In fact one of the attractions of Forth is that the complete > interpreter and dev environment (editor etc.) written in Forth so the > user can modify it and rebuild it. I think historical environments like > that wanted around 64k of ram and 1MB of disk, which is doable with some > of the Cortex-M parts: if that was available in a 2553-like package and > cheap enough, I'd use it! Noforth for the 2553 is a formidable development environment with indeed the interpreter running on the board. Running an editor on a Launchpad and storing files there, for Forth source? mp4's on a SD-card maybe, some people have enough mp4 files to fill a 32 Gbyte disk. > > 6. Even further, one of the boards we're discussing here, the Dragonfly, > has a Cortex M4 cpu with 128k ram and 512M flash on the chip, plus 16MB > of on-board SPI flash. That's enough for a complete dev environment > with files, documentation, source code to everything, revision control, > etc. One thing not really needed is more pins! There's no technical > obstacle to putting it all in a 2553-sized PDIP. So what you want is something like Linux, Android, in short Unix. But we have that in all kinds of shapes, starting with the Raspberry. Why the obsession with the pin count? With 8 channels of PCI express one can do a terrible amount of I/O I give you that. Maybe it's going to happen. Not because it must, but because it can. > > 7. In fact, ... , well you get the idea. In fact everybody is doing the same thing: think of an idea, count what is needed for it, then choose the smallest board that can accomodate the needs. The discussion is pretty fruitless without an application in mind. I'm thinking about a digital sine generator currently. That requires fifteen to twenty I/O pins just to switch capacitors. A chip with enough pins has almost certainly enough flash and RAM. But it must be an MSP430. I don't want to program a PIC,8052, atmega or ARM. (ARM is okay but not for this). 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-09 19:03 -0700 |
| Message-ID | <87d1ou6552.fsf@jester.gateway.pace.com> |
| In reply to | #47008 |
Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> writes: > If anything Forh applications are more compact, the interpreter > consists for the most part of sensible library functions. No I don't think so: you can write sensible library functions for C just as well, and a lot of a Forth interpreter's code consists of the text interpreter and its supporting machinery, which is completely absent from a typical C application. In the case of MSP430 Camelforth I think that's around 8k or so of flash. I don't know about Noforth. > ByteForth is available for ages and has proven to be practical on > DIP-8 chips. Sounds interesting-- got a url? > Noforth for the 2553 is a formidable development environment with > indeed the interpreter running on the board. Running an editor on > a Launchpad and storing files there, for Forth source? ... SD card... An SD card is physically rather large compared to a tiny SPI flash package, and decreases reliability because of yet another solderless connector. 2553 Noforth does sound nice and I'd like to give it a try. I notice that the V version (with namelists) uses more code space, which wouldn't be an issue in a hypothetical larger 2553. >> Cortex M4 cpu with 128k ram and 512M* flash... *[I meant 512K not M] > So what you want is something like Linux, Android, in short Unix. Not really; I'm imagining something closer to the Forth environments that ran on old micro and minicomputers. A text interpreter with an editor and a simple file system, plus enough stuff to modify and recompile the system, and also to back out of errors. CPU speed for most usage is probably irrelevant: 1 mhz would be more than plenty. > But we have that in all kinds of shapes, starting with the Raspberry. No that's an enormously more complicated system-- basically a PC on a board. Lots of software subsystems, high power consumption, long bootup delay, etc. It can't possibly go in the places where a 2553 can go. > Why the obsession with the pin count? To keep the packages small. Here's a keychain flashlight with variable brightness (PWM), blinky modes, SOS, etc.: http://www.ledmuseum.net/freedom.htm It was first released in the early 2000's and I believe it uses a PIC12 microprocessor programmed in assembler. Maybe we'd like to be able to reconfigure or reprogram it, to change what the button actions do, etc. The current hipster approach would be to have some stupid Iphone app that connects to it and uploads all your personal usage patterns to a cloud server run by some corporate octopus. But surely 10+ years of MCU advances would let us use a part that lets us program it in Forth. Then we could connect a tty to some UART pins, get an OK prompt, and interactively tweak the device any way we like. No non-portable host side apps, no GUI, no Iphone--just a wholesome Forth text interpreter. But a Raspberry Pi inside would be silly. When you turn on a flashlight, it has to light up immediately, not spend 30 seconds booting and sending DHCP and NTP queries to the internet. A 2553 with Camel or Noforth for this would be fine. > In fact everybody is doing the same thing: think of an idea, count > what is needed for it, then choose the smallest board that > can accomodate the needs. Of course they don't. When was the last time you heard of a 4-bit MCU? They used to be everywhere, since you didn't always need the power of an 8-bit. And these days, the Cortex M0 is pushing out the 8-bit parts. You could save a few cents of hardware with an 8-bit MCU, but unless the quantity is huge, it's probably not worth the extra programming effort to use a 25 cent part instead of a 35 cent part. If we live in an era where every little gadget with a 35 cent MCU inside can run an interactive Forth interpreter, shouldn't we embrace it and put those interpreter in everything? > I'm thinking about a digital sine generator currently. That requires > fifteen to twenty I/O pins just to switch capacitors. A chip with > enough pins has almost certainly enough flash and RAM. Not just a DAC?
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-09 21:44 -0700 |
| Message-ID | <878tzi5xos.fsf@jester.gateway.pace.com> |
| In reply to | #47009 |
Paul Rubin <no.email@nospam.invalid> writes: >> ByteForth ... has proven to be practical on DIP-8 chips. > Sounds interesting-- got a url? Found it: http://home.hccnet.nl/willem.ouwerkerk/byteforth.htm I sort of remember seeing it before. I don't speak NL but can sort of read it as garbled English and figure out what most of it says, so cool :).
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-05-10 08:28 +0000 |
| Message-ID | <slrnnj3aff.7fb.albert@cherry.spenarnc.xs4all.nl> |
| In reply to | #47009 |
On 2016-05-10, Paul Rubin <no.email@nospam.invalid> wrote: > Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> writes: >> If anything Forh applications are more compact, the interpreter >> consists for the most part of sensible library functions. > > No I don't think so: you can write sensible library functions for C just > as well, and a lot of a Forth interpreter's code consists of the text > interpreter and its supporting machinery, which is completely absent > from a typical C application. In the case of MSP430 Camelforth I think > that's around 8k or so of flash. I don't know about Noforth. > >> ByteForth is available for ages and has proven to be practical on >> DIP-8 chips. > > Sounds interesting-- got a url? May you should put the site of the Dutch Forth Chapter in your favourites: http://forth.hcc.nl In the top menu choose producten, then choose byteforth in the side menu. (You can find ciforth there too, and the egel "werkboek"). This part of the site is in Dutch. > >> Noforth for the 2553 is a formidable development environment with >> indeed the interpreter running on the board. Running an editor on >> a Launchpad and storing files there, for Forth source? ... SD card... > > An SD card is physically rather large compared to a tiny SPI flash > package, and decreases reliability because of yet another solderless > connector. 2553 Noforth does sound nice and I'd like to give it a try. > I notice that the V version (with namelists) uses more code space, which > wouldn't be an issue in a hypothetical larger 2553. Micro sd cards too large for you? Then I've nothing to say. But I'm with you. ciforth's WANT system works with blocks. Even a smallish sdcard could accomodate a library for the whole MSP430 family. (Once the board is determined, WANT takes care of conditional loading. The current ciforth library accomodates 16/32/64 bit, msdos/win32/linux, standalone. The bitbanging application I'm writing right now, has one line of conditional code for 32/64 bit that possibly will migrate to the library in the future.) > >>> Cortex M4 cpu with 128k ram and 512M* flash... *[I meant 512K not M] >> So what you want is something like Linux, Android, in short Unix. > > Not really; I'm imagining something closer to the Forth environments > that ran on old micro and minicomputers. A text interpreter with an > editor and a simple file system, plus enough stuff to modify and > recompile the system, and also to back out of errors. CPU speed for > most usage is probably irrelevant: 1 mhz would be more than plenty. You may like my com-4e5 environment. It switches between a communication mode and Forth mode. The Forth is just a 64 bit Forth run on an 8core 4Ghz 16 Gbyte. It makes sense to offload files and editors to this smart terminal. For the rest it is the good oldfashioned Forth idea. If you want to change the msp430 Forth itself you're welcome too. The metacompiler runs on ISO Forth's , and is 64 bit clean. It doesn't run on noforth. It maybe could but it slightly big. We're just pratical here. I've a VT100 somewhere. It is not my dream to run the 2553 from this terminal alone. > >> But we have that in all kinds of shapes, starting with the Raspberry. > > No that's an enormously more complicated system-- basically a PC on a > board. Lots of software subsystems, high power consumption, long bootup > delay, etc. It can't possibly go in the places where a 2553 can go. > >> Why the obsession with the pin count? > > To keep the packages small. Here's a keychain flashlight with variable > brightness (PWM), blinky modes, SOS, etc.: > > http://www.ledmuseum.net/freedom.htm > > It was first released in the early 2000's and I believe it uses a PIC12 > microprocessor programmed in assembler. Maybe we'd like to be able to > reconfigure or reprogram it, to change what the button actions do, etc. > > The current hipster approach would be to have some stupid Iphone app > that connects to it and uploads all your personal usage patterns to a > cloud server run by some corporate octopus. But surely 10+ years of MCU > advances would let us use a part that lets us program it in Forth. Then > we could connect a tty to some UART pins, get an OK prompt, and > interactively tweak the device any way we like. No non-portable host > side apps, no GUI, no Iphone--just a wholesome Forth text interpreter. > > But a Raspberry Pi inside would be silly. When you turn on a > flashlight, it has to light up immediately, not spend 30 seconds booting > and sending DHCP and NTP queries to the internet. A 2553 with Camel or > Noforth for this would be fine. You know that this is the trend. In Elektor I see lots of nice designs, that don't use overkill but most people wouldn't be able to design them. With Egel we try to offer building blocks to use in Forth to lower the bar. > >> In fact everybody is doing the same thing: think of an idea, count >> what is needed for it, then choose the smallest board that >> can accomodate the needs. > > Of course they don't. When was the last time you heard of a 4-bit MCU? > They used to be everywhere, since you didn't always need the power of an > 8-bit. And these days, the Cortex M0 is pushing out the 8-bit parts. > You could save a few cents of hardware with an 8-bit MCU, but unless the > quantity is huge, it's probably not worth the extra programming effort > to use a 25 cent part instead of a 35 cent part. It is more like using a 250 cent instead of 35 cent part, because of availability. Of course I count practicality into the choice. > > If we live in an era where every little gadget with a 35 cent MCU inside > can run an interactive Forth interpreter, shouldn't we embrace it and > put those interpreter in everything? That is exactly what noforth is about, but below a certain footprint DIP has to go. > >> I'm thinking about a digital sine generator currently. That requires >> fifteen to twenty I/O pins just to switch capacitors. A chip with >> enough pins has almost certainly enough flash and RAM. > > Not just a DAC? Aiming for 0.01% distortion. That is DAC plus filtering. The built in DAC may not hold up, then there will be even more I/O pins needed. 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-10 12:34 -0400 |
| Message-ID | <ngt2c3$nc0$1@dont-email.me> |
| In reply to | #47013 |
On 5/10/2016 4:28 AM, Albert van der Horst wrote: > On 2016-05-10, Paul Rubin <no.email@nospam.invalid> wrote: >> Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> writes: >> >>> I'm thinking about a digital sine generator currently. That requires >>> fifteen to twenty I/O pins just to switch capacitors. A chip with >>> enough pins has almost certainly enough flash and RAM. >> >> Not just a DAC? > > Aiming for 0.01% distortion. That is DAC plus filtering. The built in > DAC may not hold up, then there will be even more I/O pins needed. I have some experience with DDS designs. 0.01% distortion is not a problem if your DAC is up to the job. Virtually any audio quality codec should be capable of that. What frequency range are you shooting for? The DAC found in MCUs may not be up to the job. But you can do dithering to get better resolution. It won't do much for the inherent non-linearity though and that will cause distortion. If you are dithering to add resolution, in theory the non-linearities could be compensated for, but I have no idea how to come up with a formula to do that unless each unit is calibrated. It is entirely possible to implement a 1 bit DAC with sigma-delta techniques. With a very high sample rate it has much less requirements for the filter. If you use an audio quality DAC (or CODEC) the design of an audio frequency DDS is not very hard at all. It won't take too much processing and the interface would be just four pins (or maybe even just three since you aren't use the ADC). So this would likely fit in a very tiny MCU as long as it has a crystal clock since low distortion depends on a stable clock. I'm not sure what you are doing with the capacitors. The filter needed for a DAC depends on the sample rate, not the frequency of the signal produced. Are you planning to change your sample rate to change the signal frequency? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-05-10 22:27 +0000 |
| Message-ID | <slrnnj4rke.eho.albert@cherry.spenarnc.xs4all.nl> |
| In reply to | #47014 |
On 2016-05-10, rickman <gnuarm@gmail.com> wrote: > On 5/10/2016 4:28 AM, Albert van der Horst wrote: <SNIP> >> Aiming for 0.01% distortion. That is DAC plus filtering. The built in >> DAC may not hold up, then there will be even more I/O pins needed. > > I have some experience with DDS designs. 0.01% distortion is not a > problem if your DAC is up to the job. Virtually any audio quality codec > should be capable of that. What frequency range are you shooting for? > > The DAC found in MCUs may not be up to the job. But you can do > dithering to get better resolution. It won't do much for the inherent > non-linearity though and that will cause distortion. If you are > dithering to add resolution, in theory the non-linearities could be > compensated for, but I have no idea how to come up with a formula to do > that unless each unit is calibrated. > > It is entirely possible to implement a 1 bit DAC with sigma-delta > techniques. With a very high sample rate it has much less requirements > for the filter. > > If you use an audio quality DAC (or CODEC) the design of an audio > frequency DDS is not very hard at all. It won't take too much > processing and the interface would be just four pins (or maybe even just > three since you aren't use the ADC). So this would likely fit in a very > tiny MCU as long as it has a crystal clock since low distortion depends > on a stable clock. > > I'm not sure what you are doing with the capacitors. The filter needed > for a DAC depends on the sample rate, not the frequency of the signal > produced. Are you planning to change your sample rate to change the > signal frequency? I wouldn't be interested in this, if I'd have to add a high quality DAC. Nor would I, if it was only a textbook application. If the MSP430 DAC is not sufficiently linear that will be a problem. How much remains to be seen. If it is, I have a solution. The filter for my solution depends on the frequency of the signal. That is all I'm willing to disclose at the moment. The idea is a Launchpad plus passive components only. 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 | Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-05-09 09:16 +0000 |
| Message-ID | <slrnnj0oso.o0t.albert@cherry.spenarnc.xs4all.nl> |
| In reply to | #46991 |
On 2016-05-08, Paul Rubin <no.email@nospam.invalid> wrote: > 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. There are interesting new developments, like the magnetic ram (fram). You can find an overview of the boards supported by noforth, some of them are more capable like the Dupont board. You can find an overview on the noforth site. 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:01 -0400 |
| Message-ID | <ngnunj$86e$1@dont-email.me> |
| In reply to | #46989 |
On 5/8/2016 1:36 PM, Albert van der Horst wrote: > On 2016-05-08, rickman <gnuarm@gmail.com> wrote: >> >> 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? I was asking why bother with a custom board if it is pretty much the same as the launchpad. I figured you needed custom connectors for your application. Is the presence of the USB interface chip so big a deal that you need a custom board? The Cypress PSOC boards are small, not much more than the MCU and you can break off the part with the USB interface. Not that that is a recommendation. I actually found them awkward to use. In theory the MCUs include some programmable hardware so the tools are designed so you don't need to know much about the details. In the process the tools have become *too* dumbed down so you can't tell much of what is going on. Doesn't the MCU include a brownout detector? I thought nearly all MCUs had those these days. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-03-31 23:26 -0700 |
| Message-ID | <87bn5tsv3e.fsf@nightsong.com> |
| In reply to | #46378 |
rickman <gnuarm@gmail.com> writes: > Personally I feel they are a bit overrated. They have to be installed > using a JTAG or similar programmer. Then if they are clobbered, back > to the programmer. So why not just use one all the time to begin > with I had that conversation with some AVR users and they say it isn't a problem with the arduino. Yes you can wipe out the bootloader if you try, but it's apparently quite hard to do it by accident. There's a dance you have to do to unprotect that memory region. I remember the FRAM MSP430's also have a way to write-protect code memory.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-03-31 19:09 -0700 |
| Message-ID | <87oa9urseo.fsf@nightsong.com> |
| In reply to | #46372 |
visualforth@rocketmail.com writes: > With FRAM and a token threaded Forth (like Jupiter ACE's Forth) no > Block Editor is needed: programming as you go and editing/debugging > the source code directly on chip if needed. Wait, what? That sounds even more painful than block editing. What if you want to factor a word, which means adding another word just above where the old word was? How would this editing actually work? Hmm, do you mean treat the FRAM program area as a contiguous file and just copy stuff around as you edit? With 32k of off-chip fram you can probably copy it all in a few msec. So if you had a local editing buffer of a line or so, you'd do some copying when the person inserted or deleted a line, but not on every input char. Maybe that is workable. The bigger FRAM launchpads (5969 and 6989) still look a lot more attractive to me though.
[toc] | [prev] | [next] | [standalone]
| From | David Schultz <abuse@127.0.0.1> |
|---|---|
| Date | 2016-03-31 21:41 -0500 |
| Message-ID | <2f6dnYPRfqgjQmDLnZ2dnUU7-ffNnZ2d@earthlink.com> |
| In reply to | #46374 |
On 03/31/2016 09:09 PM, Paul Rubin wrote: > The bigger FRAM launchpads (5969 and 6989) still look a lot more > attractive to me though. > Kind of. Accessing memory above 0x10000 is a pain. I thought about using the 16K there on the FR5969 as a data buffer but converting a 32 bit value on the Forth stack to a 20 bit address in a register is not trivial. Add to that the limitations of the MPU and I am just pretending that it isn't there. I enabled the MPU so that a coding error doesn't take out Forth or the vectors. The MPU can only define 3 segments so when I write protect the vectors the upper FRAM is also write protected. -- 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-03-31 23:10 -0700 |
| Message-ID | <87k2khsvtc.fsf@nightsong.com> |
| In reply to | #46376 |
David Schultz <abuse@127.0.0.1> writes: > Kind of. Accessing memory above 0x10000 is a pain.. > Add to that the limitations of the MPU and I am just pretending that it > isn't there. Yeah, I haven't examined it but there were similar issues with early Unix on the bigger PDP-11's. I figured the space about 0x10000 could be used as a block or file store without having to be able to run code from it or access it directly from programs. Only the block words would touch it, using special instructions that let you copy a block to or from low memory. Of course with an SD card the storage question kind of goes away. Are you using the SPI interface to the card? How fast do you run it?
[toc] | [prev] | [next] | [standalone]
| From | David Schultz <abuse@127.0.0.1> |
|---|---|
| Date | 2016-04-01 12:37 -0500 |
| Message-ID | <aIqdnc8Y4KpqLGPLnZ2dnUU7-dnNnZ2d@earthlink.com> |
| In reply to | #46380 |
On 04/01/2016 01:10 AM, Paul Rubin wrote: > Of course with an SD card the storage question kind of > goes away. Are you using the SPI interface to the card? How fast do > you run it? > I am running the SPI with 1 8MHz clock. For normal Forth block use this is more than fast enough even with the SD routines being colon definitions. Since I have MCLK running at 16MHz I could increase the SPI clock speed but the improvements would be slight. Since I need to log data at higher rates than that I have been working on faster code using the DMAC. That has been interesting and while the average is about 400KB/sec the periodic stalls by the card are annoying. -- 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-04-01 15:35 -0700 |
| Message-ID | <877fghrm8g.fsf@nightsong.com> |
| In reply to | #46395 |
David Schultz <abuse@127.0.0.1> writes: > I am running the SPI with 1 8MHz clock. For normal Forth block use this > is more than fast enough even with the SD routines being colon > definitions. Oh that's terrifically fast for stuff like a block loader. Is the erase block size really 128kib? How do you deal with that? I found the info here: http://3gfp.com/wp/2014/07/formatting-sd-cards-for-speed-and-lifetime/ I could also see the 16kib write block size as being hard to manage on a smaller cpu. > Since I need to log data at higher rates than that I have been working > on faster code using the DMAC. That has been interesting and while the > average is about 400KB/sec the periodic stalls by the card are annoying. Maybe with that big a system going on, you might want a cpu with more buffer ram etc. There's a Cortex M4 discovery board with 8MB of off-chip ram iirc, and of course there's always the raspberry pi class of board. How are you liking eforth for doing anything real? I played with it a little and it seemed very limited compared with flashforth, mecrisp, etc.
[toc] | [prev] | [next] | [standalone]
| From | David Schultz <abuse@127.0.0.1> |
|---|---|
| Date | 2016-04-01 18:11 -0500 |
| Message-ID | <VeKdnerwS6S7nWLLnZ2dnUU7-YvNnZ2d@earthlink.com> |
| In reply to | #46402 |
On 04/01/2016 05:35 PM, Paul Rubin wrote: > David Schultz <abuse@127.0.0.1> writes: >> I am running the SPI with 1 8MHz clock. For normal Forth block use this >> is more than fast enough even with the SD routines being colon >> definitions. > > Oh that's terrifically fast for stuff like a block loader. Is the > erase block size really 128kib? How do you deal with that? I found > the info here: > I have no idea. For the basic functionality I just read and write single 512 byte blocks. > Maybe with that big a system going on, you might want a cpu with more > buffer ram etc. There's a Cortex M4 discovery board with 8MB of > off-chip ram iirc, and of course there's always the raspberry pi class > of board. > I picked up a STM32F4 Discovery board a while back and got the SDIO interface running because I was thinking about an application that would need to record data at 2MB/sec. I got that working but never moved on to the application. I considered that for this logger but I just don't need that much performance. Even with the SDIO interface there are stalls. > How are you liking eforth for doing anything real? I played with it a > little and it seemed very limited compared with flashforth, mecrisp, > etc. > I like it. But then I have added on a number of things that aren't in the basic eForth. It is about time to build the target hardware but the prospect of soldering the QFN packaged sensor makes me nervous. I got lucky once but will I be lucky again? -- David W. Schultz http://home.earthlink.net/~david.schultz Returned for Regrooving
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2016-03-31 19:47 -0700 |
| Message-ID | <9d7cf792-fdb4-4f98-bf22-96279aa29e16@googlegroups.com> |
| In reply to | #46374 |
On Thursday, March 31, 2016 at 10:09:55 PM UTC-4, Paul Rubin wrote: > visualforth.com writes: > > With FRAM and a token threaded Forth (like Jupiter ACE's Forth) no > > Block Editor is needed: programming as you go and editing/debugging > > the source code directly on chip if needed. > > Wait, what? That sounds even more painful than block editing. What if > you want to factor a word, which means adding another word just above > where the old word was? How would this editing actually work? > > Hmm, do you mean treat the FRAM program area as a contiguous file and > just copy stuff around as you edit? With 32k of off-chip fram you can > probably copy it all in a few msec. So if you had a local editing > buffer of a line or so, you'd do some copying when the person inserted > or deleted a line, but not on every input char. Maybe that is workable. > > The bigger FRAM launchpads (5969 and 6989) still look a lot more > attractive to me though. Look at Jupiter ACE user manual Chapter 7, Altering word definitions: How to correct mistakes, using LIST, EDIT and REDEFINE. There you will find the procedure they used. With FRAM it may even be improvable. Source: http://jupiter-ace.co.uk/usermanual.html The Jupiter ACE source code is available at https://github.com/LawrenceWoodman/xAce
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-03-31 23:23 -0700 |
| Message-ID | <87fuv5sv8b.fsf@nightsong.com> |
| In reply to | #46377 |
visualforth@rocketmail.com writes: > Look at Jupiter ACE user manual Chapter 7, Altering word definitions: > How to correct mistakes, using LIST, EDIT and REDEFINE. Heh, I like that manual. But that doesn't look easier than a block editor to implement or use. Is it a colorforth-like tokenizing system? I can see how that can save some space, but I think it's better to store source code as text, so that formatting and comments are preserved. It's interesting that they enlarged the amount of sram from 2k (in the older fram parts) to 4k in this current one. I guess people didn't want to use fram as sram as much of the time as TI expected. Either way it seems like plenty for stacks and the more important user and system code and variables.
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.forth
csiph-web