Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #24179
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation |
| Date | 2013-07-05 17:05 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <kr7c6i$end$1@dont-email.me> (permalink) |
| References | (17 earlier) <7xppuy1ce1.fsf@ruckus.brouhaha.com> <kr49qb$jia$1@dont-email.me> <7x1u7e6xg8.fsf@ruckus.brouhaha.com> <kr4b85$t1o$1@dont-email.me> <7x38ruxh8o.fsf@ruckus.brouhaha.com> |
On 7/4/2013 3:22 PM, Paul Rubin wrote: > rickman<gnuarm@gmail.com> writes: >>> the effect is in principle 4x worse for a 32-bit adder >> You don't use MCUs like anyone else I know. You look at the data they >> provide which is *chip* data. No one provides power data separately >> for each logic function on an MCU. So there is no way to analyze the >> device in this manner. > > MCUs are not made out of magic--they use well-understood design and fab > processes and the designers know how to estimate these numbers and in > principle we could do the same. Without actual numbers we can still > hopefully agree that it's bloody obvious that if two chips are made with > the same process and one of them has 4x more circuitry than the other, > the bigger one is likely to have more total leakage current than the > smaller one. That's all I'm saying here. That is the point, we don't know anything about the processes used for the various chips. Yes, if you want to talk in abstractions then sure, I agree. But what is the point of that? >>> Lack of code space, lack of ram, awkward instruction set, no compilers. >> These things (the few that are accurate... > > Which of "lack of code space", "lack of ram", "awkward instruction set", > and "no compilers" are inaccurate? > >> most of what you said about the GA144 is wrong) are limitations to you >> because you have not learned how to use the chip. That is what I >> said. You can't use any device until you learn how. > > I look at the sample code that GA has posted, and the pain level > apparent in that code, and I can only conclude that nobody knows how. I like to think I know how. I may not be a master of the GA144, but I was able to code a few routines and verified that my ideas likely would not work on the GA144, at least not the way I intended. I also found that my concept of using the cores in the same way I use FPGA components was not appreciated by the folks at GA and they are not interested in supporting that, i.e. they won't release adequate timing data to plan a design rather than just expecting the user to try stuff on an eval board and time it... Those were my problems with the company more than the chip or the tools. If you are faulting them for that, then I agree. >> You have already learned how to use conventional MCUs so you have >> already climbed up the learning curve. Now you need to climb the >> learning curve for this device. > > That sounds like a platitude. Look at that conference paper on the GA > site, where somebody spent months programming the AES encryption > function onto something like 100 cores of a GA144. Or the GA app note > about MD5, again taking months and spread across dozens of cores. Both > those algorithms can easily be coded on a conventional MCU in an > afternoon. Ok, AES encryption may not be suitable for the GA144 if it uses 100 out of 144 cores. It is also likely not suitable for the 8 bitter chips you have been talking about. I haven't read all the app notes, but I am pretty sure it doesn't take months to learn how to use the GA144. I learned what I know in a few weeks. I did not get to the point of mastering all the tools however. I will grant you that the company is doing a *lousy* job of promoting the device. I think they are also doing a lousy job of supporting the device. Every question I asked, all of which seemed to be pretty obvious questions, had to be answered individually and many had to be researched. I would have thought most of these issue would have been addressed in the docmentation. Clearly their ideas of design are different from mine. That still does not make the chip or the tools difficult to use. >> The GA144 is not inherently difficult to use for simple tasks. In >> fact, I find it much easier to use than most MCUs where you often have >> to figure out how to use a single CPU to do multiple asynchronous >> tasks, interrupts, multi-threading, etc... not simple stuff to the >> uninitiated. > > Let's take a fairly simple conceptual exercise and say you want to make > a typical, slightly fancy digital wrist watch. Ignore the notorious > hardware issues of clocking the GA144 with a crystal, Uh, I don't think you will have much luck getting any MCU without an internal oscillator to run from a crystal. So you will need an oscillator instead. If you are going to discount the device based on an app which requires functions it doesn't have then why not ask it to shoot a payload to the moon? > and assume you > have a precise 1000 hz timer toggling an input pin, and enough i/o pins > for all the LCD segments. So you have to count these timer events, and > drive an LCD display showing the current time (hours/minutes/seconds), > day of the week, and calendar day. You have to support a pushbutton UI > allowing setting the time and date, and you have to calculate the > weekday from the day/month/year, which requires taking leap years into > account. You want stopwatch and alarm functions, but we'll skip unusual > features like the sunrise/sunset time or moon phase. I have a $5 watch > that does all this stuff, so it's not outlandish. > > How would you envision the GA144 code for this being organized? On a > conventional MCU it's all very straightforward coding. You might want > to use interrupts, or you could do a single threaded polling loop. Why would you want to do polling or use interrupts in a conventional MCU? They all work at much lower power if you put them in stop state and let the 1000 Hz input wake them and run from an internal imprecise, but low power oscillator. This feature they have in common with the GA144. > MCU's usually have built-in counter/timers so you can let the hardware > divide the 1000 hz down to 1 hz for display update. The only catch is > that there's enough functions that you might need a KB or so of code. > On an MCU that's no big deal. On the GA144 it means having to split the > code across many different cores, and deal with routing communications > around between the cores, etc. Plus you have to program in a very low > level Forth subset. MCU's usually have C compilers, or (this being clf) > full featured ANS Forth which we can consider to be about equivalent. See, you *don't* understand the GA144. Splitting the code across cores is not a *requirement*, it is a *feature*!!! This makes the code simple in the same way it is simple in an FPGA. Imagine doing this in an FPGA. You would have an input counter dividing by 1000 to produce a seconds pulse followed by the seconds counter, the minutes counter..., in fact early watches were done just this way and I'm not sure they aren't still done this way. So you might assign the input counter to a single CPU in the GA144. It wakes on the positive transition of the 1 kHz input, handles the counter and (if it doesn't deal with the time itself) sends an a one Hz tick to the next node. This input timing node calculates the seconds, minutes and hours while taking into account (possibly) the leap second and outputs to another node which calculates the day, week, month and year. None of these are complex tasks and would fit easily in the available node memory. The aggregate time is passed on to the alarm node which deals with handling alarm operation and the display node with handles formatting the data for the LCD. There may be another node to control the display timing since an LCD is driven by ~30 Hz AC, but that can likely be done by the same node, it needs a timing signal from the first node that is dividing by 1000. The input timing node just has to provide the ~30 Hz output as well as a 1 Hz output. Another node is the "UI" which controls the two, three or four push buttons and sends messages to all of these nodes to set the current time. How could you possibly make this into something complex? Ah, you are used to using a single, sequential processor with all of it's complexities like needing interrupts and multiple tasks. If I had the time I would code this up for you, but I'm busy with work for a few more weeks. > It's pretty clear that if you make any realistic plan in your head about > how you'd develop the code for the two approaches, the coding hassle is > just much, much lower with the MCU. Or it is obvious that coding this app (and many others) is a snap on a multi-core chip like the GA144. Look, I understand where you are coming from. I have a different perspective because I do FPGA work which always deals with multiple processing elements. This means I already have the development model in my head. You need to give up what you have learned about sequential processing and think in terms of modularization and data flow. Its not harder, it's just different. In fact, I think it is much easier because the synchronization is built in. That can be a bear in sequential processing. -- Rick
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar
Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-06-24 11:02 +0200
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-06-24 05:54 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-06-25 10:51 +0200
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-06-25 02:29 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-06-25 14:06 +0200
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-06-25 10:34 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-06-26 11:03 +0200
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-06-26 22:18 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-06-27 12:09 +0200
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-06-27 11:15 -0400
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-06-27 09:55 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-06-27 15:02 -0400
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation visualforth@rocketmail.com - 2013-06-30 21:43 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-01 12:09 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-01 16:44 -0400
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-01 18:14 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-07-02 10:36 +0200
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Mark Wills <markrobertwills@yahoo.co.uk> - 2013-07-02 03:12 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-02 10:17 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-02 16:35 -0400
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-02 16:33 -0400
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-03 00:51 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-07-03 10:38 +0200
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-04 09:26 -0400
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-04 10:08 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-04 13:07 -0400
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-04 10:34 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-04 13:31 -0400
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-04 12:22 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-04 12:27 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-05 17:05 -0400
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-05 15:09 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-05 19:21 -0400
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-05 17:49 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-06 00:38 -0400
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-05 22:39 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-06 10:56 -0400
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-06 20:35 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-07-07 10:44 +0000
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-07 12:48 -0400
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-07 01:20 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-07-08 11:49 +0200
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation rickman <gnuarm@gmail.com> - 2013-07-08 09:55 -0400
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Roberto Waltman <usenet@rwaltman.com> - 2013-07-06 12:48 -0400
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-07-08 14:47 +0200
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-08 09:37 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation stephenXXX@mpeforth.com (Stephen Pelc) - 2013-07-09 11:32 +0000
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-07-09 14:27 +0200
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Bill Richards <billrich@gmx.com> - 2013-07-09 13:41 +0000
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-09 09:23 -0500
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-07-10 02:27 +0000
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Bill Richards <billrich@gmx.com> - 2013-07-10 07:34 +0000
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-10 03:18 -0500
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Paul Rubin <no.email@nospam.invalid> - 2013-07-10 01:43 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Brad Eckert <hwfwguy@gmail.com> - 2013-07-16 08:31 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-10 03:02 -0500
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation stephenXXX@mpeforth.com (Stephen Pelc) - 2013-07-09 15:14 +0000
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation visualforth@rocketmail.com - 2013-07-15 12:27 -0700
Re: Announcing Mecrisp-Stellaris - a native code ARM-Cortex implementation Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-07-16 11:52 +0200
csiph-web