Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #15789 > unrolled thread
| Started by | Howerd <howerdo@yahoo.co.uk> |
|---|---|
| First post | 2012-09-27 14:16 -0700 |
| Last post | 2012-10-07 10:57 -0700 |
| Articles | 10 on this page of 50 — 10 participants |
Back to article view | Back to comp.lang.forth
GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-09-27 14:16 -0700
Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-09-29 01:20 -0700
Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-09-30 11:05 -0400
Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-09-30 09:06 -0700
Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-09-30 14:29 -0400
Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-09-30 19:56 -0700
Re: GA144 polyForth Coos Haak <chforth@hccnet.nl> - 2012-09-30 21:54 +0200
Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-01 11:18 -0700
Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-10-01 23:40 -0700
Re: GA144 polyForth "Elizabeth D. Rather" <erather@forth.com> - 2012-10-01 21:23 -1000
Re: GA144 polyForth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-05 19:19 +0000
Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-04 23:04 -0700
Re: GA144 polyForth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-01 10:28 -0500
Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-01 11:19 -0700
Re: GA144 polyForth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-03 10:46 -0500
Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-04 13:46 -0700
Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-05 22:10 -0700
Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-10-05 23:17 -0700
Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-06 05:47 -0700
Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-07 19:31 -0400
Re: GA144 polyForth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-08 20:10 +0200
Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-08 16:36 -0400
Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-08 13:31 -0700
Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-09 13:48 -0400
Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-09 13:21 -0700
Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-09 17:08 -0400
Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-13 07:39 -0700
Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-13 14:28 -0400
Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-13 13:37 -0700
Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-13 16:54 -0400
Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-13 14:14 -0700
Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-13 17:30 -0400
Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-14 02:00 -0700
Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-14 19:54 -0400
Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-15 11:03 -0700
Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-15 16:38 -0400
Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-16 04:12 -0700
Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-16 15:46 -0400
Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-16 23:05 -0700
Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-17 13:40 -0400
Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-17 22:54 -0700
Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-18 14:53 -0400
Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-18 15:06 -0400
Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-18 15:09 -0400
Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-19 10:43 -0700
Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-19 17:43 -0400
Re: GA144 polyForth Mikael Nordman <oh2aun@invalid.com> - 2012-10-06 11:29 +0300
Re: GA144 polyForth mhx@iae.nl (Marcel Hendrix) - 2012-10-06 11:14 +0200
Re: GA144 polyForth Mikael Nordman <oh2aun@invalid.com> - 2012-10-06 16:08 +0300
Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-10-07 10:57 -0700
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Howerd <howerdo@yahoo.co.uk> |
|---|---|
| Date | 2012-10-17 22:54 -0700 |
| Message-ID | <53df0473-3971-422e-aeda-3859b0a6b68b@y6g2000vbb.googlegroups.com> |
| In reply to | #16398 |
On Oct 17, 7:40 pm, rickman <gnu...@gmail.com> wrote: > On 10/17/2012 2:05 AM, Howerd wrote: > > > Hi Rick, > > > I've chopped the bulk of the reply post because it is getting way too > > long... > > >>> X is " how can I use the GA144's VCO as a very high resolution ADC?" > >> BTW, perhaps you should share with the Green Arrays people > >> that their ADC can't measure with high resolution. > > No, you can't use the VCO as a VERY high resolution ADC ( 30 bits ). > > But you can, I think, use it to measure down to this level if you use > > the counter directly, and not as a conventional ADC. > > I think you need to read a bit more about the GA144 and how the ADC > works. There is no limit to the resolution of the ADC data word. Once > you actually understand how the ADC works, you will see that. But as > long as you keep talking about the constituent parts, you will not see it. > > >> You don't want to measure voltage, charge *or* current, you want to measure ANALOG. > > Exactly. Voltage and current are scalar quantities, quantum mechanics > > shows that electric fields are vectors, so current flowing in a wire > > is a 1 dimensional representation of a 2 or more dimensional field. > > If you measure voltage with chips that are desinged to measure > > voltage, you will only see voltage. > > So, yes I want to measure ANALOG, whtever that is. > > Hey, ANALOG is *your* term, not mine! Go back to your previous post, > you said, "Y is " how can I use the GA144's VCO to measure very small > analog changes on its input pin with very high resolution?" Answer - see > above." So what is an ANALOG that you are measuring changes in? > > Rick Hi Rick, > I think you need to read a bit more about the GA144 and how the ADC works. Ah, the RTFM principle ;-) > So what is an ANALOG that you are measuring changes in? If I knew that, I wouldn't need to do the experiment. Almost every mobile phone these days has a "chip antenna" - a small block that picks up the RF. I don't know how these work, but they are certainly not half wavelength dipoles. So there are some interesting new developments in antenna technology that do not fit with my 1973-76 physics course. I am curious what other possibilites exist, and the GA144 seems to be an ideal chip experimenting with. I want to get away from the (very useful) abstractions that are taught in schools and get back to the simplest possible model that actually fits the observations. Best regards, Howerd
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-18 14:53 -0400 |
| Message-ID | <k5pj77$rak$1@dont-email.me> |
| In reply to | #16068 |
On 10/18/2012 1:54 AM, Howerd wrote: > On Monday, October 8, 2012 1:31:55 AM UTC+2, rickman wrote: >> On 10/6/2012 8:47 AM, Howerd wrote: >> >> > On Saturday, October 6, 2012 8:17:09 AM UTC+2, Paul Rubin wrote: >> >> >> Howerd<how....@yahoo.co.uk> writes: >> >> >>> always going to be an overhead when you interface a GA144 to a clocked >> >> >>> system - since the GA144 runs asynchronously it has to run a polling >> >> >>> loop. OK, it could idle between characters, >> >> >> >> >> >> Can't it use edge or level sensitive triggering on the port pin >> >> >> listening to the rs232 signal? Then the GA node should block until the >> >> >> bit actually arrives. >> >> >> >> That is how many MCUs time an async data stream, but they have to have a >> >> timer running so they can record the time of each transition. The GA144 >> >> is capable of implementing timers the same way by monitoring a clock >> >> input, but GA doesn't seem too interested in using this sort of >> >> operation. Chuck's work seems to focus on no clock at all which is not >> >> practical. He tried that with his video circuits and found the VGA >> >> signal from software loop timing was not stable enough to work with his >> >> monitor, and that is a *relaxed* application. >> >> >> >> >> >> >> It also occurs to me, I don't see any way for a GA node to enter a sleep >> >> >> for a given amount of time (say 100 microseconds), other than with a >> >> >> full-speed busy loop and that 8 ma of power consumption. Compare that >> >> >> with microcontrollers that have very low powered counter-timers. >> >> >> >> The async processor goes to sleep until an input triggers it. So why >> >> not use a clock for that input? Then the GA144 core could utilize very >> >> little power just waiting. >> >> >> >> >> >> >> 8 ma is more than I expected for a single node anyway. It means over 1 >> >> >> amp for all 144 nodes going at once, or several watts of power. I >> >> >> didn't realize the ga144 could use that much. Or, maybe the 8ma >> >> >> includes other stuff too. >> >> >> >> 8 mA is too high for a single node. One node is about 5 mW which would >> >> be around 3 mA I believe. Still it's in that ballpark. With all 144 >> >> nodes running the power consumption is around three quarters of a Watt. >> >> But the power consumption is instruction dependent, so you need to >> >> qualify that. Just like the instruction rate is not 700 MIPS, but >> >> depends on your code the power consumption depends on your code too. >> >> >> >> >> >> >>> but a better way would be to use the on-chip SERDES instead of RS232 >> >> >> >> The SERDES is useless for talking to anything other than another GA >> >> device. At least it is not supported in any other mode. I'm not sure >> >> what protocol they use, but the clocking rate varies widely and so is >> >> hard to interface to other devices. At least this is what I got out of >> >> the specs and lack of other info. >> >> >> >> >> >> >> The on-chip serdes is designed to only talk to other ga144's--do you >> >> >> mean to add a third ga144 to the board? >> >> > >> >> > Hi Paul, >> >> > >> >> >> ... I don't see any way for a GA node to enter a sleep >> >> >> for a given amount of time (say 100 microseconds), other than with a >> >> >> full-speed busy loop and that 8 ma of power consumption. >> >> > Yes - being asynchronous means that it has no idea of time. >> >> > But the only reason to wait for 100 ns is to synchronise with an >> >> external synchronous device - I'm stating the obvious here, but the >> >> GA144 is best suited to a fully asynchronous environment. If only the >> >> whole world was asynchronous - maybe it should be ;-) >> >> >> >> To sync with a sync device it would just wait for the clock signal. >> >> Sync devices always use a clock. The reason for waiting for some amount >> >> of time is to reduce power when you have nothing to do. That means you >> >> need a timer to start the processor again. That can be done by a timer >> >> node using an external clock. >> >> >> >> The world will become async as soon as no one cares about speeds or times. >> >> >> >> >> >> >> The on-chip serdes is designed to only talk to other ga144's--do you >> >> >> mean to add a third ga144 to the board? >> >> > Nope - there are already two on the eval board, one of them is >> >> already acting as the interface to the synchronous world, via USB and >> >> serial comms. The two chips communicate via serdes. >> >> > But the serdes protocol is very simple, and self clocking (as it must >> >> be!), so maybe it could be implemented in software on another chip. The >> >> auto-baud software needs at least 19200 baud to not overflow the 18 bit >> >> counter, so a reasonably fast ARM should be able to keep up. >> >> >> >> Are you mixing the SERDES and the software UART? ARMs and many other >> >> processors implement software UARTs. The SERDES runs at 100's of MHz. >> >> That is too fast for any CPU I am aware of to implement in software... >> >> assuming you knew the protocol. >> >> >> >> >> >> > There is a common theme here that I have noticed : The GA144 does >> >> things its own way, and it is difficult to interface it to the rest of >> >> the world which is doing things another way. >> >> >> >> Duh, not only other digital systems, but lots of real world applications >> >> are hard to interface to the GA144. Clocks tell us time and nearly >> >> everything is time based. >> >> >> >> >> >> > For example : >> >> > 1. It would be great, but non-trivial, to run a USB stack on a >> >> handful of F18's. Does this mean that the GA144 should have hardware USB >> >> support added, or that USB should changed for something simpler? >> >> >> >> "Trivial"??? If that were true, GA would have done it already and put >> >> the code in the cores so it could boot from USB without the support >> >> chips from FTDI. >> >> >> >> >> >> > 2. SDRAM has a synchronous interface, but runs dynamically >> >> internally. I believe there are asynchronous RAMS, but thay are rare. >> >> Should the GA144 add a fast SDRAM module, or should the SDRAM chip be >> >> modified? >> >> >> >> Async RAMs are not "rare", in fact that is what is on the GA144 eval >> >> board. They aren't dense and they can be expensive, but the ones GA >> >> picked aren't too bad at around $5. >> >> >> >> The problem with DRAMs (the generic term for all dynamic memory) is that >> >> they must be operated with both minimums and maximums on the timing >> >> signals. The maximums are not too hard to meet, but typically designers >> >> want to run the DRAMs as fast as possible. In the old days when DRAM >> >> interfaces were async (meaning no clock, not lack of timing constraints) >> >> it could be hard to optimize this interface. SDRAM added a clock and >> >> gave the interface specific timing related to that clock. I tried to >> >> design an SDRAM software interface for the GA144 and the big problem is >> >> trying to make the processors run the interface anywhere close to full >> >> speed. I think I could get it to run at 50 MHz, but I can't be sure >> >> because they don't provide all the timing data for this sort of design. >> >> But 50 MHz is not even half speed for the old single data rate SDRAM >> >> and is nowhere near the rates of DDR, DDR2 or DDR3. >> >> >> >> Don't try to turn this into a problem with the memory devices. They >> >> work just fine. The problem is that GA won't put a proper memory >> >> interface on the chip which will run at memory speeds. Instead they use >> >> software which runs much slower than optimal. >> >> >> >> >> >> > 3. Most software is written with the assumption of large amounts of >> >> flat addressed memory ( doesn't the 1M byte DOS limit feel really tight? >> >> ). But you can write software in very small, colorForth size chunks. If >> >> you spread these around a few F18's maybe you can create something >> >> really cool. >> >> >> >> Yes, there are apps which will suit the GA144 small memory model, but >> >> they aren't the same apps that are typically running on>1MB devices. >> >> Remember the memory chunks are only 64 words per processor for both >> >> program and data. So even with 144 of them you only have some 9 kWords >> >> of memory on chip. Otherwise you have to load the programs and data >> >> from external memory. Memory can be a real bottle neck unless you are >> >> running a pretty special app that fits the GA144. I think digital >> >> receivers are one class of app that might work ok on this device, but I >> >> don't know of any others. >> >> >> >> >> >> > Going back to the original point - yes the GA144 can wait in an idle >> >> state for a pin to change state, but it must poll to get timings. Maybe >> >> a neighbouring F18 could wait for a change of state on a fixed clock >> >> signal, say at 16 * baudrate, then pass this on. This should get the >> >> power down to a minimum. Then again, maybe fixed baud rate is not the >> >> right way to talk to a GA144... >> >> >> >> Yes, an external clock and a timer node is the way to get timing data. >> >> But to suggest that you shoudldn't talk to the GA144 with a fixed baud >> >> rate is not very realistic. What part of the world is going to change >> >> to suit the GA144? >> >> >> >> One way to do this is to work with a two wire interface, one wire for >> >> clock and one wire for data. Whoever is sending the data sends the >> >> clock and the receiver has the option of slowing the clock like in I2C. >> >> Or they could just add some hardware to handle this properly for >> >> whatever interface you don't like. >> >> >> >> >> >> > What would be interesting is to move the polyForth virtual machine to >> >> the target GA144, using serdes to communicate with it, and then measure >> >> the power. >> >> > Maybe I'll find some time over Xmas :-) >> >> > >> >> > Best regards, >> >> > Howerd >> >> >> >> Rather than play with the board to measure things that don't likely >> >> matter to the world, what do you think you could use this device for >> >> that would be a better implementation than other devices? >> >> >> >> Rick > > Hi Rick, > >> 8 mA is too high for a single node. One node is about 5 mW which would >> be around 3 mA I believe. > This is consistant with three nodes being active - the comms, bitsy and stack. > Comms could wait for a clock signal, and the polyForth VM could be put into an idle mode, presumably. > >> > 1. It would be great, but non-trivial, to run a USB stack on a >> handful of F18's. Does this mean that the GA144 should have hardware USB >> support added, or that USB should changed for something simpler? >> "Trivial"??? > No, I said non-trivial! It would make a great PHD project :-) :PhD? Hardly! A PhD dissertation is supposed to be about original work, not the mere implementation of a standard protocol. >> nearly everything is time based. > This is true, but this is just because everything is time based - its a self-fulfilling prophecy. The GA144 has no problem measuring time, just that it does so in its units. It can, of course, compare this to a reference clock if required. Ok, this is looney land type stuff. Time is measured in units of seconds and the various SI defined powers of 10. Talking about GA144 units of time is a bit tongue in cheek as the GA144 has no way of "measuring" time without a time reference. Don't pervert reality with this sort of comment. >> What part of the world is going to change to suit the GA144? > Any part that comes into contact with it - maybe the way things are done at the moment is not the only way. After all, Chuck designed the GA144 using colorForth... More loony land stuff. I don't think 100 years of electrical engineering is going to reverse course to adapt to the GA144. I'm not sure the "world" has even noticed its existence. "Wait, do you feel that, a disturbance in the force? It must be the GA144!" >> One way to do this is to work with a two wire interface... > Another is to use the GA144 serdes protocol. IIRC it it very simple, and since it is self-clocking, you can run it at lower speeds too. My comment about ARM chips being able to implement it in software was because it needs to be reasonably fast, I believe, so as not to overflow the 18 bit counters. Really? What is the GA144 SERDES protocol? What is the maximum rate, the minimum? What is the setup and hold timing on the data? BTW, it is *not* self-clocking. It has two wires, one is the clock and one is data. That is *not* self clocking. I suppose you mean the chip defines the clock rate, not an external timing reference. That is why I ask about the protocol spec, there isn't one! They only have to make one GA144 chip talk to the other GA144 chips and they don't spec the SERDES to talk to any other devices. >> Don't try to turn this into a problem with the memory devices. They >> work just fine. The problem is that GA won't put a proper memory >> interface on the chip which will run at memory speeds. > I am not an expert on current memory technology, but it seems to me that any memory array returns its result when its ready, and most of the difficulty is in creating a synchronous interface to this. If this is true, what you are advocating is adding another synchronous interface to the GA144 to match the one on the RAM chip, and I am suggesting removing them both. Yes, that would be much better, a memory with no interface. The GA144 can communicate with it via... well, what exactly? >> Or they could just add some hardware to handle this properly for >> whatever interface you don't like. > I have been checking out the latest chips for an embedded upgrade - MSP430, 8051, even PIC24. They all seem to be a collection of interface modules wrapped around some sort of processor, rather than a processor with modules. > Instead of doing this, GA supply the simplest possible hardware, and allow the end user to program appropriate interfaces. > One solution is to put a conventional chip alongside a GA144 to handle all of these interfaces. Maybe this is a necessary evil to communicate with the rest of the world. Necessary evil? No, this is the absurdity of thinking you can design a useful chip and ignore the world it will be working in. The GA144 may have some application in apps where it stands alone. But as a component is a large system it is rather pointless. The only interfaces a user can program on this chip are the slow, simple interfaces that *every* other MCU already has without programming. In fact, I was just looking at the Atmel SAM4 devices with the cortex M4 processor. They are very low power and have just dozens of peripherals built in. Many of these peripherals can't be done in software of the GA144 because the CPUs are too slow. When I looked at using the GA144 in an app which needs an interface to a PC, I realized I would need to add an MCU to implement the USB interface at high speed rates. Sometimes the 50 year old serial port is just not enough! >> what do you think you could use this device for >> that would be a better implementation than other devices? > I intend to use the GA144 to interface to one or more antennas. I have a "gut feeeling" that if you remove all of the simplifying assumptions between electromagnetic radiation and software you might be able to find some new properties of both. > I am particularly interested in the orbital angular momentum ( OAM ) property of electromagnetic radiation - I want to go back to basics and see whether this can be measured easily with a GA144. I think the 6 GHz counter and VCO might be able to resolve OAM effects. We shall see... Yes, we have already discussed this and it is clear that the GA144 has no advantage over conventional ADCs for this app. But since you don't understand how the GA144 ADC operates you can't see that. You also haven't said how OAM might manifest itself in a measurement, so you certainly can't say there is anything superior to any technique. Rick
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-18 15:06 -0400 |
| Message-ID | <k5pjv7$q3$1@dont-email.me> |
| In reply to | #16446 |
On 10/18/2012 2:53 PM, rickman wrote: > > Rick I'm not sure what was wrong, but it appears that I replied to an old message. Sorry if my reply sounded a bit cranky. It is just that much of this has gotten to be repetitive so I couldn't tell it was an old message, oddly enough. Rick
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-18 15:09 -0400 |
| Message-ID | <k5pk58$q3$2@dont-email.me> |
| In reply to | #16447 |
On 10/18/2012 3:06 PM, rickman wrote: > On 10/18/2012 2:53 PM, rickman wrote: >> >> Rick > > I'm not sure what was wrong, but it appears that I replied to an old > message. Sorry if my reply sounded a bit cranky. It is just that much of > this has gotten to be repetitive so I couldn't tell it was an old > message, oddly enough. > > Rick No, I was right the first time. For some odd reason the newsreader is showing my reply (the first one) as to an old message. But it was the most recent message I was responding to and it is highly repetitive with the rest of this conversation. Rick
[toc] | [prev] | [next] | [standalone]
| From | Howerd <howerdo@yahoo.co.uk> |
|---|---|
| Date | 2012-10-19 10:43 -0700 |
| Message-ID | <b314e512-1931-49f0-986a-9f367014c4ef@googlegroups.com> |
| In reply to | #16446 |
Hi Rick, I've chopped the original text here, again because its is getting too long... >:PhD? Hardly! A PhD dissertation is supposed to be about original >work, not the mere implementation of a standard protocol. Since no one has implemented USB on a GA144 I think this counts as original. My point about making a good PhD thesis is that it needs a substantial amount of time, such a PhD thesis could provide. > "Wait, do you feel that, a disturbance in the force? It must be the GA144!" I would describe it more as a feeling of excitement - something new, created out of a desire for simplicity. The chip layout was designed using OKAD2 in colorForth. The architecture of each F18 is a very well thought out Forth machine. The GA144 has just enough hard-coded interfaces that it can boot, and uses a power efficient, asynchronous design. Each F18 has a built in BIOS to allow it to communicate with all the other F18's. This has effectively extended Forth into the world of parallel computing. If this was just talk and speculation I would be quite interested, but I have seen OKAD2 in action, and I have two GA144's on an eval board sitting on the shelf, waiting for me to find some free time... They are real and they work :-) What's not to get excited about? But of course YMMV - whatever floats your boat... > What is the GA144 SERDES protocol? What is the maximum rate, > the minimum? What is the setup and hold timing on the data? BTW, it is > *not* self-clocking. It has two wires,... It sounds like 18 bit SPI to me. The data sheet says 450MHz. You are right about the two wires though - I was confusing it with the 1-wire protocol which only runs at ~25MHz - only twice as fast as USB full speed. > No, this is the absurdity of thinking you can design a > useful chip and ignore the world it will be working in. The alternative is to be a sheep and follow what every one else is doing. > Yes, we have already discussed this and it is clear that the GA144 has > no advantage over conventional ADCs for this app. I think we will have to agree to differ on this. > You also haven't said how OAM might manifest itself in a measurement, That is because I don't know yet. Sorry. Apparently OAM is being used : http://www.extremetech.com/extreme/120803-vortex-radio-waves-could-boost-wireless-capacity-infinitely although I am sceptical that you can even double the bandwidth using OAM in this way, due to increased noise. We shall see... > so you certainly can't say there is anything superior to any technique. Not yet, clearly. > More loony land stuff. After all the GA144 looks like any other chip - its OK if you don't get excited about it ;-) Its just from my eccentric perspective that the GA144 seems to be very special. I got a similar feeling of excitement from the CDP1802 chip back in the late 70's - again something new and simple, and from seeing Forth for the first time, and colorForth etc. etc. I usually pretend to be quite normal, except of course when there's a full moon ;-) Best regards, Howerd
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-19 17:43 -0400 |
| Message-ID | <k5shi1$d5l$1@dont-email.me> |
| In reply to | #16495 |
On 10/19/2012 1:43 PM, Howerd wrote: > Hi Rick, > > I've chopped the original text here, again because its is getting too long... > >> :PhD? Hardly! A PhD dissertation is supposed to be about original >> work, not the mere implementation of a standard protocol. > Since no one has implemented USB on a GA144 I think this counts as original. > My point about making a good PhD thesis is that it needs a substantial amount of time, such a PhD thesis could provide. Yes, that is the problem. What should be a simple matter of implementing a standard protocol that runs on all sorts of processors down to small 8 bit MCUs, is instead a major exercise on the GA144. The more I defend this device, the less I like it! >> "Wait, do you feel that, a disturbance in the force? It must be the GA144!" > I would describe it more as a feeling of excitement - something new, created out of a desire for simplicity. > The chip layout was designed using OKAD2 in colorForth. That's totally irrelevant. > The architecture of each F18 is a very well thought out Forth machine. "Well thought out" is a matter of opinion. Many here will disagree with you on that. I can think of a number of obvious functions missing from the GA144, the most significant is likely a real, clock based memory interface. > The GA144 has just enough hard-coded interfaces that it can boot, and uses a power efficient, asynchronous design. > Each F18 has a built in BIOS to allow it to communicate with all the other F18's. This has effectively extended Forth into the world of parallel computing. That is what is missing. There is NO inter-CPU communications protocol built in. It was only a month or so ago that Chuck came up with an admittedly very complex scheme to pass data through nodes to get to a destination. > If this was just talk and speculation I would be quite interested, but I have seen OKAD2 in action, and I have two GA144's on an eval board sitting on the shelf, waiting for me to find some free time... They are real and they work :-) > What's not to get excited about? > But of course YMMV - whatever floats your boat... If I were designing chips I might get excited about OKAD. But I design boards and need chips that work and are well enough documented so that I can do my work. >> What is the GA144 SERDES protocol? What is the maximum rate, >> the minimum? What is the setup and hold timing on the data? BTW, it is >> *not* self-clocking. It has two wires,... > It sounds like 18 bit SPI to me. The data sheet says 450MHz. > You are right about the two wires though - I was confusing it with the 1-wire protocol which only runs at ~25MHz - only twice as fast as USB full speed. 450 MHz is what, max, min, typ? How are words delineated? They may work, but what can they be used for? >> No, this is the absurdity of thinking you can design a >> useful chip and ignore the world it will be working in. > The alternative is to be a sheep and follow what every one else is doing. Yes, the sheep that design products that are bought and do useful stuff. >> Yes, we have already discussed this and it is clear that the GA144 has >> no advantage over conventional ADCs for this app. > I think we will have to agree to differ on this. If you could just explain anything about your ADC ideas that fits in with either the real design of the GA144 or electronics design I would be happy to just agree with you. But you have not answered any of my questions about how you will be using the ADCs. >> You also haven't said how OAM might manifest itself in a measurement, > That is because I don't know yet. Sorry. > Apparently OAM is being used : > http://www.extremetech.com/extreme/120803-vortex-radio-waves-could-boost-wireless-capacity-infinitely > although I am sceptical that you can even double the bandwidth using OAM in this way, due to increased noise. We shall see... Yes, by people who understand OAM and also understand how ADCs work. Or do I misunderstand and they are all using GA144s in their receivers? >> so you certainly can't say there is anything superior to any technique. > Not yet, clearly. > >> More loony land stuff. > After all the GA144 looks like any other chip - its OK if you don't get excited about it ;-) > Its just from my eccentric perspective that the GA144 seems to be very special. > I got a similar feeling of excitement from the CDP1802 chip back in the late 70's - again something new and simple, and from seeing Forth for the first time, and colorForth etc. etc. > > I usually pretend to be quite normal, except of course when there's a full moon ;-) > > Best regards, > Howerd Excited or irrational exuberance? I was impressed with the device at one point. Then I started to program with it and found the glaring lack of documentation combined with the resistance of the company to fill in the gaps. That, on top of the severe limitations of the chips. I do see the GA144 being useful in some limited applications, but the harder I look at it, the more limited these apps seem to be. Rick
[toc] | [prev] | [next] | [standalone]
| From | Mikael Nordman <oh2aun@invalid.com> |
|---|---|
| Date | 2012-10-06 11:29 +0300 |
| Message-ID | <k4oq5o$vbr$1@dont-email.me> |
| In reply to | #15789 |
On 28.9.2012 0:16, Howerd wrote: > I also ran a speed test : > : asd 1000 for 1000 for 0 drop next next ; > takes about 3 seconds. > All in all it could compete with an MSP430, 8051 or a PIC except that > only with the GA144 do you get so many fast cores with fast I/O to > > play with. Out of curiosity I ran the same speed test with FlashForth on PIC18, PIC24 and AVR Atmega. 181 ms on PIC24 @ 54 MHz 750 ms on PIC18 @ 48 MHz 4154 ms on Atmega 328 @ 8 Mhz Mike
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2012-10-06 11:14 +0200 |
| Message-ID | <70899297938435@frunobulax.edu> |
| In reply to | #15967 |
Mikael Nordman <oh2aun@invalid.com> writes Re: GA144 polyForth > On 28.9.2012 0:16, Howerd wrote: > > I also ran a speed test : > > : asd 1000 for 1000 for 0 drop next next ; > > takes about 3 seconds. > > All in all it could compete with an MSP430, 8051 or a PIC except that > > only with the GA144 do you get so many fast cores with fast I/O to > > > play with. > Out of curiosity I ran the same speed test with FlashForth on PIC18, > PIC24 and AVR Atmega. > 181 ms on PIC24 @ 54 MHz > 750 ms on PIC18 @ 48 MHz > 4154 ms on Atmega 328 @ 8 Mhz That's remarkably good. On a 2.667 GHz i7 desktop machine, iForth (64bit) takes 2.22 ms. Adjusting for clockspeed, 2.22 ms * 2667 / 54 = 110 ms, as compared to PIC24's 181 ms. The speed difference between PIC24 and PIC18 is much higher than the expected factor of 2. I guess FlashForth for PIC24 is radically different and uses more of the available registers? -marcel
[toc] | [prev] | [next] | [standalone]
| From | Mikael Nordman <oh2aun@invalid.com> |
|---|---|
| Date | 2012-10-06 16:08 +0300 |
| Message-ID | <k4pafs$igl$1@dont-email.me> |
| In reply to | #15969 |
On 6.10.2012 12:14, Marcel Hendrix wrote:
>> Out of curiosity I ran the same speed test with FlashForth on PIC18,
>> PIC24 and AVR Atmega.
>
>> 181 ms on PIC24 @ 54 MHz
>> 750 ms on PIC18 @ 48 MHz
>> 4154 ms on Atmega 328 @ 8 Mhz
>
> That's remarkably good. On a 2.667 GHz i7 desktop machine, iForth (64bit)
> takes 2.22 ms. Adjusting for clockspeed, 2.22 ms * 2667 / 54 = 110 ms, as
> compared to PIC24's 181 ms.
>
> The speed difference between PIC24 and PIC18 is much higher than the
> expected factor of 2. I guess FlashForth for PIC24 is radically different
> and uses more of the available registers?
>
> -marcel
>
>
The 16-bit PIC24 has much better adressing modes than the
8-bit processors. This is partly due to that the PIC24
has a 24-bit instruction word so it can fit more data
in one instruction.
Normalized for 8 MHz Fosc the comparative figures are
PIC24: 1221 ms
PIC18: 4500 ms
Amega: 4154 ms
Normalized for 8 MIPS peak instruction rate:
PIC24: 610 ms (16 Mhz Fosc)
PIC18: 1125 ms (32 MHz Fosc)
Amega: 4154 ms (8 Mhz Fosc)
The decrement of TOR in NEXT is just one instruction.
PIC24: dec [--W15], [W15++] ; XNEXT
bra c, back
Here it is 3 instructions.
PIC18: decf TOSL, F, A ; XNEXT
movlw 0
subwfb TOSH, F, A
bc back
And for the Atmega its 12 instruction cycles.
It would be only 5 cycles if the
NEXT code is inlined. But I decided
to save space instead of making it fast.
Atmega: call XNEXT
brcc back
; (next) decrement top of return stack
XNEXT:
pop zh
pop zl
pop xh
pop xl
sbiw xl, 1
push xl
push xh
ijmp
Mike
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-07 10:57 -0700 |
| Message-ID | <7xa9vy4139.fsf@ruckus.brouhaha.com> |
| In reply to | #15967 |
Mikael Nordman <oh2aun@invalid.com> writes: > 181 ms on PIC24 @ 54 MHz > 750 ms on PIC18 @ 48 MHz > 4154 ms on Atmega 328 @ 8 Mhz Out of curiosity I tried it in JSForth in Firefox 15 on my Core 2 laptop: http://forthfreak.net/jsforth80x25.html I don't have a convenient way to time it precisely but I'd guess it used around 1/8 of a second.
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | comp.lang.forth
csiph-web