Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #41625 > unrolled thread
| Started by | dunno <dunno@dunno.dunno> |
|---|---|
| First post | 2015-08-31 07:20 +0000 |
| Last post | 2015-09-14 18:21 -0700 |
| Articles | 20 on this page of 115 — 25 participants |
Back to article view | Back to comp.lang.forth
GA144 use cases dunno <dunno@dunno.dunno> - 2015-08-31 07:20 +0000
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-08-31 09:55 -0400
Re: GA144 use cases Syd Rumpo <usenet@nononono.co.uk> - 2015-08-31 16:49 +0100
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-08-31 18:35 -0400
Re: GA144 use cases Dennis Ruffer <daruffer@gmail.com> - 2015-08-31 19:08 -0700
Re: GA144 use cases Mux <Yvo.Zoer@gmail.com> - 2015-09-02 10:57 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-02 14:17 -0400
Re: GA144 use cases Mux <Yvo.Zoer@gmail.com> - 2015-09-02 11:28 -0700
Re: GA144 use cases hughaguilar96@gmail.com - 2015-09-02 13:41 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-02 16:50 -0400
Re: GA144 use cases Mux <Yvo.Zoer@gmail.com> - 2015-09-02 15:03 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-02 18:18 -0400
Re: GA144 use cases Mux <Yvo.Zoer@gmail.com> - 2015-09-02 16:14 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-02 20:40 -0400
Re: GA144 use cases Greg <borota@gmail.com> - 2015-09-02 17:53 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-02 21:25 -0400
Re: GA144 use cases Mux <Yvo.Zoer@gmail.com> - 2015-09-02 22:28 -0700
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-02 22:53 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-03 11:32 -0400
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-03 11:57 -0700
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-03 10:35 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-03 15:54 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-03 16:11 +0000
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-03 13:06 -0400
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-04 08:07 +0000
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-04 11:49 -0400
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-05 11:06 +0000
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-05 09:05 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-05 12:59 -0400
Re: GA144 use cases mhx@iae.nl - 2015-09-05 10:56 -0700
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-06 14:29 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-03 22:08 +0200
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-03 14:00 -0700
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-04 01:28 +0200
Re: GA144 use cases franck.bensusan@gmail.com - 2015-09-03 23:04 -0700
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-04 08:24 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-04 15:09 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-05 15:10 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-05 22:04 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-06 14:51 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-06 22:51 +0200
Re: GA144 use cases Greg <borota@gmail.com> - 2015-09-06 17:30 -0700
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-04 22:27 -0700
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-05 13:07 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-05 11:22 +0000
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-04 08:14 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-04 15:13 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-05 16:06 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-05 21:05 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-06 14:37 +0000
Re: GA144 use cases Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-11-30 04:17 -0600
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-01 23:06 +0100
Re: GA144 use cases Mark Wills <markwills1970@gmail.com> - 2015-09-03 00:05 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-03 13:08 -0400
Re: GA144 use cases forther <forther@gmail.com> - 2015-09-07 11:26 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-02 15:15 -0400
Re: GA144 use cases forther <forther@gmail.com> - 2015-09-07 11:21 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-11-30 16:33 -0500
Re: GA144 use cases forther <forther@gmail.com> - 2015-12-03 12:12 -0800
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-12-03 16:10 -0500
Re: GA144 use cases Jason Damisch <jasondamisch@yahoo.com> - 2015-09-02 12:10 -0700
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-03 01:27 -0700
Re: GA144 use cases Syd Rumpo <usenet@nononono.co.uk> - 2015-09-03 13:32 +0100
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-03 11:32 -0400
Re: GA144 use cases mhx@iae.nl (Marcel Hendrix) - 2015-09-03 18:57 +0200
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-03 23:58 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-04 07:52 +0000
Re: GA144 use cases Waldek Hebisch <hebisch@antispam.uni.wroc.pl> - 2015-09-05 16:32 +0000
Re: GA144 use cases mhx@iae.nl - 2015-09-05 10:52 -0700
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-05 22:11 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-06 14:18 +0000
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-07 07:49 +0000
Re: GA144 use cases Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2015-09-05 23:42 +0000
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-05 17:25 -0700
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-07 03:18 -0700
Re: GA144 use cases Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-09-07 03:31 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-07 15:06 -0400
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-08 21:41 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-09 02:54 -0400
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-09 03:02 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-09 16:55 -0400
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-09 20:12 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-09 23:40 -0400
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-09 23:43 -0400
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-10 00:07 -0400
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-09 21:55 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-10 01:43 -0400
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-09 23:49 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-10 14:43 -0400
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-10 16:10 -0400
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-12 03:15 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-12 10:28 -0400
Re: GA144 use cases Greg <abiforth@gmail.com> - 2015-09-13 13:05 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-13 18:59 -0400
Re: GA144 use cases Greg <abiforth@gmail.com> - 2015-09-13 18:42 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-13 22:47 -0400
Re: GA144 use cases Greg <abiforth@gmail.com> - 2015-09-13 21:24 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-14 02:00 -0400
Re: GA144 use cases borota@gmail.com - 2015-09-14 08:35 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-14 12:06 -0400
Re: GA144 use cases borota@gmail.com - 2015-09-14 09:33 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-14 13:25 -0400
Re: GA144 use cases Greg <borota@gmail.com> - 2015-09-14 14:17 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-14 18:12 -0400
Re: GA144 use cases Greg <schmegner@gmail.com> - 2015-09-14 18:15 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-14 22:16 -0400
Re: GA144 use cases Greg <borota@gmail.com> - 2015-09-18 14:50 -0700
Re: GA144 use cases Jason Damisch <jasondamisch@yahoo.com> - 2015-09-18 15:11 -0700
Re: GA144 use cases Greg <borota@gmail.com> - 2015-09-19 05:32 -0700
Re: GA144 use cases Dennis Ruffer <daruffer@gmail.com> - 2015-09-19 08:39 -0700
Re: GA144 use cases Greg <borota@gmail.com> - 2015-09-20 19:03 -0700
Re: GA144 use cases Dennis Ruffer <daruffer@gmail.com> - 2015-09-21 06:44 -0700
Re: GA144 use cases Dennis Ruffer <daruffer@gmail.com> - 2015-09-22 13:10 -0700
Re: GA144 use cases Mark Wills <markwills1970@gmail.com> - 2015-09-18 16:18 -0700
Re: GA144 use cases schmegner@gmail.com - 2015-09-14 18:21 -0700
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-09 16:55 -0400 |
| Message-ID | <msq680$58i$1@dont-email.me> |
| In reply to | #41888 |
On 9/9/2015 6:02 AM, Stefan Mauerhofer wrote: > Am Mittwoch, 9. September 2015 08:54:21 UTC+2 schrieb rickman: >> On 9/9/2015 12:41 AM, Stefan Mauerhofer wrote: >>> Am Montag, 7. September 2015 21:06:58 UTC+2 schrieb rickman: >>>> >>>> Did anyone else explore the world of crystal oscillators with >>>> the GA144? >>>> >>>> -- >>>> >>>> Rick >>> >>> Hi Rick >>> >>> Thanks for the info about other low power devices. It seems quite >>> obvious to shut down the high speed clock and run a low speed >>> clock to monitor the wake-up condition. >>> >>> Regarding your question: Yes, I did. I could start and keep >>> running crystals up to 16 MHz without any external electronics or >>> manipulating the voltage or temperature. >> >> Did you ever publish your code? Chuck was not able to start a 10 >> MHz crystal oscillator due to the lack of adequate resolution in >> his timing method, the software loop. How do you get yours going? >> >> -- >> >> Rick > > Hi Rick > > I am planning to publish the code this year. The problem is that > currently I have other priorities. You are right, the software loop > resolution is not sufficient. By spreading the code & data over 4 > nodes I could increase the average resolution of the software loop. I > am using 1 node to hold 64 software loop counter. 1 node is > calculating the in-between values with a kind of Bresenham algorithm > and write them to the data node. 1 node is controlling the search > algorithm and the last node is controlling the I/O pin, sense the > feedback from the crystal and report the result back. I am not happy > with the result yet, because I had a 2 MHz crystal, which would not > run with my program. So I need some more investigation on what is > happening with the crystals. I was astonished, that I could start and > lock on a 16 MHz crystal. I tried about 20 different crystals from 32 > kHz to 18 MHz. I could excite every crystal (even the 2 MHz) up to 16 > MHz. Beyond 16 MHz the F18A node was to slow to create a stable > frequency with a software loop. I'm not clear on how you obtain adequate resolution in the timing node. I can see the possibility of using alternate pathways with different instruction timing. Is that what you mean? I'm not sure how the Bresenham algorithm might be used for this. Are you saying you dither ± a loop count so that you ping the crystal at the right rate on average? That could work, but how do you deal with the timing variations caused by PVT (Process, Voltage and Temperature)? Start up times for a crystal would be greatly extended if you had to sweep looking for the right rate. I'm not an analog guy, so I can't explain in great detail how an oscillator works. I have wondered what crystal parameters will matter to a digital oscillator. I see this has gotten far off topic for the group. Any interest in discussing this in a group where others know more about such things? I might start a discussion in sci.electronics.design. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-09-09 20:12 -0700 |
| Message-ID | <8737ynt1b2.fsf@jester.gateway.pace.com> |
| In reply to | #41905 |
rickman <gnuarm@gmail.com> writes: > I see this has gotten far off topic for the group. Any interest in > discussing this in a group where others know more about such things? It's about a Forth chip, so I'd say it's on-topic.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-09 23:40 -0400 |
| Message-ID | <msqtv8$b7f$1@dont-email.me> |
| In reply to | #41909 |
On 9/9/2015 11:12 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> I see this has gotten far off topic for the group. Any interest in >> discussing this in a group where others know more about such things? > > It's about a Forth chip, so I'd say it's on-topic. But it's not really, in fact stack chips are not automatically "forth" chips. The real point is that we were talking about digital oscillators which has nearly nothing to do with Forth while there are other groups where it would fit right in. Let me say this, which at least applies to the GA144 which is as close to a Forth chip as you can get. The whole reason we are discussing a digital oscillator is because the philosophy to the GA144 is to provide a minimum variety of capability which can be adapted to a variety of needs. Virtually all embedded applications require timing information (a clock) even if they don't need it to make the logic work. The GA144 has no provision to add a crystal oscillator, I can only assume because it was felt this could be done with the available circuitry. But no one at GA has bitten the bullet to demonstrate this capability. This is true for many functions needed of MCUs used in conventional applications. There is an assumption that each developer will be happy to roll their own widget interface or function while more conventional MCUs provide the needed logic or software out of the box. It's as if the GA144 was birthed, then laid in a crib and abandoned by the parents. I'm curious about what the folks who developed a hearing aid application did for a clock? I can't imagine using the ADC or DAC without a clock. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-09 23:43 -0400 |
| Message-ID | <msqu5c$bkr$1@dont-email.me> |
| In reply to | #41909 |
On 9/9/2015 11:12 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> I see this has gotten far off topic for the group. Any interest in >> discussing this in a group where others know more about such things? > > It's about a Forth chip, so I'd say it's on-topic. I wrote a slightly long post continuing the conversation on the GA144 but Thunderbird lost it. Oh well... -- Rick
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-10 00:07 -0400 |
| Message-ID | <msqvj6$d3i$3@dont-email.me> |
| In reply to | #41914 |
On 9/9/2015 11:43 PM, rickman wrote: > On 9/9/2015 11:12 PM, Paul Rubin wrote: >> rickman <gnuarm@gmail.com> writes: >>> I see this has gotten far off topic for the group. Any interest in >>> discussing this in a group where others know more about such things? >> >> It's about a Forth chip, so I'd say it's on-topic. > > I wrote a slightly long post continuing the conversation on the GA144 > but Thunderbird lost it. Oh well... I guess not. Seems I misunderstood the prompts I got. Glad I didn't go at it again... -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Stefan Mauerhofer <smauerhofer@androsoft.ch> |
|---|---|
| Date | 2015-09-09 21:55 -0700 |
| Message-ID | <66783d4e-9cff-49ca-b7ac-b59856d17ab3@googlegroups.com> |
| In reply to | #41916 |
Since this post is about the GA144 I will post some (very short) code for this chip. Yes Rick, in the GA144 we have no time base whatsoever. The (almost) only thing we have that goes into this direction is a counted loop. The smallest loop for a F18A is "for unext". The unext instruction is in slot 0 and its execution time is around 2 ns. If we call the counted loop with a parameter n on top of the stack we have an delay of (n+1)*2 ns. The next longer counted loop is (n+1) with a delay of (n+2)*2 ns. So what can we do if we want a delay between these discrete points? We could alternate the loop values between n and n+1. If we feed the loop with an alternate sequence of values n n+1 (n n+1 n n+1 ...), then we get a average delay that is roughly (n + 1.5)*2 ns. If we want a higher resolution then we must enlarge the (n n+1) pattern. I am using a pattern of size 64. I could send 63 n and 1 n+1 value to the counted loop. This gives me a delay of (n + 1 + (1/64)) * 2 ns delay. If I send 62 n and 2 n+1 then the average delay is (n + 1 + (2/64)) * 2 ns. we could go on until we reach 1 n and 63 n+1 values (average delay of (n + 1 + (63/64)) * 2 ns. This is the basic mechanism to increase the time resolution of a counted loop. The Bresenham algorithm is used to distribute the n and n+1 values as evenly as possible. Starting a crystal means to pump energy into the crystal, thus converting electrical energy into mechanical energy. The energy is most easily transmitted if we pump the energy with the crystal's resonance frequency. If we don't hit the resonance frequency then our energy will dissipate and the crystal will not oscillate. Since we don't know the exact delay of a unext loop, which is dependent of the voltage, temperature and chip fabrication, we must scan through a range of delay values until we hit the crystal's resonance frequency. I hope this explains the method to start a 16 MHz crystal with a GA144.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-10 01:43 -0400 |
| Message-ID | <msr55v$tar$1@dont-email.me> |
| In reply to | #41917 |
On 9/10/2015 12:55 AM, Stefan Mauerhofer wrote: > Since this post is about the GA144 I will post some (very short) code for this chip. > > Yes Rick, in the GA144 we have no time base whatsoever. The (almost) only thing we have that goes into this direction is a counted loop. The smallest loop for a F18A is "for unext". The unext instruction is in slot 0 and its execution time is around 2 ns. If we call the counted loop with a parameter n on top of the stack we have an delay of (n+1)*2 ns. The next longer counted loop is (n+1) with a delay of (n+2)*2 ns. > > So what can we do if we want a delay between these discrete points? We could alternate the loop values between n and n+1. If we feed the loop with an alternate sequence of values n n+1 (n n+1 n n+1 ...), then we get a average delay that is roughly (n + 1.5)*2 ns. > > If we want a higher resolution then we must enlarge the (n n+1) pattern. I am using a pattern of size 64. I could send 63 n and 1 n+1 value to the counted loop. This gives me a delay of (n + 1 + (1/64)) * 2 ns delay. If I send 62 n and 2 n+1 then the average delay is (n + 1 + (2/64)) * 2 ns. we could go on until we reach 1 n and 63 n+1 values (average delay of (n + 1 + (63/64)) * 2 ns. This is the basic mechanism to increase the time resolution of a counted loop. > > The Bresenham algorithm is used to distribute the n and n+1 values as evenly as possible. I don't recall exactly the Bresenham algorithm, but I'd be willing to bet it ends up being the same as an NCO, numerically controlled oscillator. The average frequency is the ratio of two integers, the step size and the counter modulus. This is an often used algorithm for generating a frequency with as much precision as required. > Starting a crystal means to pump energy into the crystal, thus converting electrical energy into mechanical energy. The energy is most easily transmitted if we pump the energy with the crystal's resonance frequency. If we don't hit the resonance frequency then our energy will dissipate and the crystal will not oscillate. I seem to recall the info I read at GA on their oscillator attempt put out a ping, a minimum width impulse into the crystal. That is likely more than enough for maintaining the energy in the crystal, but to start it a square wave might work better to put more energy in more quickly. Which did you do at the start? > Since we don't know the exact delay of a unext loop, which is dependent of the voltage, temperature and chip fabrication, we must scan through a range of delay values until we hit the crystal's resonance frequency. Do you stimulate the crystal for a fixed amount of time at a given frequency? Or do you "look" for the crystal oscillating in response to your stimulus? I guess it is likely both, stimulate for a time and then look. If no input back from the crystal, move on to the next frequency. What range of timing values do you cover? > I hope this explains the method to start a 16 MHz crystal with a GA144. Yes, this is as expected. The interesting part will be to see how long it takes to get a crystal started in the worst case which is likely one or the other temperature extreme. I know that many MCU makers don't specify their crystal oscillators very well. I have had to ask manufacturers for more info which in one case found it's way into the data sheet. The trick here will be to get well specified operation for specified crystals. But then I am thinking like a potential GA customer and this is not being done by GA, but by you. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Stefan Mauerhofer <smauerhofer@androsoft.ch> |
|---|---|
| Date | 2015-09-09 23:49 -0700 |
| Message-ID | <7a289415-dc93-49b6-b3f9-6aab53a23160@googlegroups.com> |
| In reply to | #41918 |
> I don't recall exactly the Bresenham algorithm, but I'd be willing to > bet it ends up being the same as an NCO, numerically controlled > oscillator. The average frequency is the ratio of two integers, the > step size and the counter modulus. This is an often used algorithm for > generating a frequency with as much precision as required. Yes, you are right. I am using this algorithm. > I seem to recall the info I read at GA on their oscillator attempt put > out a ping, a minimum width impulse into the crystal. That is likely > more than enough for maintaining the energy in the crystal, but to start > it a square wave might work better to put more energy in more quickly. > Which did you do at the start? I am using a square wave for starting the crystal. > Do you stimulate the crystal for a fixed amount of time at a given > frequency? Or do you "look" for the crystal oscillating in response to > your stimulus? I guess it is likely both, stimulate for a time and then > look. If no input back from the crystal, move on to the next frequency. > What range of timing values do you cover? The crystal is stimulated for a fixed amount of square wave cycles (to avoid measuring the elapsed time). Then the pin is switched to input to check if there is a transition coming back from the crystal. Initially I used way too long wires to connect the crystal to the EvalBoard, so a nearby power line could induce a 60 Hz signal, messing up the whole process. If no transition is detected for a certain time, then the next frequency is selected and the whole process starts again. > Yes, this is as expected. The interesting part will be to see how long > it takes to get a crystal started in the worst case which is likely one > or the other temperature extreme. The time to start the crystal is depending on the scanning range and resolution. For 1 MHz crystals I don't need an increment in 1/64. 1/2 or 1/4 is sufficient for those. > I know that many MCU makers don't specify their crystal oscillators very > well. I have had to ask manufacturers for more info which in one case > found it's way into the data sheet. The trick here will be to get well > specified operation for specified crystals. ... Yes, it is different to make a crystal work in the lab or to provide safe operations of a crystal in a product sold by the thousands or millions. I am still not pleased with my code, especially the failure with the 2 MHz crystal worries me. I could start the 2 MHz xtal but could not keep it running. I get some feedback but I think I did not stimulate the crystal enough to keep it running. I will improve my code not to halt on the first sign of resonance but to measure how many times the crystal oscillates by itself without pumping in any energy. Then I can find the maximum stimulus response frequency and hopefully make run also the 2 MHz algorithm with the improved algorithm. Anyway, I am having still a lot of fun with the GA144, although I feel a bit claustrophobic programming a chip with so little memory per node :-) On the other hand it has some unique features which distinguishes it from any other chip I know. And if I have some problems with the unorthodox IDE I get help from GA. They have a hotline. -Stefan
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-10 14:43 -0400 |
| Message-ID | <mssisi$c4l$1@dont-email.me> |
| In reply to | #41919 |
On 9/10/2015 2:49 AM, Stefan Mauerhofer wrote: >> I don't recall exactly the Bresenham algorithm, but I'd be willing to >> bet it ends up being the same as an NCO, numerically controlled >> oscillator. The average frequency is the ratio of two integers, the >> step size and the counter modulus. This is an often used algorithm for >> generating a frequency with as much precision as required. > > Yes, you are right. I am using this algorithm. > >> I seem to recall the info I read at GA on their oscillator attempt put >> out a ping, a minimum width impulse into the crystal. That is likely >> more than enough for maintaining the energy in the crystal, but to start >> it a square wave might work better to put more energy in more quickly. >> Which did you do at the start? > > I am using a square wave for starting the crystal. > >> Do you stimulate the crystal for a fixed amount of time at a given >> frequency? Or do you "look" for the crystal oscillating in response to >> your stimulus? I guess it is likely both, stimulate for a time and then >> look. If no input back from the crystal, move on to the next frequency. >> What range of timing values do you cover? > > The crystal is stimulated for a fixed amount of square wave cycles (to avoid measuring the elapsed time). Then the pin is switched to input to check if there is a transition coming back from the crystal. Initially I used way too long wires to connect the crystal to the EvalBoard, so a nearby power line could induce a 60 Hz signal, messing up the whole process. > If no transition is detected for a certain time, then the next frequency is selected and the whole process starts again. > > >> Yes, this is as expected. The interesting part will be to see how long >> it takes to get a crystal started in the worst case which is likely one >> or the other temperature extreme. > > The time to start the crystal is depending on the scanning range and resolution. For 1 MHz crystals I don't need an increment in 1/64. 1/2 or 1/4 is sufficient for those. > >> I know that many MCU makers don't specify their crystal oscillators very >> well. I have had to ask manufacturers for more info which in one case >> found it's way into the data sheet. The trick here will be to get well >> specified operation for specified crystals. ... > > Yes, it is different to make a crystal work in the lab or to provide safe operations of a crystal in a product sold by the thousands or millions. I am still not pleased with my code, especially the failure with the 2 MHz crystal worries me. I could start the 2 MHz xtal but could not keep it running.. I get some feedback but I think I did not stimulate the crystal enough to keep it running. I will improve my code not to halt on the first sign of resonance but to measure how many times the crystal oscillates by itself without pumping in any energy. Then I can find the maximum stimulus response frequency and hopefully make run also the 2 MHz algorithm with the improved algorithm. > > Anyway, I am having still a lot of fun with the GA144, although I feel a bit claustrophobic programming a chip with so little memory per node :-) > On the other hand it has some unique features which distinguishes it from any other chip I know. And if I have some problems with the unorthodox IDE I get help from GA. They have a hotline. I had typed a reply with more comments and questions, but my computer shut down and I lost it. I am tired of fighting this Lenovo piece of crap. I'm going out to get a new one. Be back later... -- Rick
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-10 16:10 -0400 |
| Message-ID | <mssnvp$1o5$1@dont-email.me> |
| In reply to | #41919 |
On 9/10/2015 2:49 AM, Stefan Mauerhofer wrote: >> I don't recall exactly the Bresenham algorithm, but I'd be willing >> to bet it ends up being the same as an NCO, numerically controlled >> oscillator. The average frequency is the ratio of two integers, >> the step size and the counter modulus. This is an often used >> algorithm for generating a frequency with as much precision as >> required. > > Yes, you are right. I am using this algorithm. > >> I seem to recall the info I read at GA on their oscillator attempt >> put out a ping, a minimum width impulse into the crystal. That is >> likely more than enough for maintaining the energy in the crystal, >> but to start it a square wave might work better to put more energy >> in more quickly. Which did you do at the start? > > I am using a square wave for starting the crystal. > >> Do you stimulate the crystal for a fixed amount of time at a given >> frequency? Or do you "look" for the crystal oscillating in >> response to your stimulus? I guess it is likely both, stimulate >> for a time and then look. If no input back from the crystal, move >> on to the next frequency. What range of timing values do you >> cover? > > The crystal is stimulated for a fixed amount of square wave cycles > (to avoid measuring the elapsed time). Then the pin is switched to > input to check if there is a transition coming back from the crystal. > Initially I used way too long wires to connect the crystal to the > EvalBoard, so a nearby power line could induce a 60 Hz signal, > messing up the whole process. If no transition is detected for a > certain time, then the next frequency is selected and the whole > process starts again. > > >> Yes, this is as expected. The interesting part will be to see how >> long it takes to get a crystal started in the worst case which is >> likely one or the other temperature extreme. > > The time to start the crystal is depending on the scanning range and > resolution. For 1 MHz crystals I don't need an increment in 1/64. 1/2 > or 1/4 is sufficient for those. 1/64 or 1/4 mean what, that portion of a step size ( 1 count of UNEXT ) by dithering? >> I know that many MCU makers don't specify their crystal oscillators >> very well. I have had to ask manufacturers for more info which in >> one case found it's way into the data sheet. The trick here will >> be to get well specified operation for specified crystals. ... > > Yes, it is different to make a crystal work in the lab or to provide > safe operations of a crystal in a product sold by the thousands or > millions. I am still not pleased with my code, especially the failure > with the 2 MHz crystal worries me. I could start the 2 MHz xtal but > could not keep it running.. I get some feedback but I think I did not > stimulate the crystal enough to keep it running. I will improve my > code not to halt on the first sign of resonance but to measure how > many times the crystal oscillates by itself without pumping in any > energy. Then I can find the maximum stimulus response frequency and > hopefully make run also the 2 MHz algorithm with the improved > algorithm. Ok, so a 1 MHz crystal works as do several up to 16 MHz, but not the 2 MHz. Do you have detailed info on this crystal? If it starts but dies off after switching to "ping" mode from square wave, maybe the ping needs to be longer than the minimum on/off time which is what I assume you are doing? A tiny impulse doesn't put much energy into the crystal and the 2 MHz part may have a higher ESR which increases the damping factor. In addition to "working", I would like to understand how the digital oscillator interacts with the crystal in a systematic way. There is a lot of info on crystals and most of it is not terribly complete. I have found one or two references that seem to cover the topic thoroughly. It is not always easy to construct a crystal oscillator that works under a range of conditions (usually PVT, but in this case also the crystal specs). > Anyway, I am having still a lot of fun with the GA144, although I > feel a bit claustrophobic programming a chip with so little memory > per node :-) On the other hand it has some unique features which > distinguishes it from any other chip I know. And if I have some > problems with the unorthodox IDE I get help from GA. They have a > hotline. I have three chips sitting here that I don't know what to do with. It seems every thing about this part is done halfway. Even the low cost mounting option has no provision for decoupling caps, the Schmartboard. **** Very frustrating working with an unreliable computer. In addition to the several issues this computer has had since day one, it now has an intermittent software problem that shuts down all networking. I can't even reach the router or modem when it is acting up. I was letting the battery run down to see if that would help reset the condition and was typing a reply when the computer just quit without any of the several warnings I am supposed to get. Crap! I got all ticked off and started yelling about driving up to the city to get a new machine. I started the computer back up and after three days of very limited Internet it is working again. :P I'm still pissed, but I'll wait until tomorrow to get the new machine. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Stefan Mauerhofer <smauerhofer@androsoft.ch> |
|---|---|
| Date | 2015-09-12 03:15 -0700 |
| Message-ID | <81a8b5fc-d075-4005-af8d-ba8e46ff998a@googlegroups.com> |
| In reply to | #41927 |
Am Donnerstag, 10. September 2015 22:10:20 UTC+2 schrieb rickman: > > I have three chips sitting here that I don't know what to do with. It > seems every thing about this part is done halfway. Even the low cost > mounting option has no provision for decoupling caps, the Schmartboard. > Hi Rick I recommend you to buy a EvalBoard from GA. It works and you don't have to worry about caps.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-12 10:28 -0400 |
| Message-ID | <mt1cn5$pg$1@dont-email.me> |
| In reply to | #41967 |
On 9/12/2015 6:15 AM, Stefan Mauerhofer wrote: > Am Donnerstag, 10. September 2015 22:10:20 UTC+2 schrieb rickman: >> >> I have three chips sitting here that I don't know what to do with. It >> seems every thing about this part is done halfway. Even the low cost >> mounting option has no provision for decoupling caps, the Schmartboard. >> > > Hi Rick > > I recommend you to buy a EvalBoard from GA. It works and you don't have to worry about caps. I don't have $500 worth of interest in the device at this point. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Greg <abiforth@gmail.com> |
|---|---|
| Date | 2015-09-13 13:05 -0700 |
| Message-ID | <102f7769-e18e-4548-99be-757e617792de@googlegroups.com> |
| In reply to | #41968 |
I am a software guy so this discussion about crystals is way over my head, at this point in time. I did run into some GA144 related posts here though, where it was claimed that if one managed to get the crystal oscillating reliably, that had huge markerting potential. Some going as far as calling this a Cana of Galilee like moment (Jesus started his ministry with the first public miracle there). So what Stefan is talking in here, isn't that? I took arrayforth school classes, which are done quite professionally, and found the chip to be quite original and interesting. Most programming documentation though assumes Forth knowledge, so I decided to learn Forth before buying the evalboard. I am itching to buy it earlier, are there enough people intersted in the chip, where we could start maybe a dedicated group, and where also clueless people like me could be helped along the way by the more advanced people?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-13 18:59 -0400 |
| Message-ID | <mt4v11$ahu$1@dont-email.me> |
| In reply to | #41985 |
On 9/13/2015 4:05 PM, Greg wrote: > I am a software guy so this discussion about crystals is way over my > head, at this point in time. I did run into some GA144 related posts > here though, where it was claimed that if one managed to get the > crystal oscillating reliably, that had huge markerting potential. > Some going as far as calling this a Cana of Galilee like moment > (Jesus started his ministry with the first public miracle there). So > what Stefan is talking in here, isn't that? No, Stefan is just saying you can pay GA $500 for the privilege of playing with their software and chip to see if you can figure out how to use it in a product. I was pointing out that they worked with Schmartboards to promote a low cost product which allowed easy access to the pins on the chip, but didn't bother to get any decoupling caps included on the board which would allow the user to actually use *all* 144 processors on the chip. Obviously this was something done with virtually no investment (or possibly *literally* none), so was not targeted to anything like the typical low cost starter kit. Not sure what they were thinking. The issue of the crystal oscillator is not at all a show stopper or the great enabler of this chip. It is just another useful feature that was left out of the design for unknown reasons. One might think it was because the processors don't need a clock, but that is simply an issue of controlling the timing of each processor. Nearly all embedded processors need timing for various interfaces and algorithms. So a clock is required. Having an oscillator on the chip saves the cost of using an external oscillator vs. just a crystal, about $0.50 in quantity. This does not seem to be a large cost, but when making high volume products this becomes a large cost. Just one of many shortcomings of the GA144 for high volume apps. > I took arrayforth school classes, which are done quite > professionally, and found the chip to be quite original and > interesting. Most programming documentation though assumes Forth > knowledge, so I decided to learn Forth before buying the evalboard. I > am itching to buy it earlier, are there enough people intersted in > the chip, where we could start maybe a dedicated group, and where > also clueless people like me could be helped along the way by the > more advanced people? I would say I am "interested" in the chip, but not enough to spend $500. I have several of the Schmartboard devices and have never powered them up. Part of the reason is that I did take a look at the development system from GA and found it to be rather labyrinthine. I spent significant time trying to learn the chip at the lower levels where I wanted to optimize some of the timing for an interface to SDRAM. So I did learn the instructions and their timing, but it turns out there are details of the I/O instruction timing missing. I wasn't able to get that timing from GA, so I dropped my efforts. There may be other projects which the GA144 could be an interesting device, but something would need to motivate me to get up and over the learning curve for the tools. Are the videos fairly painless? I seem to recall watching two or three finding that progress was slow and full of details which are not otherwise documented (perhaps in the source code of the system). -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Greg <abiforth@gmail.com> |
|---|---|
| Date | 2015-09-13 18:42 -0700 |
| Message-ID | <95a2750e-3971-4b72-9410-a61ba6ebabcd@googlegroups.com> |
| In reply to | #41988 |
I have found the videos clear and well done. They must have put quite some effort into them. Thing is though that I can't see myself programming much at that level. So what you have next is Coloforth and more recently PolyForth and Eforth. Any of these options involves knowing Forth which is what I am trying to do in my little spare time now. Compared to x86/x64, F18 is extremely simple, once over the initial shock of being so different, there isn't that much to it, actually. The arrayforth classes are structered so that after you are finished, you have a pretty solid understanding of the processor instruction set and their timing. But I do not recall any timing information being given in relation to I/O. Everytime I called/emailed Green arrays I have found very receptive ears, even though I haven't bouhgt anything from them yet. Problem though is that I am a software developer with very limited understanding of the actual hardware pieces that go into the makings of a computer, so I would need to couple with somebody who has that knowledge to get something going. I will search the forum about those postings I was talking about, it seems like what Stefan has going is something big, according to those. There was something about getting the crystal to oscillate on a single pin, or something like that, whatever that means :)
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-13 22:47 -0400 |
| Message-ID | <mt5cd9$7lp$1@dont-email.me> |
| In reply to | #41989 |
On 9/13/2015 9:42 PM, Greg wrote: > I have found the videos clear and well done. They must have put quite > some effort into them. Thing is though that I can't see myself > programming much at that level. Not sure what you mean by "that level"? Is this just the assembly level for the F18A? Personally I don't find it that hard, but that is my thing. I've built microprogrammed machines and programmed them. > So what you have next is Coloforth > and more recently PolyForth and Eforth. Any of these options involves > knowing Forth which is what I am trying to do in my little spare time > now. Whether to use Forth or F18A assembly depends on what you are doing. My understanding is that Polyforth runs in an interpreted mode using multiple F18A nodes. That's great for high level application code. I expect most of the processors will be doing specific tasks, especially in support of I/O. That will likely need to be programmed in F18A assembly. > Compared to x86/x64, F18 is extremely simple, once over the > initial shock of being so different, there isn't that much to it, > actually. That depends on how you look at it. There is a lot of detail that is hard to pull out of the docs I found. But if you read between the lines there is a lot there. > The arrayforth classes are structered so that after you are > finished, you have a pretty solid understanding of the processor > instruction set and their timing. But I do not recall any timing > information being given in relation to I/O. Everytime I > called/emailed Green arrays I have found very receptive ears, even > though I haven't bouhgt anything from them yet. I was initially an eager and willing potential customer. But I guess they didn't think I was working in a way that was compatible with their methods. I was told that rather than worry about designing to timing data, just try it and see if it would work. :) Even if it worked on their eval board, timing has to work over PVT (process, voltage and temperature). The one variable that can't be tested is "process". In every device I've ever designed timing was analyzed by.... analysis from data sheet timing or timing tools with that information built in. > Problem though is > that I am a software developer with very limited understanding of the > actual hardware pieces that go into the makings of a computer, so I > would need to couple with somebody who has that knowledge to get > something going. I will search the forum about those postings I was > talking about, it seems like what Stefan has going is something big, > according to those. There was something about getting the crystal to > oscillate on a single pin, or something like that, whatever that > means :) Normally a crystal is used in a circuit with an amplifier. There are two pins on the amplifier, input and output. Some passives need to be added to set the circuit to the right conditions to oscillate at the correct frequency. The amplifier is so simple that it is nearly universally included in all MCU devices as well as other chips. The GA144 doesn't do that. In a GA144 the idea is that you can connect a crystal between an I/O pin and ground. The I/O pin can be driven high for a short time, then put into input mode. If the crystal is ringing at high enough amplitude, the input can detect when the voltage rises above the 0/1 threshold and wake up the processor. The software then drives the pin to a high for a short time, sets the I/O to input mode again and sleeps waiting for the next threshold crossing. This is all good, but it requires starting with a series of pulses which will put enough energy into the crystal so it will ring with an amplitude high enough to cross the input threshold. That's the hard part. My recollection is a bit fuzzy, but I think both Chuck and someone at GA tried this and could not get it to work for the general case of an arbitrary crystal frequency. They used a simple timing loop which has a limited resolution of one instruction. I say limited because crystals have a very high Q which means they will only resonate at a frequency very close to the intended frequency. So if you try to start it at a frequency outside of this range, the energy won't build up in the crystal and it won't start ringing. Think of this as pushing a swing, same exact problem. If you feel the right time to give them a push, they swing more and more each time. If you blindly push them without syncing to the right frequency some of the time you are slowing them down rather than helping. Stefan realized he could use a dithering technique to drive the crystal at a closer average frequency even if each pulse isn't exactly on the timing mark. This "average" frequency is the important part. So he has gotten more crystals to work even if it isn't perfect. The hard part will be characterizing this and assuring it will work over PVT. There are also factors to consider regarding the stability of this oscillator. Driving the crystal with a 1 or 2 ns wide pulse generates a wide array of frequencies. I have no idea what this will do to the oscillations. Many applications are not at all critical in this regard. They just need to be within 1% of a target frequency. Others are *very* sensitive to frequency and phase noise. But as I said before, this crystal oscillator is not *the* factor keeping people from using the GA144. It is one of many shortcomings that make this an unprofitable device to use in the vast majority of applications. In fact, I expect it is way down on the list of important features in an MCU. I hope this post wasn't too long. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Greg <abiforth@gmail.com> |
|---|---|
| Date | 2015-09-13 21:24 -0700 |
| Message-ID | <76727cd8-abfb-413d-8163-3df6beea97d1@googlegroups.com> |
| In reply to | #41991 |
Rick, thanks much for the explanation. What I mean by 'that level'. To some extent F18 is higher level programming than say x86 assembly, but to some is lower level. One of the classes explains how to do multiplication, for something like that I would certainly want something higher level that does it automatically for me. It is my understanding that ColorForth implements multiplication for you. I think ColorForth is the "assembler" in this world. Then you have the packing of 4 instructions in an 18 bit word. One instruction takes 5 bits, so to fit 4 instructions in the 18 bit word you can only use the instructions that have the last 2 bits set to zero, on the last position in the word. One of which is conveniently, nop. Because that's what you need to use, if the 4th instruction is not one of the other instructions you can pack in there. Again, it is my understanding that ColorForth handles this for you, putting in a nop whenever your next instruction cannot be fitted in the remaning 3 bits of the 18 bit word... Then you have a few instructions that REQUIRE a nop after them, whenever they are not followed by certain other instructions. IIRC that has to do with carry flag not having enough time to propagate, so a nop is needed before the next instruction can correctly be processed. I am not even sure if this is handled by ColorForth for you, I think that's something you need to keep tabs on. I've done Intel assembly in my younger years, but overall I think that even though the instruction set is so much reduced, it is harder and lower level to program this processor. That's why I can't see myself writting reasonably sized programs 'at this level' there simply is too much low level detail that you get bogged down into. And I didn't even throw into the mix, the multi-core thing. If you read from a core, while that core is also in reading mode, you got youself a nice freeze. I don't own an eval board yet, all this is from my recollections from the ArrayForth classes I took a while back.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-14 02:00 -0400 |
| Message-ID | <mt5nlu$2p8$1@dont-email.me> |
| In reply to | #41993 |
On 9/14/2015 12:24 AM, Greg wrote: > Rick, thanks much for the explanation. What I mean by 'that level'. > To some extent F18 is higher level programming than say x86 assembly, > but to some is lower level. One of the classes explains how to do > multiplication, for something like that I would certainly want > something higher level that does it automatically for me. It is my > understanding that ColorForth implements multiplication for you. I > think ColorForth is the "assembler" in this world. Then you have the > packing of 4 instructions in an 18 bit word. One instruction takes 5 > bits, so to fit 4 instructions in the 18 bit word you can only use > the instructions that have the last 2 bits set to zero, on the last > position in the word. One of which is conveniently, nop. Because > that's what you need to use, if the 4th instruction is not one of the > other instructions you can pack in there. Again, it is my > understanding that ColorForth handles this for you, putting in a nop > whenever your next instruction cannot be fitted in the remaning 3 > bits of the 18 bit word... Then you have a few instructions that > REQUIRE a nop after them, whenever they are not followed by certain > other instructions. IIRC that has to do with carry flag not having > enough time to propagate, so a nop is needed before the next > instruction can correctly be processed. I am not even sure if this is > handled by ColorForth for you, I think that's something you need to > keep tabs on. I guess it has been awhile since I looked at the tools. I didn't remember that this was color forth. I don't recall if the tool handles the NOP or not. That is a bit tricky. It's for the ADD instruction which takes two instruction cycles for the carry to ripple. Since this is from loading the two stack positions to using the result, if the previous instruction does not alter the stack the nop is not needed. So I guess they give you the flexibility of not adding it. Sounds like a good job for an optimizer. BTW, the nop goes *before* the plus. > I've done Intel assembly in my younger years, but overall I think > that even though the instruction set is so much reduced, it is harder > and lower level to program this processor. That's why I can't see > myself writting reasonably sized programs 'at this level' there > simply is too much low level detail that you get bogged down into. > And I didn't even throw into the mix, the multi-core thing. If you > read from a core, while that core is also in reading mode, you got > youself a nice freeze. I don't own an eval board yet, all this is > from my recollections from the ArrayForth classes I took a while > back. There is no such thing as a "reasonable" sized program in the F18A if by "reasonable" you mean, not small. With only 64 words of total RAM for program and data there isn't much need for anything other than assembler. It's not really hard. Just give it a try and you'll get the hang of it. The problems come from the I/O instructions in my opinion. At least when you are doing pin I/O... but also inter node comms. There are no protocols set up, so anything other than very basic comms will require you to invent protocols. Be ready to read between the lines on the data sheet. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | borota@gmail.com |
|---|---|
| Date | 2015-09-14 08:35 -0700 |
| Message-ID | <f1510759-4006-4d07-afdb-74fecc9a5864@googlegroups.com> |
| In reply to | #41994 |
On Monday, September 14, 2015 at 1:00:16 AM UTC-5, rickman wrote: > On 9/14/2015 12:24 AM, Greg wrote: > > Rick, thanks much for the explanation. What I mean by 'that level'. > > To some extent F18 is higher level programming than say x86 assembly, > > but to some is lower level. One of the classes explains how to do > > multiplication, for something like that I would certainly want > > something higher level that does it automatically for me. It is my > > understanding that ColorForth implements multiplication for you. I > > think ColorForth is the "assembler" in this world. Then you have the > > packing of 4 instructions in an 18 bit word. One instruction takes 5 > > bits, so to fit 4 instructions in the 18 bit word you can only use > > the instructions that have the last 2 bits set to zero, on the last > > position in the word. One of which is conveniently, nop. Because > > that's what you need to use, if the 4th instruction is not one of the > > other instructions you can pack in there. Again, it is my > > understanding that ColorForth handles this for you, putting in a nop > > whenever your next instruction cannot be fitted in the remaning 3 > > bits of the 18 bit word... Then you have a few instructions that > > REQUIRE a nop after them, whenever they are not followed by certain > > other instructions. IIRC that has to do with carry flag not having > > enough time to propagate, so a nop is needed before the next > > instruction can correctly be processed. I am not even sure if this is > > handled by ColorForth for you, I think that's something you need to > > keep tabs on. > > I guess it has been awhile since I looked at the tools. I didn't > remember that this was color forth. I don't recall if the tool handles > the NOP or not. That is a bit tricky. It's for the ADD instruction > which takes two instruction cycles for the carry to ripple. Since this > is from loading the two stack positions to using the result, if the > previous instruction does not alter the stack the nop is not needed. So > I guess they give you the flexibility of not adding it. Sounds like a > good job for an optimizer. BTW, the nop goes *before* the plus. > > > > I've done Intel assembly in my younger years, but overall I think > > that even though the instruction set is so much reduced, it is harder > > and lower level to program this processor. That's why I can't see > > myself writting reasonably sized programs 'at this level' there > > simply is too much low level detail that you get bogged down into. > > And I didn't even throw into the mix, the multi-core thing. If you > > read from a core, while that core is also in reading mode, you got > > youself a nice freeze. I don't own an eval board yet, all this is > > from my recollections from the ArrayForth classes I took a while > > back. > > There is no such thing as a "reasonable" sized program in the F18A if by > "reasonable" you mean, not small. With only 64 words of total RAM for > program and data there isn't much need for anything other than > assembler. It's not really hard. Just give it a try and you'll get the > hang of it. The problems come from the I/O instructions in my opinion. > At least when you are doing pin I/O... but also inter node comms. > There are no protocols set up, so anything other than very basic comms > will require you to invent protocols. Be ready to read between the > lines on the data sheet. > > -- > > Rick These are some of the links I was referring to: https://groups.google.com/d/msg/comp.lang.forth/znB0NksUPBo/FMBe5Ddpp8AJ https://groups.google.com/d/msg/comp.lang.forth/znB0NksUPBo/mr6z8b50xzUJ where it was said that getting the crystal to oscillate was a big deal.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-14 12:06 -0400 |
| Message-ID | <mt6r5t$5e7$1@dont-email.me> |
| In reply to | #41996 |
On 9/14/2015 11:35 AM, borota@gmail.com wrote: > On Monday, September 14, 2015 at 1:00:16 AM UTC-5, rickman wrote: >> On 9/14/2015 12:24 AM, Greg wrote: >>> Rick, thanks much for the explanation. What I mean by 'that level'. >>> To some extent F18 is higher level programming than say x86 assembly, >>> but to some is lower level. One of the classes explains how to do >>> multiplication, for something like that I would certainly want >>> something higher level that does it automatically for me. It is my >>> understanding that ColorForth implements multiplication for you. I >>> think ColorForth is the "assembler" in this world. Then you have the >>> packing of 4 instructions in an 18 bit word. One instruction takes 5 >>> bits, so to fit 4 instructions in the 18 bit word you can only use >>> the instructions that have the last 2 bits set to zero, on the last >>> position in the word. One of which is conveniently, nop. Because >>> that's what you need to use, if the 4th instruction is not one of the >>> other instructions you can pack in there. Again, it is my >>> understanding that ColorForth handles this for you, putting in a nop >>> whenever your next instruction cannot be fitted in the remaning 3 >>> bits of the 18 bit word... Then you have a few instructions that >>> REQUIRE a nop after them, whenever they are not followed by certain >>> other instructions. IIRC that has to do with carry flag not having >>> enough time to propagate, so a nop is needed before the next >>> instruction can correctly be processed. I am not even sure if this is >>> handled by ColorForth for you, I think that's something you need to >>> keep tabs on. >> >> I guess it has been awhile since I looked at the tools. I didn't >> remember that this was color forth. I don't recall if the tool handles >> the NOP or not. That is a bit tricky. It's for the ADD instruction >> which takes two instruction cycles for the carry to ripple. Since this >> is from loading the two stack positions to using the result, if the >> previous instruction does not alter the stack the nop is not needed. So >> I guess they give you the flexibility of not adding it. Sounds like a >> good job for an optimizer. BTW, the nop goes *before* the plus. >> >> >>> I've done Intel assembly in my younger years, but overall I think >>> that even though the instruction set is so much reduced, it is harder >>> and lower level to program this processor. That's why I can't see >>> myself writting reasonably sized programs 'at this level' there >>> simply is too much low level detail that you get bogged down into. >>> And I didn't even throw into the mix, the multi-core thing. If you >>> read from a core, while that core is also in reading mode, you got >>> youself a nice freeze. I don't own an eval board yet, all this is >>> from my recollections from the ArrayForth classes I took a while >>> back. >> >> There is no such thing as a "reasonable" sized program in the F18A if by >> "reasonable" you mean, not small. With only 64 words of total RAM for >> program and data there isn't much need for anything other than >> assembler. It's not really hard. Just give it a try and you'll get the >> hang of it. The problems come from the I/O instructions in my opinion. >> At least when you are doing pin I/O... but also inter node comms. >> There are no protocols set up, so anything other than very basic comms >> will require you to invent protocols. Be ready to read between the >> lines on the data sheet. >> >> -- >> >> Rick > These are some of the links I was referring to: > https://groups.google.com/d/msg/comp.lang.forth/znB0NksUPBo/FMBe5Ddpp8AJ > https://groups.google.com/d/msg/comp.lang.forth/znB0NksUPBo/mr6z8b50xzUJ > where it was said that getting the crystal to oscillate was a big deal. Ok. So what do you think now? -- Rick
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web