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 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-23 15:10 -0500 |
| Message-ID | <o65ns6$imo$1@dont-email.me> |
| In reply to | #54317 |
On 1/23/2017 2:53 PM, Dale Scott wrote: > < 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. Ok I get that. I like using Forth and many here claim it has huge advantages over other languages for a variety of reasons. I like it for two simple reasons. It is interactive which makes test and debug easier and it uses a very simple tool rather than the complex and messy compile, assemble, link nonsense of languages like C. I don't see how any of that helps to support feature customization. I think any language would support that pretty well. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-01-23 14:34 -0800 |
| Message-ID | <87d1fdl824.fsf@nightsong.com> |
| In reply to | #54307 |
I don't recommend using Forth for this project unless you're already familiar with Forth. Learning a new language and its techniques at the same time as trying to get a project out the door is asking for trouble. Stick with what you know for the project, and try out Forth on the side in a more exploratory way. Learning new stuff from scratch takes a much different mindset (explore, try things out, go off in different directions) than completing a project (drill as directly as you can to the desired end result, look in the manual or web if there's some needed info that you don't know, but don't waste time learning more than the exact thing that you need). A good programmer has to be able to work in each of these mindsets, but trying to be in both at the same time creates a balancing problem.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-24 03:14 -0600 |
| Message-ID | <JdmdnTEEZdqVhhrFnZ2dnUU7-X2dnZ2d@supernews.com> |
| In reply to | #54327 |
Paul Rubin <no.email@nospam.invalid> wrote: > I don't recommend using Forth for this project unless you're already > familiar with Forth. Learning a new language and its techniques at > the same time as trying to get a project out the door is asking for > trouble. It's pretty much the only way that's ever worked for me. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-23 03:43 -0500 |
| Message-ID | <o64fl2$iim$1@dont-email.me> |
| In reply to | #54274 |
On 1/23/2017 12:36 AM, hughaguilar96@gmail.com wrote: > 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. Uh, actually you can. There are many ways to reverse engineer something. A FSM as simple as the PLD you describe would not be so hard to reverse engineer. Even if it requires monitoring the instruction/data stream from memory it is far from an impossible or even difficult job to reverse engineer a simple CPU design, especially when you have some knowledge of what it is intended to do. A logic analyzer and a few days would likely do the job. > 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. Trade secrets are fine, but don't count on the simple security fuse. It is not really a hard thing at all to get past those. Check on the web, there are lots of examples of people opening chips and reverse engineering if not outright reading the data inside or the chip design. The only real security I've seen in ICs is to have a low power static RAM with battery backup internal to your chip. That is *much* harder to get around. I see this in RAM based FPGAs. > 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. What about the guy who patented the intermittent windshield wiper? It took him a while, but eventually he won out. Copyright only protects a specific work, trade secrets can't protect you from reverse engineering and patents can be expensive to enforce. That's why I like niche applications where there is enough profit to keep me happy, but not enough for a competitor to be interested, especially the big ones. The other way to protect your work is to have a relationship with your customers that goes beyond just selling stuff. If you have custom tweaked a design for them, they just plain won't go out looking for an alternate source, especially if they are large enough. That's right, I said "large" enough. A larger company won't *care* about cutting you out to capture your profit. The company I sell to won't even consider a new design unless it is $100 million in potential sales. So clearly they won't be interested in the fraction of that which they would save by cutting me out. Also, large companies have the problem of right and left hands not knowing what the other is doing. That lets you get away with a lot. :) -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2017-01-23 10:32 +0000 |
| Message-ID | <MPG.32efec06f121180b9896ea@news.virginmedia.com> |
| In reply to | #54278 |
In article <o64fl2$iim$1@dont-email.me>, gnuarm@gmail.com says... > > Copyright only protects a specific work, trade secrets can't protect you > from reverse engineering and patents can be expensive to enforce. > Patents can also bankrupt you down the line if you tread on someone elses toes... for example by using a poor search done by a patent attorney not getting paid upfront... Getting a patent for almost anything is pretty easy - it's the consequences of having it that can be problematic. -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2017-01-23 08:58 -0300 |
| Subject | keep secrets (was Re: embedded Forth) |
| Message-ID | <DuRIrDXjQoB@allinger-307049.user.uni-berlin> |
| In reply to | #54278 |
On 23 Jan 17 at group /comp/lang/forth in article o64fl2$iim$1@dont-email.me <gnuarm@gmail.com> (rickman) wrote: > On 1/23/2017 12:36 AM, hughaguilar96@gmail.com wrote: >> [keeping SW secrets] >> 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. > Uh, actually you can. There are many ways to reverse engineer > something. A FSM as simple as the PLD you describe would not be so hard > to reverse engineer. Even if it requires monitoring the > instruction/data stream from memory it is far from an impossible or even > difficult job to reverse engineer a simple CPU design, especially when > you have some knowledge of what it is intended to do. > A logic analyzer and a few days would likely do the job. I'm shure, you never tried to reverse engineering a FORTH Code. BTDT In 1985(?) I compiled a target EPROM with a special 16bit constant for the testing of a big ADC controlled by a 8051. I gave the EPROM, the source and a description to the HW-developer and told him, that I save no copy of anything. (No RVCS exist. With 9 SW-Engineers we had a total 5MB (yes MB) of disk space on our central PDP-11. He solved the problem with the ADC board. But 1 month later he showed up with nearly the same problem. And asked me, to tell him the special constant. Of coarse I don't remember and he throwed any of may docs away, only the EPROM left. PHUGGGH! It cost me and him a hole day, just to reengineer that code to find the constant. The modified init word for the ADC didn't change, but a lot of other definitions. So I fired two LA and an ICE just to find this routine, because most of the CFAs changed in the meantime. And I have my sources of a released version some days after the special one. However it's a pain in your ass, to reverse engineer FORTH even if you have some sources and excellent knowledge of whats going on. Don't forget to generate headerless targets to make it worse. >> 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. > Trade secrets are fine, but don't count on the simple security fuse. It > is not really a hard thing at all to get past those. Check on the web, > there are lots of examples of people opening chips and reverse > engineering if not outright reading the data inside or the chip design. > The only real security I've seen in ICs is to have a low power static > RAM with battery backup internal to your chip. That is *much* harder to > get around. I see this in RAM based FPGAs. But if you combine the security fuse with some words with a lot of stack juggling a flag ( DUP DROP ROT ROLL >R R@ R> pick -ROLL OVER DROP MUL DIV XOR MOD SHIFT -SHIFT 2* 2/ ... ) on the stack with nonsense data (I think 16 entries are terrible enough) and some seconds after starting the program, another stack juggling... you retrieve the flag and stop the program: "Checksum ERROR!" I think that they need several days just to find out, that it is FORTH, especially if you don't have any hint to FORTH in your code and doc. Just to obfuscate FORTH, put a string with a hint to a very rare C, ADA or whatsoever Compiler in the target. Just to keep them busy. For some nasty customers (they want evaluation board before paying HAHAHA) I did it. The never stole a program of mine :) Another trick: put a serial number TO92 (DALLAS DSxxxx?) to the board and check this number, then you even couldn't clone the program. Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang -- Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-01-23 07:47 -0500 |
| Subject | Re: keep secrets (was Re: embedded Forth) |
| Message-ID | <20170123074719.5c5180ec@_> |
| In reply to | #54296 |
On Mon, 23 Jan 2017 08:58:00 -0300 "Wolfgang Allinger" <all2001@spambog.com> wrote: > It cost me and him a hole day, Nice! That's one of the best puns or Freudian slips, ever. The word's "whole" and "hole" are homophones. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2017-01-23 18:18 -0300 |
| Subject | Re: keep secrets (was Re: embedded Forth) |
| Message-ID | <DuRJIbLzQoB@allinger-307049.user.uni-berlin> |
| In reply to | #54300 |
On 23 Jan 17 at group /comp/lang/forth in article 20170123074719.5c5180ec@_ <NeedNotReplyHere@xrsevnneqk.cem> (Rod Pemberton) wrote: > On Mon, 23 Jan 2017 08:58:00 -0300 > "Wolfgang Allinger" <all2001@spambog.com> wrote: >> It cost me and him a hole day, > Nice! That's one of the best puns or Freudian slips, ever. The word's > "whole" and "hole" are homophones. Sorry I'm a native German :) Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang -- Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-23 19:15 -0500 |
| Subject | Re: keep secrets (was Re: embedded Forth) |
| Message-ID | <o66685$9gn$1@dont-email.me> |
| In reply to | #54324 |
On 1/23/2017 4:18 PM, Wolfgang Allinger wrote: > > On 23 Jan 17 at group /comp/lang/forth in article 20170123074719.5c5180ec@_ > <NeedNotReplyHere@xrsevnneqk.cem> (Rod Pemberton) wrote: > >> On Mon, 23 Jan 2017 08:58:00 -0300 >> "Wolfgang Allinger" <all2001@spambog.com> wrote: > >>> It cost me and him a hole day, > >> Nice! That's one of the best puns or Freudian slips, ever. The word's >> "whole" and "hole" are homophones. > > Sorry I'm a native German :) He's saying it is a play on words. Whole and hole are pronounced the same. Whole is what you meant (the full day), but by using hole it sounds like a pun that the day was wasted down a hole. Not bad even if unintentional. lol -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-23 14:38 -0500 |
| Subject | Re: keep secrets (was Re: embedded Forth) |
| Message-ID | <o65m0o$asp$1@dont-email.me> |
| In reply to | #54296 |
On 1/23/2017 6:58 AM, Wolfgang Allinger wrote: > > On 23 Jan 17 at group /comp/lang/forth in article o64fl2$iim$1@dont-email.me > <gnuarm@gmail.com> (rickman) wrote: > >> On 1/23/2017 12:36 AM, hughaguilar96@gmail.com wrote: > >>> [keeping SW secrets] > >>> 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. > >> Uh, actually you can. There are many ways to reverse engineer >> something. A FSM as simple as the PLD you describe would not be so hard >> to reverse engineer. Even if it requires monitoring the >> instruction/data stream from memory it is far from an impossible or even >> difficult job to reverse engineer a simple CPU design, especially when >> you have some knowledge of what it is intended to do. > >> A logic analyzer and a few days would likely do the job. > > I'm shure, you never tried to reverse engineering a FORTH Code. > BTDT > > In 1985(?) I compiled a target EPROM with a special 16bit constant for the > testing of a big ADC controlled by a 8051. I gave the EPROM, the source > and a description to the HW-developer and told him, that I save no copy of > anything. (No RVCS exist. With 9 SW-Engineers we had a total 5MB (yes MB) > of disk space on our central PDP-11. > > He solved the problem with the ADC board. But 1 month later he showed up > with nearly the same problem. And asked me, to tell him the special > constant. Of coarse I don't remember and he throwed any of may docs away, > only the EPROM left. PHUGGGH! It cost me and him a hole day, just to > reengineer that code to find the constant. The modified init word for the > ADC didn't change, but a lot of other definitions. So I fired two LA and > an ICE just to find this routine, because most of the CFAs changed in the > meantime. > > And I have my sources of a released version some days after the special > one. However it's a pain in your ass, to reverse engineer FORTH even if > you have some sources and excellent knowledge of whats going on. > > Don't forget to generate headerless targets to make it worse. I'm not sure how having headers makes reverse engineering easier in compiled code. Anyway, a day to reverse engineer code is not really that big a deal if you are trying to duplicate a product. A week or two would be perfectly acceptable. >>> 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. > >> Trade secrets are fine, but don't count on the simple security fuse. It >> is not really a hard thing at all to get past those. Check on the web, >> there are lots of examples of people opening chips and reverse >> engineering if not outright reading the data inside or the chip design. >> The only real security I've seen in ICs is to have a low power static >> RAM with battery backup internal to your chip. That is *much* harder to >> get around. I see this in RAM based FPGAs. > > But if you combine the security fuse with some words with a lot of stack > juggling a flag ( DUP DROP ROT ROLL >R R@ R> pick -ROLL OVER DROP MUL DIV > XOR MOD SHIFT -SHIFT 2* 2/ ... ) on the stack with nonsense data (I think > 16 entries are terrible enough) and some seconds after starting the > program, another stack juggling... you retrieve the flag and stop the > program: "Checksum ERROR!" I'm not sure what you are describing here. The security fuse is supposed to stop you from being able to read the contents of the program memory. But it only stops you from *reading* the program memory. There are other ways of getting the contents if you want to spend some money. > I think that they need several days just to find out, that it is FORTH, > especially if you don't have any hint to FORTH in your code and doc. I'm not sure that is terribly relevant. > Just to obfuscate FORTH, put a string with a hint to a very rare C, ADA or > whatsoever Compiler in the target. Just to keep them busy. > > For some nasty customers (they want evaluation board before paying HAHAHA) > I did it. The never stole a program of mine :) > > Another trick: put a serial number TO92 (DALLAS DSxxxx?) to the board and > check this number, then you even couldn't clone the program. Yeah, I've thought of that, but it is cumbersome and expensive to deal with that in production. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2017-01-23 18:43 -0300 |
| Subject | Re: keep secrets (was Re: embedded Forth) |
| Message-ID | <DuRJIuGUQoB@allinger-307049.user.uni-berlin> |
| In reply to | #54312 |
On 23 Jan 17 at group /comp/lang/forth in article o65m0o$asp$1@dont-email.me <gnuarm@gmail.com> (rickman) wrote: > On 1/23/2017 6:58 AM, Wolfgang Allinger wrote: >> >> On 23 Jan 17 at group /comp/lang/forth in article >> o64fl2$iim$1@dont-email.me <gnuarm@gmail.com> (rickman) wrote: >> >>> On 1/23/2017 12:36 AM, hughaguilar96@gmail.com wrote: >> >>>> [keeping SW secrets] >>> A logic analyzer and a few days would likely do the job. >> >> I'm shure, you never tried to reverse engineering a FORTH Code. >> BTDT >> >> In 1985(?) I compiled a target EPROM with a special 16bit constant for the >> [...] >> only the EPROM left. PHUGGGH! It cost me and him a hole day, just to >> reengineer that code to find the constant. >>[...] >> And I have my sources of a released version some days after the special >> one. However it's a pain in your ass, to reverse engineer FORTH even if >> you have some sources and excellent knowledge of whats going on. >> >> Don't forget to generate headerless targets to make it worse. > I'm not sure how having headers makes reverse engineering easier in > compiled code. Anyway, a day to reverse engineer code is not really > that big a deal if you are trying to duplicate a product. A week or two > would be perfectly acceptable. Remember, it was my own code and I knew, what to search for! So only a reverse engineering of 2 bytes. The problem to find those byte cost me one day! I'm shure you wouldn't reverse engineering this program even in 6 month. 128kB target for a 64180 with 12 HW interrupts, some of them in the 10- 20kHz range. If you miss one IR, the programm will not run correct, so your results are nonsense. Yes, with header it's a little bit easier. In the described job of 1985, there where no headers in the target, so I can't find the word with the ADC constant by just searching for the name. I knew, that name and even know, that the constant change was the only mod of this word... but... I'm shure, you never tried reverse engineering of FORTH targets. You have to single step and find out what and where NEXT is (assumed you know its a FORTH Target. Then you have to keep track of SP and RP (assumed, you know, it's FORTH) If you don't know, it's FORTH you are lost very soon. Especially if you don't realize, that it has 2 stacks. Then you can set a breakpoint to NEXT an trie to find out, what happened. That is not trivial on an embedded system with HW interrupts. Likely it won't work. >>> Trade secrets are fine, but don't count on the simple security fuse. It >>> is not really a hard thing at all to get past those. Check on the web, >>> there are lots of examples of people opening chips and reverse >>> engineering if not outright reading the data inside or the chip design. >> But if you combine the security fuse with some words with a lot of stack >> juggling a flag ( DUP DROP ROT ROLL >R R@ R> pick -ROLL OVER DROP MUL DIV >> XOR MOD SHIFT -SHIFT 2* 2/ ... ) on the stack with nonsense data (I think >> 16 entries are terrible enough) and some seconds after starting the >> program, another stack juggling... you retrieve the flag and stop the >> program: "Checksum ERROR!" > I'm not sure what you are describing here. The security fuse is > supposed to stop you from being able to read the contents of the program > memory. But it only stops you from *reading* the program memory. There > are other ways of getting the contents if you want to spend some money. It's a scenario when someone break the fuse-bit and reads the content of the program memory... >> I think that they need several days just to find out, that it is FORTH, >> especially if you don't have any hint to FORTH in your code and doc. > I'm not sure that is terribly relevant. If you don't know, it's FORTH you will be lost! >> Another trick: put a serial number TO92 (DALLAS DSxxxx?) to the board and >> check this number, then you even couldn't clone the program. > Yeah, I've thought of that, but it is cumbersome and expensive to deal > with that in production. With the right strategy you can handle that in the final test of the system. Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang -- Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-23 19:48 -0500 |
| Subject | Re: keep secrets (was Re: embedded Forth) |
| Message-ID | <o6685j$ff7$1@dont-email.me> |
| In reply to | #54326 |
On 1/23/2017 4:43 PM, Wolfgang Allinger wrote: > > On 23 Jan 17 at group /comp/lang/forth in article o65m0o$asp$1@dont-email.me > <gnuarm@gmail.com> (rickman) wrote: > >> On 1/23/2017 6:58 AM, Wolfgang Allinger wrote: >>> >>> On 23 Jan 17 at group /comp/lang/forth in article >>> o64fl2$iim$1@dont-email.me <gnuarm@gmail.com> (rickman) wrote: >>> >>>> On 1/23/2017 12:36 AM, hughaguilar96@gmail.com wrote: >>> >>>>> [keeping SW secrets] > >>>> A logic analyzer and a few days would likely do the job. >>> >>> I'm shure, you never tried to reverse engineering a FORTH Code. >>> BTDT > >>> >>> In 1985(?) I compiled a target EPROM with a special 16bit constant for the >>> [...] >>> only the EPROM left. PHUGGGH! It cost me and him a hole day, just to >>> reengineer that code to find the constant. >>> [...] >>> And I have my sources of a released version some days after the special >>> one. However it's a pain in your ass, to reverse engineer FORTH even if >>> you have some sources and excellent knowledge of whats going on. >>> >>> Don't forget to generate headerless targets to make it worse. > >> I'm not sure how having headers makes reverse engineering easier in >> compiled code. Anyway, a day to reverse engineer code is not really >> that big a deal if you are trying to duplicate a product. A week or two >> would be perfectly acceptable. > > Remember, it was my own code and I knew, what to search for! So only a > reverse engineering of 2 bytes. The problem to find those byte cost me one > day! > > I'm shure you wouldn't reverse engineering this program even in 6 month. As a comparison, I have a GPS that is quite old. We did have access to the binary program as there were updates that we could apply. I don't recall if we knew much about the format, but none of us had the development tools, just this file. The problem was there was a constant somewhere in the code that specified numbers for two WAAS satellites. Those satellites had been taken offline permanently and now the WAAS feature didn't work. So we needed to figure out how to fix this. How long do you think that took? > 128kB target for a 64180 with 12 HW interrupts, some of them in the 10- > 20kHz range. If you miss one IR, the programm will not run correct, so > your results are nonsense. > > Yes, with header it's a little bit easier. In the described job of 1985, > there where no headers in the target, so I can't find the word with the > ADC constant by just searching for the name. I knew, that name and even > know, that the constant change was the only mod of this word... but... > > I'm shure, you never tried reverse engineering of FORTH targets. No, I have not reverse engineered a Forth program, but I don't see how that is any harder than any other binary. It's just code. You have to follow the execution and find the program structure, the data structure and how the data is manipulated. It may be tedious, but it is never impossible. Ask the NSA. What do you think it takes to write the code that performs the crypto functions in portable equipment that might become compromised? It is many orders of magnitude beyond what you are describing. > You have to single step and find out what and where NEXT is (assumed you > know its a FORTH Target. Then you have to keep track of SP and RP > (assumed, you know, it's FORTH) If you don't know, it's FORTH you are lost > very soon. Especially if you don't realize, that it has 2 stacks. > > Then you can set a breakpoint to NEXT an trie to find out, what happened. > > That is not trivial on an embedded system with HW interrupts. Likely it > won't work. Don't ever fool yourself in thinking something is hard when you haven't actually tried to crack it. Heck, I have seen so many things cracked that were intentionally designed to be secure it's not funny. Why do you think they passed the DMCA in the US? Because they simply *can't* protect things by obscurity or even intentional encryption, so they made breaking that encryption a felony... which is like locking your front door, only keeps honest people honest. >>>> Trade secrets are fine, but don't count on the simple security fuse. It >>>> is not really a hard thing at all to get past those. Check on the web, >>>> there are lots of examples of people opening chips and reverse >>>> engineering if not outright reading the data inside or the chip design. > >>> But if you combine the security fuse with some words with a lot of stack >>> juggling a flag ( DUP DROP ROT ROLL >R R@ R> pick -ROLL OVER DROP MUL DIV >>> XOR MOD SHIFT -SHIFT 2* 2/ ... ) on the stack with nonsense data (I think >>> 16 entries are terrible enough) and some seconds after starting the >>> program, another stack juggling... you retrieve the flag and stop the >>> program: "Checksum ERROR!" > >> I'm not sure what you are describing here. The security fuse is >> supposed to stop you from being able to read the contents of the program >> memory. But it only stops you from *reading* the program memory. There >> are other ways of getting the contents if you want to spend some money. > > It's a scenario when someone break the fuse-bit and reads the content of > the program memory... I can't say I follow. >>> I think that they need several days just to find out, that it is FORTH, >>> especially if you don't have any hint to FORTH in your code and doc. > >> I'm not sure that is terribly relevant. > > If you don't know, it's FORTH you will be lost! Hardly. It's just a bunch of either subroutine calls or jumps through lists. I think someone would get the hang of that pretty quickly. It's no rocket science. >>> Another trick: put a serial number TO92 (DALLAS DSxxxx?) to the board and >>> check this number, then you even couldn't clone the program. > >> Yeah, I've thought of that, but it is cumbersome and expensive to deal >> with that in production. > > With the right strategy you can handle that in the final test of the > system. But it is extra time spent on every unit. Time is money and the DSxxxx parts aren't as cheap as they should be. I've never seen one that is under $0.50 at any quantity including the one that is barely more than a serial number. Besides, this is also not secure. If I have one of these boards, I can find the key in the FPGA and set my own, or I can read the serial number in the Dallas part and use my own MCU that outputs the same number in the same way. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-01-23 16:30 -1000 |
| Subject | Re: keep secrets (was Re: embedded Forth) |
| Message-ID | <z7SdnTOuBYDSIRvFnZ2dnUU7-QfNnZ2d@supernews.com> |
| In reply to | #54330 |
On 1/23/17 2:48 PM, rickman wrote: > On 1/23/2017 4:43 PM, Wolfgang Allinger wrote: ... >> Yes, with header it's a little bit easier. In the described job of 1985, >> there where no headers in the target, so I can't find the word with the >> ADC constant by just searching for the name. I knew, that name and even >> know, that the constant change was the only mod of this word... but... >> >> I'm shure, you never tried reverse engineering of FORTH targets. > > No, I have not reverse engineered a Forth program, but I don't see how > that is any harder than any other binary. It's just code. You have to > follow the execution and find the program structure, the data structure > and how the data is manipulated. It may be tedious, but it is never > impossible. Ask the NSA. What do you think it takes to write the code > that performs the crypto functions in portable equipment that might > become compromised? It is many orders of magnitude beyond what you are > describing. > > >> You have to single step and find out what and where NEXT is (assumed you >> know its a FORTH Target. Then you have to keep track of SP and RP >> (assumed, you know, it's FORTH) If you don't know, it's FORTH you are >> lost >> very soon. Especially if you don't realize, that it has 2 stacks. >> >> Then you can set a breakpoint to NEXT an trie to find out, what happened. That's assuming there is a recognizable NEXT, which isn't true in all implementations. >> That is not trivial on an embedded system with HW interrupts. Likely it >> won't work. > > Don't ever fool yourself in thinking something is hard when you haven't > actually tried to crack it. Heck, I have seen so many things cracked > that were intentionally designed to be secure it's not funny. Why do > you think they passed the DMCA in the US? Because they simply *can't* > protect things by obscurity or even intentional encryption, so they made > breaking that encryption a felony... which is like locking your front > door, only keeps honest people honest. > > ... >> >> If you don't know, it's FORTH you will be lost! > > Hardly. It's just a bunch of either subroutine calls or jumps through > lists. I think someone would get the hang of that pretty quickly. It's > no rocket science. ...along with just plain code. But the "bunches" tend to be very short (a dozen instructions or fewer), and calls/jumps are to a vast number of places. A program of any complexity will have a few thousand defined words, with calls all over the place, so it's hard to find a logical progression of actions. A friend of mine (non-Forth) tried reading a Forth listing once, looking up the word names. He complained that he would put his finger in a page and look something up, but then to understand that he had to look something else up, and he quickly ran out of fingers. Dealing with a binary program is a lot harder. Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-23 22:23 -0500 |
| Subject | Re: keep secrets (was Re: embedded Forth) |
| Message-ID | <o66h8b$unn$1@dont-email.me> |
| In reply to | #54335 |
On 1/23/2017 9:30 PM, Elizabeth D. Rather wrote: > On 1/23/17 2:48 PM, rickman wrote: >> On 1/23/2017 4:43 PM, Wolfgang Allinger wrote: > ... >>> Yes, with header it's a little bit easier. In the described job of 1985, >>> there where no headers in the target, so I can't find the word with the >>> ADC constant by just searching for the name. I knew, that name and even >>> know, that the constant change was the only mod of this word... but... >>> >>> I'm shure, you never tried reverse engineering of FORTH targets. >> >> No, I have not reverse engineered a Forth program, but I don't see how >> that is any harder than any other binary. It's just code. You have to >> follow the execution and find the program structure, the data structure >> and how the data is manipulated. It may be tedious, but it is never >> impossible. Ask the NSA. What do you think it takes to write the code >> that performs the crypto functions in portable equipment that might >> become compromised? It is many orders of magnitude beyond what you are >> describing. >> >> >>> You have to single step and find out what and where NEXT is (assumed you >>> know its a FORTH Target. Then you have to keep track of SP and RP >>> (assumed, you know, it's FORTH) If you don't know, it's FORTH you are >>> lost >>> very soon. Especially if you don't realize, that it has 2 stacks. >>> >>> Then you can set a breakpoint to NEXT an trie to find out, what >>> happened. > > That's assuming there is a recognizable NEXT, which isn't true in all > implementations. > >>> That is not trivial on an embedded system with HW interrupts. Likely it >>> won't work. >> >> Don't ever fool yourself in thinking something is hard when you haven't >> actually tried to crack it. Heck, I have seen so many things cracked >> that were intentionally designed to be secure it's not funny. Why do >> you think they passed the DMCA in the US? Because they simply *can't* >> protect things by obscurity or even intentional encryption, so they made >> breaking that encryption a felony... which is like locking your front >> door, only keeps honest people honest. >> >> > ... >>> >>> If you don't know, it's FORTH you will be lost! >> >> Hardly. It's just a bunch of either subroutine calls or jumps through >> lists. I think someone would get the hang of that pretty quickly. It's >> no rocket science. > > ...along with just plain code. But the "bunches" tend to be very short > (a dozen instructions or fewer), and calls/jumps are to a vast number of > places. A program of any complexity will have a few thousand defined > words, with calls all over the place, so it's hard to find a logical > progression of actions. A friend of mine (non-Forth) tried reading a > Forth listing once, looking up the word names. He complained that he > would put his finger in a page and look something up, but then to > understand that he had to look something else up, and he quickly ran out > of fingers. Dealing with a binary program is a lot harder. Harder is not the same as hard. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-22 13:44 -0500 |
| Message-ID | <o62uf1$5ib$1@dont-email.me> |
| In reply to | #54229 |
On 1/21/2017 2:27 PM, 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. > > 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 I've worked with Mecrisp, but it was on an ARM based launchpad. I recall I had trouble loading the download driver as TI never bothered to get it signed, so installing it required jumping through all manner of hoops. Instead I used a Raspberry Pi where the appropriate driver worked just fine. I ended up controlling the target board remotely from my PC which worked ok until I needed to reset it. Then I used sneaker net. I did have trouble figuring out how to use a terminal emulator in the pi. Seems just a plain command window is actually a "terminal" and the support for terminal emulators is very crude. The programs I found did not work as documented and I had to figure out ways around the issues. It's been a couple of years, so I don't recall much of the details. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-01-22 13:38 -0800 |
| Message-ID | <87lgu2epwg.fsf@nightsong.com> |
| In reply to | #54246 |
rickman <gnuarm@gmail.com> writes: > On 1/21/2017 2:27 PM, Dale Scott wrote: >> It's being prototyped using the MSP432 launchpad platform > I've worked with Mecrisp, but it was on an ARM based launchpad. The MSP432 is an ARM based line, whose name resembles the older 16-bit MSP430 line, presumably to call attention to its low-power emphasis. The MSP432 launchpad is a nice little board for $12.99 USD http://www.ti.com/tool/msp-exp432p401r A 48 mhz Cortex M4F with 256k flash, 64k ram, 24 channel adc and other i/o galore, all supposedly running at 80 uA/Mhz. Impressive. I agree with Stephen that Dale will likely have an easier time with MPEforth than Mecrisp, and I'm sympathetic to "Translates to: we'll pay for hardware but not for software." In reality though, the software is an OOM more expensive than the hardware so there's a higher entry barrier.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-23 00:45 -0500 |
| Message-ID | <o6456j$gj6$1@dont-email.me> |
| In reply to | #54252 |
On 1/22/2017 4:38 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> On 1/21/2017 2:27 PM, Dale Scott wrote: >>> It's being prototyped using the MSP432 launchpad platform >> I've worked with Mecrisp, but it was on an ARM based launchpad. > > The MSP432 is an ARM based line, whose name resembles the older 16-bit > MSP430 line, presumably to call attention to its low-power emphasis. > The MSP432 launchpad is a nice little board for $12.99 USD > > http://www.ti.com/tool/msp-exp432p401r > > A 48 mhz Cortex M4F with 256k flash, 64k ram, 24 channel adc and other > i/o galore, all supposedly running at 80 uA/Mhz. Impressive. Yeah, that rings a bell now. I think naming a TI ARM chip MSP4xx is rather confusing, if not misleading. Don't know that I have an MSP432 board, but I have a couple of TI ARM boards, one is actually a Stellaris board with a potentiometer and a very small OLED display. I used it in a contest and wrote a Sudoku solver, level 1 I would say. It could solve some fairly simple Sudoku puzzles. I coded this in C and it ended up using most of the 16 kB available on the board. I find that sort of tool to be a PITA to manage so rather than try to figure out how to optimize the library usage, etc. I started to recode it in Forth. I don't think I ever finished that. > I agree with Stephen that Dale will likely have an easier time with > MPEforth than Mecrisp, and I'm sympathetic to "Translates to: we'll pay > for hardware but not for software." In reality though, the software is > an OOM more expensive than the hardware so there's a higher entry > barrier. Certainly in the start up mode where you can use $10 launchpads, yes. It's not hard to be an OOM more expensive than that, even two OOMs, if I remember the price of the commercial tools. But all tools have a learning curve that adds greatly to the cost of using. In the end it may swamp out the cost of the tool. Unfortunately Mecrisp is not nearly as well documented, so the commercial tools are likely more cost effective there too. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Dale Scott <dalescottnet@gmail.com> |
|---|---|
| Date | 2017-01-22 22:44 -0800 |
| Message-ID | <c0540ee8-44f8-4364-bf7b-f2947453ce12@googlegroups.com> |
| In reply to | #54275 |
I'm still not clear about the lineage, it feels like TI may have been finding its way. I think the Stellaris line was intended for high-speed machine control, I'm not sure where the Beaglebone processor fits (similar performance to RPi). The focus of the MSP432 line is the power of a Cortex M4F with the low power and peripheral set of the 16-bit MSP430 line. TI has done a great job of support with an Eclipse IDE and BSD-like code licensing, and US$10'ish LaunchPads, but of course all the provided source is C code. Anyway, before getting too far off topic, I think TI have been doing a great job and although ST released inexpensive ARM parts first, I hope the commercial Forth vendors have plans to support TI as well.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-01-23 00:48 -0800 |
| Message-ID | <87h94qkvqb.fsf@nightsong.com> |
| In reply to | #54277 |
Dale Scott <dalescottnet@gmail.com> writes: > I'm still not clear about the lineage, it feels like TI may have been > finding its way. I think the Stellaris line was intended for > high-speed machine control, I'm not sure where the Beaglebone > processor fits (similar performance to RPi). The Beaglebone like the RPi is a mobile phone-like cpu wrapped in a dev board. It has a lot more i/o than the rpi and its cpu (single core) is somewhat faster than the single core rpi's, but the new rpis with 4 cores can compute a lot more. The BB might still be interesting for what you're doing. It's easy to program Linux, and there are a pair of fast (200mhz) realtime coprocessors that can handle stuff like signal acquisition. They however are a pain to program and I don't know how many of the BB i/o pins they can access. If it's just lots of I2C channels that you're logging, maybe you want an FPGA to aggregate them all. Or even a GA144, heh.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-23 03:51 -0500 |
| Message-ID | <o64g3s$kb6$1@dont-email.me> |
| In reply to | #54277 |
On 1/23/2017 1:44 AM, Dale Scott wrote: > I'm still not clear about the lineage, it feels like TI may have been > finding its way. I think the Stellaris line was intended for > high-speed machine control, I'm not sure where the Beaglebone > processor fits (similar performance to RPi). The focus of the MSP432 > line is the power of a Cortex M4F with the low power and peripheral > set of the 16-bit MSP430 line. TI has done a great job of support > with an Eclipse IDE and BSD-like code licensing, and US$10'ish > LaunchPads, but of course all the provided source is C code. Anyway, > before getting too far off topic, I think TI have been doing a great > job and although ST released inexpensive ARM parts first, I hope the > commercial Forth vendors have plans to support TI as well. The Stellaris line is really just generic MCU stuff. They were looking for an edge so they designed in some PWM stuff early on. Later they branched out a bit before TI bought them. TI has several ARM lines which each has very different applications. There are RT processors which are redundant, intended for safety critical systems. The A processors are higher performance intended for use with an OS running "apps". I suppose they get used some without an OS, but I don't know what for. They are all separate lines and there is not much point in worrying about how they interrelate in my opinion. Lots of people have inexpensive ARM parts. NXP was at the head of the list for a long time. Atmel is not to be sneezed at either. Some are newer and more focused. I don't remember all the names. At one time I had a spread sheet of all the common ARM MCU devices that quickly got too large to manage. I had it up on my gnuarm.com web site where someone else would post gnuarm tools. He gave up the gnuarm toolset for another one he liked better and eventually I let the site go. Now it would cost you well over $1000 to buy that domain name because of the traffic that still shows up looking to download those tools, lol. -- Rick C
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web