Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #54229 > unrolled thread
| Started by | Dale Scott <dalescottnet@gmail.com> |
|---|---|
| First post | 2017-01-21 11:27 -0800 |
| Last post | 2017-01-23 18:46 -0300 |
| Articles | 20 on this page of 138 — 21 participants |
Back to article view | Back to comp.lang.forth
embedded forth Dale Scott <dalescottnet@gmail.com> - 2017-01-21 11:27 -0800
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-21 11:31 -0800
Re: embedded forth stephen@mpeforth.com - 2017-01-22 00:52 -0800
Re: embedded forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-22 17:09 +0000
Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-22 09:43 -0800
Re: embedded Forth stephen@mpeforth.com - 2017-01-22 12:19 -0800
Re: embedded Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-22 21:25 +0100
Re: embedded Forth john <anon@example.com> - 2017-01-22 21:04 +0000
Re: embedded Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-01-22 12:30 -1000
Re: embedded Forth hughaguilar96@gmail.com - 2017-01-22 20:45 -0800
Re: embedded Forth stephen@mpeforth.com - 2017-01-22 14:08 -0800
Re: embedded Forth Paul Rubin <no.email@nospam.invalid> - 2017-01-22 14:55 -0800
Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-22 20:41 -0800
Re: embedded Forth Paul Rubin <no.email@nospam.invalid> - 2017-01-22 21:19 -0800
Re: embedded Forth hughaguilar96@gmail.com - 2017-01-22 21:36 -0800
Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-22 22:09 -0800
Re: embedded Forth rickman <gnuarm@gmail.com> - 2017-01-23 04:15 -0500
Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-23 08:41 -0800
Re: embedded Forth rickman <gnuarm@gmail.com> - 2017-01-23 14:32 -0500
Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-23 11:53 -0800
Re: embedded Forth rickman <gnuarm@gmail.com> - 2017-01-23 15:10 -0500
Re: embedded Forth Paul Rubin <no.email@nospam.invalid> - 2017-01-23 14:34 -0800
Re: embedded Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-24 03:14 -0600
Re: embedded Forth rickman <gnuarm@gmail.com> - 2017-01-23 03:43 -0500
Re: embedded Forth john <anon@example.com> - 2017-01-23 10:32 +0000
keep secrets (was Re: embedded Forth) "Wolfgang Allinger" <all2001@spambog.com> - 2017-01-23 08:58 -0300
Re: keep secrets (was Re: embedded Forth) Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-23 07:47 -0500
Re: keep secrets (was Re: embedded Forth) "Wolfgang Allinger" <all2001@spambog.com> - 2017-01-23 18:18 -0300
Re: keep secrets (was Re: embedded Forth) rickman <gnuarm@gmail.com> - 2017-01-23 19:15 -0500
Re: keep secrets (was Re: embedded Forth) rickman <gnuarm@gmail.com> - 2017-01-23 14:38 -0500
Re: keep secrets (was Re: embedded Forth) "Wolfgang Allinger" <all2001@spambog.com> - 2017-01-23 18:43 -0300
Re: keep secrets (was Re: embedded Forth) rickman <gnuarm@gmail.com> - 2017-01-23 19:48 -0500
Re: keep secrets (was Re: embedded Forth) "Elizabeth D. Rather" <erather@forth.com> - 2017-01-23 16:30 -1000
Re: keep secrets (was Re: embedded Forth) rickman <gnuarm@gmail.com> - 2017-01-23 22:23 -0500
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-22 13:44 -0500
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-22 13:38 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-23 00:45 -0500
Re: embedded forth Dale Scott <dalescottnet@gmail.com> - 2017-01-22 22:44 -0800
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-23 00:48 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-23 03:51 -0500
Re: embedded forth john <anon@example.com> - 2017-01-23 10:02 +0000
Re: embedded forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-23 09:01 +0000
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-23 13:05 +0100
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-23 14:40 -0500
Re: embedded forth Mark Wills <markwills1970@gmail.com> - 2017-01-24 01:12 -0800
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-24 14:38 +0100
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-24 19:51 -0500
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-25 11:34 +0100
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-25 22:13 -0500
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-26 11:36 +0100
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-26 14:07 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-26 00:19 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-26 14:15 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-27 13:08 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-27 17:54 -0500
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-27 15:29 -0800
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-27 16:28 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-27 23:58 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-28 11:58 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 15:36 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-28 15:05 -0800
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-28 15:57 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 21:51 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 09:53 -0800
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-29 19:32 +0100
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 11:53 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-30 01:10 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 23:11 -0800
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-29 23:34 -0800
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-30 12:42 +0100
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-30 12:36 +0100
Re: embedded forth ctmalan@gmail.com - 2017-01-30 11:02 -0800
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-30 11:04 -0800
Re: embedded forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-31 04:34 -0600
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-30 12:15 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-30 10:15 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-30 12:20 -0800
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-30 14:09 -0800
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-31 03:04 +0100
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-30 20:19 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-30 17:10 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-30 14:38 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-30 23:09 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-31 09:32 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-08 18:22 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-09 01:46 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-09 05:11 -0500
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-12 01:30 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-12 10:21 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-12 19:37 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-14 13:26 -0800
Re: embedded forth Gary Bergstrom <forthprgrmr@gmail.com> - 2017-02-14 11:36 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-14 18:13 -0500
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 21:51 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 10:20 -0800
Re: embedded forth Cecil Bayona <cbayona@cbayona.com> - 2017-01-29 12:38 -0600
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 11:49 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-04 04:22 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-04 17:54 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-04 20:26 -0800
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-05 07:53 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 11:08 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 11:39 -0800
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-08 06:46 -0800
Re: embedded forth luser droog <mijoryx@yahoo.com> - 2017-02-13 19:17 -0800
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-15 06:23 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-15 11:09 -0800
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-15 15:24 -0800
Re: embedded forth jkn_gg@nicorp.f9.co.uk - 2017-02-16 09:49 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-17 09:12 -0800
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-17 12:47 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-17 16:18 -0800
Re: embedded forth luser droog <mijoryx@yahoo.com> - 2017-02-16 08:43 -0800
Re: embedded forth Alex <alex@rivadpm.com> - 2017-02-05 20:47 +0000
Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 13:36 -0800
Re: embedded forth Alex <alex@rivadpm.com> - 2017-02-05 23:18 +0000
Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 21:10 -0800
Re: embedded forth Alex <alex@rivadpm.com> - 2017-02-06 11:12 +0000
Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 21:15 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 22:45 -0800
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-06 12:04 +0100
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-08 03:08 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-08 06:39 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-08 07:15 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-08 15:49 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-09 01:14 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-09 05:19 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-09 03:48 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-05 16:08 -0500
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-07 21:59 -0500
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-28 11:10 +0100
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 06:15 -0500
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-28 19:48 +0100
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 14:37 -0500
Re: embedded forth mhx@iae.nl - 2017-01-28 07:48 -0800
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-28 19:53 +0100
Re: embedded forth mhx@iae.nl - 2017-01-28 15:49 -0800
Re: embedded forth "Wolfgang Allinger" <all2001@spambog.com> - 2017-01-23 18:46 -0300
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | Dale Scott <dalescottnet@gmail.com> |
|---|---|
| Date | 2017-01-21 11:27 -0800 |
| Subject | embedded forth |
| Message-ID | <49b3566a-3842-4f9f-a47f-a66590625fef@googlegroups.com> |
Hi all, I'm being lured by the siren song of Forth for an embedded system data logger project. It's being prototyped using the MSP432 launchpad platform and has thirty-two I2C sensors, receiving ~300Kbps of data each on all four i2c ports, and streams the data to an SD card using SD over SPI. The basic platform could have application in quite a few projects, and so I thought Forth might be the perfect development environment. I've been trying to install Mecrisp on a launchpad, but seem to be having tool version problems (an old version of DSLite is needed to load the mecrisp-stellaris bin file, but current XDS110 debug probe firmware no longer seems to support the old version of DSLite). So now I'm looking for where the Mecrisp community (and msp432 sub-community) hang out. Is this the correct forum for mecrisp forth users? What about MSP432 mecrisp users? (43.oh? Element14?) Does mecrisp seem a reasonable solution for what I'm trying to achieve? Thanks! Dale
[toc] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-01-21 11:31 -0800 |
| Message-ID | <87a8akryz7.fsf@jester.hsd1.ca.comcast.net> |
| In reply to | #54229 |
Dale Scott <dalescottnet@gmail.com> writes: > Is this the correct forum for mecrisp forth users? What about MSP432 > mecrisp users? (43.oh? Element14?) This is the best place for all things Forth. > Does mecrisp seem a reasonable solution for what I'm trying to achieve? I'd say yes, if you want to use Forth, either because Forth is interesting or because you're familiar with Forth already. If you're not used to Forth, using it effectively has a learning curve despite the language itself being very simple.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com |
|---|---|
| Date | 2017-01-22 00:52 -0800 |
| Message-ID | <aeadc354-890f-4823-bfff-5b1dcfba8ca6@googlegroups.com> |
| In reply to | #54229 |
On Saturday, 21 January 2017 20:27:07 UTC+1, Dale Scott wrote: > Hi all, I'm being lured by the siren song of Forth for an embedded system data > logger project. It's being prototyped using the MSP432 launchpad platform and > has thirty-two I2C sensors, receiving ~300Kbps of data each on all four i2c ports, > and streams the data to an SD card using SD over SPI. The basic platform could > have application in quite a few projects, and so I thought Forth might be the perfect > development environment. If someone is paying wages to get this done, you should really consider using one the professional tool chains from MPE (http://www.mpeforth.com) or Forth Inc (http://www.forth.com). The price differences will get lost in the noise of the project. The use of better tool chains usually saves money in the end. Stephen P.S. I'm the managing director at MPE.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-22 17:09 +0000 |
| Message-ID | <2017Jan22.180948@mips.complang.tuwien.ac.at> |
| In reply to | #54229 |
Dale Scott <dalescottnet@gmail.com> writes:
>Is this the correct forum for mecrisp forth users? What about MSP432 mecris=
>p users? (43.oh? Element14?)
Mecrisp is on-topic here. The Mecrisp docs may document the preferred
places for discussions, support requests etc.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Dale Scott <dalescottnet@gmail.com> |
|---|---|
| Date | 2017-01-22 09:43 -0800 |
| Message-ID | <e20554d8-a66d-4a9d-ad6c-f95fb2c1a66b@googlegroups.com> |
| In reply to | #54244 |
Thanks Stephen and Anton for your information. How difficult is it to work with new I2C and SPI hardware devices in Forth? "Difficult" is a loaded question but are there any generalities? Do protocol stacks exist for I2C? SPI? In general, how How would one develop a low-level I2C or SPI device driver in Forth compared to C? Thanks, Dale P.S. At the moment the work is sweat equity, I'm working on a feasibility prototype for a provisional patent a colleague has filed, so $$'s for pro-tools is limited at the moment (but hopefully not forever ;-)).
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com |
|---|---|
| Date | 2017-01-22 12:19 -0800 |
| Message-ID | <67e370db-ebd9-45ec-a262-7e9ce3fc3b72@googlegroups.com> |
| In reply to | #54245 |
On Sunday, 22 January 2017 18:43:16 UTC+1, Dale Scott wrote: > Thanks Stephen and Anton for your information. How difficult is it to work with new > I2C and SPI hardware devices in Forth? "Difficult" is a loaded question but are there > any generalities? Do protocol stacks exist for I2C? SPI? In general, how How would > one develop a low-level I2C or SPI device driver in Forth compared to C? You would write some code, and compile and test interactively. It's the interactivity that matters. Until you've done it you won't believe it. To assume a protocol stack for something as simple as I2C and SPI is to be a bit grandiose - it stems from operating systems not having direct hardware access. Once you have direct hardware access the world changes. MPE's I2C and SPI code uses a common set of words regardless of the hardware. For I2C we often use a simple bit-banged driver that just needs two GPIO pins. > P.S. At the moment the work is sweat equity, I'm working on a feasibility > prototype for a provisional patent a colleague has filed, so $$'s for pro-tools > is limited at the moment (but hopefully not forever ;-)). Translates to: we'll pay for hardware but not for software. The downside of this approach is that you'll waste a vast amount of time writing code that is already present in the commercial tools. You really want to implement all the SD commands for SPI, debug them and then test on a range of cards? What next, a FAT file system ... Stephen
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-22 21:25 +0100 |
| Message-ID | <o634g7$42k$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #54245 |
In article <e20554d8-a66d-4a9d-ad6c-f95fb2c1a66b@googlegroups.com>, Dale Scott <dalescottnet@gmail.com> wrote: >Thanks Stephen and Anton for your information. How difficult is it to work = >with new I2C and SPI hardware devices in Forth? "Difficult" is a loaded qu= I2C and SPI are not related to Forth but to the particular Operating System or microcontroller you're using. You cannot believe how different I2C is between 8051, Atmel, TI MSP430 and several hundreds microcontrollers neither you or I ever heard of. Almost all programs have been written in a Forth version, but that doesn't mean you can find them. 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 | john <anon@example.com> |
|---|---|
| Date | 2017-01-22 21:04 +0000 |
| Message-ID | <MPG.32ef2ed392ed127f9896e8@news.virginmedia.com> |
| In reply to | #54245 |
In article <e20554d8-a66d-4a9d-ad6c-f95fb2c1a66b@googlegroups.com>, dalescottnet@gmail.com says... > > P.S. At the moment the work is sweat equity, I'm working on a feasibility prototype for a provisional patent a colleague has filed, so $$'s for pro-tools is limited at the moment (but hopefully not forever ;-)). > > Take stephen's advice and find the funds. -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-01-22 12:30 -1000 |
| Message-ID | <zN2dncTzZ5rhrxjFnZ2dnUU7-UfNnZ2d@supernews.com> |
| In reply to | #54251 |
On 1/22/17 11:04 AM, john wrote: > In article <e20554d8-a66d-4a9d-ad6c-f95fb2c1a66b@googlegroups.com>, > dalescottnet@gmail.com says... >> >> P.S. At the moment the work is sweat equity, I'm working on a feasibility prototype for a provisional patent a colleague has filed, so $$'s for pro-tools is limited at the moment (but hopefully not forever ;-)). >> >> > > Take stephen's advice and find the funds. Stephen is right. I'm speaking for FORTH, Inc. here, although I'm now retired and no longer actually work for them. I recommend that you get the free evaluation version of SwiftX (FORTH, Inc.'s cross-development system for embedded controllers), as well as sampling MPE's products. At the very least you'll get some very detailed documentation as well as a lot of source code that will answer a lot of your questions and give you an opportunity to practice your Forth skills and judge the ease of use of the respective development chains. Check out FORTH, Inc. at www.forth.com. Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-22 20:45 -0800 |
| Message-ID | <8b7a319b-6b7a-4777-be00-35d399550bf7@googlegroups.com> |
| In reply to | #54251 |
On Sunday, January 22, 2017 at 2:04:36 PM UTC-7, john wrote: > In article <e20554d8-a66d-4a9d-ad6c-f95fb2c1a66b@googlegroups.com>, > dalescottnet@gmail.com says... > > > > P.S. At the moment the work is sweat equity, I'm working on a feasibility prototype for a provisional patent a colleague has filed, so $$'s for pro-tools is limited at the moment (but hopefully not forever ;-)). > > > > > > Take stephen's advice and find the funds. Testra had a motion-control board based on the Dallas 80c320. The code was written in UR/Forth's Forth cross-compiler, and over time almost all of it had been converted into assembly-language. It was too slow --- the competitor's MC68000 provided much higher performance --- the primary application was laser-etching which has to fast. Their solution was to build a custom Forth processor based on a Lattice isp1048 PLD. They did not "find the funds" to hire Stephen Pelc --- they found the funds to hire me --- it was very much of a shoestring budget. This worked though --- everybody involved already knew Forth, so the "sweat equity" was worth something --- there can't be any "coming up to speed" if you are going to be successful.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com |
|---|---|
| Date | 2017-01-22 14:08 -0800 |
| Message-ID | <05b4d180-c8ef-4dd9-b624-5c94e0a02fdc@googlegroups.com> |
| In reply to | #54245 |
Dale said > P.S. At the moment the work is sweat equity, I'm working on a feasibility > prototype for a provisional patent a colleague has filed, so $$'s for > pro-tools is limited at the moment (but hopefully not forever ;-)). I don't normally wear a hat as cynical as this, but ... Sweat equity means that you will make a profit later. You have already chosen your side of the time/money pair. How are you going to pay the patent lawyer? Any commercial software tool costs are peanuts compared to the lawyers' fees. I won't be so grumpy when winter is over. Stephen
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-01-22 14:55 -0800 |
| Message-ID | <87h94qemc9.fsf@nightsong.com> |
| In reply to | #54253 |
stephen@mpeforth.com writes: > Sweat equity means that you will make a profit later. You have already > chosen your side of the time/money pair. How are you going to pay the > patent lawyer? Any commercial software tool costs are peanuts compared > to the lawyers' fees. The patent lawyer only gets paid if the project produces a promising results that look worth investing money in. That's much later than the beginning of development. Commercial software tools require spending the money BEFORE finding out whether the idea is worthwhile. Free software and cheap hardware (think of Launchpad/RPi/Arduino-priced boards knocking out the $200 development boards from earlier) are attractive partly because you can get an idea and start hacking without any significant financial or personal commitment. You then make some progress or perhaps fail to make any, and THEN decide whether the project looks worth pursuing. If your idea works, you can then quit your day job, start spending money on licenses and lawyers, seek outside funding, etc. If not, you haven't lost anything except a little bit of hacking time that you can think of as hobby activity. Expensive tools flip the process around too much.
[toc] | [prev] | [next] | [standalone]
| From | Dale Scott <dalescottnet@gmail.com> |
|---|---|
| Date | 2017-01-22 20:41 -0800 |
| Message-ID | <cc5845ab-6710-4a99-9d3b-2f18403fd37b@googlegroups.com> |
| In reply to | #54259 |
> You really want to implement all the SD commands > for SPI, debug them and then test on a range of > cards? What next, a FAT file system ... Not really (wanting to write even more code from scratch), and yes, actually (FAT file system). I think I will experiment with Forth using the free MPE lite cross-compiler and an MSP430 (non-ARM) launchpad sitting on my shelf, stay the course in C for the time being for my MSP432 (ARM Cortex M4) project, and then migrate the ARM project to Forth down the road. I already have a working i2c engine, sd-over-spi (using FatFs) and some low -level i2c device drivers written in C, but only the barest skeleton of an application so far. Is it common (or preferred, or even discouraged) to re-use existing device-level C-code? Presumably one would start by creating new words in Forth that simply wrap the C-code device drivers or i2c/spi library functions. Thanks for the info from everyone. I really appreciate the help coming up to speed. Cheers, Dale
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-01-22 21:19 -0800 |
| Message-ID | <87lgu2l5f5.fsf@nightsong.com> |
| In reply to | #54270 |
Dale Scott <dalescottnet@gmail.com> writes: > I think I will experiment with Forth using the free MPE lite > cross-compiler and an MSP430 (non-ARM) launchpad sitting on my shelf, Cool, I don't remember what the MPE Lite situation is with the ARM. You could also check SwiftForth eval versions. > stay the course in C for the time being for my MSP432 (ARM Cortex M4) > project, and then migrate the ARM project to Forth down the road. You might try MicroPython (micropython.org) which supports various boards including its own, which is quite nice if a bit expensive ($45). It supports some of the ST Discovery boards but unfortunately the Launchpads might require some porting.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-22 21:36 -0800 |
| Message-ID | <e0bca367-5f85-4080-bc57-1514614c69d2@googlegroups.com> |
| In reply to | #54245 |
On Sunday, January 22, 2017 at 10:43:16 AM UTC-7, Dale Scott wrote: > Thanks Stephen and Anton for your information. How difficult is it to work with new I2C and SPI hardware devices in Forth? "Difficult" is a loaded question but are there any generalities? Do protocol stacks exist for I2C? SPI? In general, how How would one develop a low-level I2C or SPI device driver in Forth compared to C? > > Thanks, > Dale > > P.S. At the moment the work is sweat equity, I'm working on a feasibility prototype for a provisional patent a colleague has filed, so $$'s for pro-tools is limited at the moment (but hopefully not forever ;-)). Can you tell us anything about this provisional patent without giving away all the secrets in the patent? Is performance an issue? What do you have that is worth a patent, that nobody else can figure out on their own? You can't patent the obvious --- it has to be something that nobody else would be likely to figure out on their own. At Testra they had multiple patents, but had lost interest in getting any more patents --- you have to explain the whole thing in the patent, but then patent trolls will steal your idea, and then you have the expense of suing to protect your secrets that you just gave away (very expensive, and definitely not going to work against Beijing). Their solution with the MiniForth was that the PLD design can't be reverse-engineered from the PLD, so nobody could build a MiniForth processor except themselves. That was in 1994. I understand that a lot of processors now have internal non-volatile memory and have a security switch that can be set to prevent people from obtaining the code. Physical security measures such as this are your best bet --- making your code public in a patent and then relying on lawyers to sue after your code has been stolen is like leaving the barn door open and then relying on somebody to go get your horse for you after it has run off. I'm just saying --- most people who are planning on patenting something are making a huge expensive mistake --- I have never heard of any case in which this actually worked out in a profitable way for the guy with the patent.
[toc] | [prev] | [next] | [standalone]
| From | Dale Scott <dalescottnet@gmail.com> |
|---|---|
| Date | 2017-01-22 22:09 -0800 |
| Message-ID | <96ec0ab8-a01c-4867-a75d-44939434c112@googlegroups.com> |
| In reply to | #54274 |
The patent has to do with what is being measured, and how it is analyzed to determine a result (how's that for vague ;-)) Otherwise it's a basic data logger that packs as many I2C sensors in as small a space as possible, the aggregates the samples taken as fast as possible, and either stores the data data locally or sends somewhere else e.g. by WiFi. I think there could be other people in other domains with similar needs, who might appreciate such a data logger. It was the need to easily scale horizontally that made me think of Forth.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-23 04:15 -0500 |
| Message-ID | <o64hfm$qaa$1@dont-email.me> |
| In reply to | #54276 |
On 1/23/2017 1:09 AM, Dale Scott wrote: > The patent has to do with what is being measured, and how it is > analyzed to determine a result (how's that for vague ;-)) > > Otherwise it's a basic data logger that packs as many I2C sensors in > as small a space as possible, the aggregates the samples taken as > fast as possible, and either stores the data data locally or sends > somewhere else e.g. by WiFi. I think there could be other people in > other domains with similar needs, who might appreciate such a data > logger. It was the need to easily scale horizontally that made me > think of Forth. Depending on the details of what you are doing, an FPGA would not be totally out of line. If you really want not just speed, but precise timing measurement, an FPGA essentially runs everything in true parallel, not sequential multitasking like a processor does. It would be a trivial matter to run any number of I2C interfaces. But you may not really need that if the timing resolution needed is milliseconds rather than low microseconds. Can you explain what the risk area is? Is it the utility or the practicality of the algorithm rather than issues specific to implementing them in the data logger? What do you mean by scaling horizontally? Why would Forth make that easier than in other languages? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Dale Scott <dalescottnet@gmail.com> |
|---|---|
| Date | 2017-01-23 08:41 -0800 |
| Message-ID | <938e293e-6b20-4405-ac62-5fa71c1d5884@googlegroups.com> |
| In reply to | #54282 |
< an FPGA would not be totally out of line. The current system is for proof of concept. The I2C sensor using supports eight different addresses and the MSP432 has four I2C ports, and 32 sensors total will be enough for validation purposes. However the marketable system will need two hundred to a thousand sensors, and I'm thinking will probably use an FPGA to connect directly to the I2C sensors. I was thinking of implementing an I2C-to-SPI bridge in the FPGA hardware, and still use an mpu to aggregate two SPI channels and write to the SD card, and provide a UI/API to the outside world. Several FPGAs would be connected to each SPI channel and essentially time-multiplexed. The IP involved in the project relates to a very specific orientation/positioning of the sensors, and what can be gleaned about the situation from that relationship, and I think the risk in the data logger itself is relatively low. Beyond this specific project, I wonder if there could be opportunities in other fields where aggregating data from many many sensors is needed, such as a body-suit that monitors physiology for health science purposes. I have read of current research involving a network of sensors embedded in a women's bra to diagnosis potential tumours. I suspect there may also be opportunities in physical process monitoring, where a string of many closely-spaced sensors measure aspects of "something" (liquid, slurry, or a hard object) moving past the sensors. The physical limitations of the actual sensors involved and how they must be electrically interconnected (e.g. long narrow or a square array), will likely vary considerably from one application to another, although the general concept of aggregating the data (possibly including some domain-specific form of reduction or compression) remains the same. It is this situation where I thought Forth might have special benefit, and provide greater efficiencies over C for customizing the concept to a specific situation (scaling horizontally).
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-23 14:32 -0500 |
| Message-ID | <o65ll8$9v5$1@dont-email.me> |
| In reply to | #54307 |
On 1/23/2017 11:41 AM, Dale Scott wrote: > < an FPGA would not be totally out of line. > > The current system is for proof of concept. The I2C sensor using > supports eight different addresses and the MSP432 has four I2C ports, > and 32 sensors total will be enough for validation purposes. However > the marketable system will need two hundred to a thousand sensors, > and I'm thinking will probably use an FPGA to connect directly to the > I2C sensors. I was thinking of implementing an I2C-to-SPI bridge in > the FPGA hardware, and still use an mpu to aggregate two SPI channels > and write to the SD card, and provide a UI/API to the outside world. > Several FPGAs would be connected to each SPI channel and essentially > time-multiplexed. The number of sensors is not so much an issue as the data rate. I2C typically uses 7 bit addresses but some have preassigned uses, so there are 112 usable addresses on each I2C bus. To get 1000 addresses you will need a minimum of 10 busses if they will support your data rates. Do you know what data rates you need? > The IP involved in the project relates to a very specific > orientation/positioning of the sensors, and what can be gleaned about > the situation from that relationship, and I think the risk in the > data logger itself is relatively low. Beyond this specific project, I > wonder if there could be opportunities in other fields where > aggregating data from many many sensors is needed, such as a > body-suit that monitors physiology for health science purposes. I > have read of current research involving a network of sensors embedded > in a women's bra to diagnosis potential tumours. I suspect there may > also be opportunities in physical process monitoring, where a string > of many closely-spaced sensors measure aspects of "something" > (liquid, slurry, or a hard object) moving past the sensors. The > physical limitations of the actual sensors involved and how they must > be electrically interconnected (e.g. long narrow or a square array), > will likely vary considerably from one application to another, > although the general concept of aggregating the data (possibly > including some domain-specific form of reduction or compression) > remains the same. It is this situation where I thought Forth might > have special benefit, and provide greater efficiencies over C for > customizing the concept to a specific situation (scaling > horizontally). I use Forth for it's interactivity and closeness to the hardware. I'm not sure Forth has any significant advantages in other ways. I don't know what scaling horizontally means. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Dale Scott <dalescottnet@gmail.com> |
|---|---|
| Date | 2017-01-23 11:53 -0800 |
| Message-ID | <32db709d-da6f-4b11-8e6d-24a6f9663a54@googlegroups.com> |
| In reply to | #54311 |
< scaling horizontally Sorry, I mean from a marketing or product-management perspective, taking a somewhat standard product and adapting it to fit a wide range of customers who have similar high-level needs but who will still need a degree of low-level customization. This is in contrast to scaling vertically, which would mostly involve adding features to satisfy all potential customers within a specific (vertical) market.
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web