On Friday, December 10, 2021 at 1:43:52 PM UTC-5, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
> > the GA144 ... It's an embedded computer, an MCU which has a very
> > different application space. Unfortunately, the GA144 has no
> > identified application space, so it has no market and no sales to
> > speak of. I bought three of them. Does that count?
> If you bought 3 chips that's 432 processors, so it's a start ;-).

A start of what? I don't think GA got very far with my $50 or whatever I paid.

> More srsly an MCU with ~128 bytes of ram (like the midrange ATTinys) is
> perfectly useful and respectable.

Yes, useful and respectable for tiny tasks that require a $1 MCU. The GA144 is more like $10 in quantity. Trying to use multiple such ATTiny processors in a chain gang for something useful is a much, much narrower market. I do recall seeing a mall light display that used many separate controllers all controlled over a single wire. Many ATTiny chips could have been used, but not a GA144.

> I've been programming those things a
> little bit recently. But, they usually have 4K or more of program store
> on the MCU. Having to use the GA144 ram as program memory (sharing it
> with application data), or being limited to the 64 words (= 144 bytes)
> of mask rom at each node, is horribly constricting, as the code on the
> GA site shows. They had to do crazy things to make even simple programs
> fit.

If you rub elbows with the GA144 gang they will talk about shipping different code to each processor as needed, it can even execute code as it is arriving over a com port. They also talk about decomposing your program into pieces so it can map to many F18A processors in the GA144. Talk is easy, such a mapping is not so easy for other than a small class of applications.

> It also didn't help that the Polyforth VM that they include in the rom
> on 3 the of the GA144 nodes is completely undocumented.

Documentation is not a hallmark of Forth and even parts of the GA144 are not documented. When I asked for the timing data I required I was suspected of wanting to reverse engineer their device and told I could measure the timing myself. Yes, as a customer I want to be in the business of characterizing *THEIR* devices.

> They were very
> eager for someone to target a C compiler to the GA144, so I remember
> looking at the code for that VM but finding it more confusing than I was
> willing to deal with.

Like much of the software for the GA144.

> They said something at one point about a later chip possibly having
> flash memory for programs, which would help a lot. Flash apparently
> needs a different fab process. A block of ram would be just as good
> though. Was there ever even a proposed application that would use most
> or all of the 144 nodes? The GA144's predecessor (the SeaFORTH) had 40
> nodes, and I think there may have been one with 28 nodes, maybe earlier.
> So if they replaced half the GA144's nodes with ram, they might have
> been better off.

You could have stopped at, "Was there ever even a proposed application?"

> I had one idea for a GA144 application that couldn't easily be done in a
> conventional MCU because it needed very low latency i/o (a few ns from
> input to output), but I decided after a while that it would be easier to
> do that with a small FPGA.

Yeah, I use an FPGA on the board I'm currently selling exactly because of one interface that requires faster response than an MCU can manage. It is probably faster than the GA144 can manage realistically. The device has a register file which is written and read by the host over a serial port much like SPI. On the last 33 MHz clock rising edge the host sends a control flag to indicate that is the end of the command. On the next falling edge the host reads in the first bit of the data produced by the command... 15 ns after the command is received. That was hard to do with an FPGA even. I had to play some games with decoding the command first and registering the result in that rising edge so the 15 ns is available for selecting the right bit, routing it out of the chip and giving the host some setup time.

No, that's not possible in a GA144 even at 700 MIPS.

> Wayne Morellini is right that we don't have ironclad mathematical proof
> that GA isn't getting billion-dollar deals from hush-hush customers and
> keeping quiet about them. But, in the real world, such deals would
> result in financial expansion of the company, that would be visible as
> new hiring, new products, carefully worded announcements, GA staff
> driving Ferraris around, etc. So there is decent practical inference
> that such deals aren't happening.

I wasn't even talking about huge deals. Any sort of sales would eventually deplete the existing chips they built. When that happens they would place another small order with the foundry and make an announcement that the company is well and the GA144 is not wasting away. No need to imagine customers with NDAs, etc.

> I do keep wondering how many LUT4 it would take to implement an F18-like
> processor (e.g. b16-small) in an FPGA. There is supposedly a 50 cent
> FPGA now with 1000 LUT (no idea of block ram). If a reasonably fast
> stack processor can fit in < 500 of that, leaving the user 500 for other
> purposes, that seems like a useful alternative to the RISC-V that
> everyone wants to use now. It apparently takes 1000 LUT to make even a
> very slow RISC-V.

I'm pretty confident the entire CPU other than the comms links could be easily done in a 1000 4LUT device if it has block RAM. I don't really know enough about the comms ports to know how large they might be, but I don't think they would take up much space. This all would be synchronous rather than async, so that would be different for sure. Some of the smaller FPGAs have very low power requirements, so that part could pair up pretty well with the GA144.

--

Rick C.

--+- Get 1,000 miles of free Supercharging
--+- Tesla referral code - https://ts.la/richard11209

On Friday, December 10, 2021 at 2:49:54 PM UTC-5, Nickolay Kolchin wrote:
> On Friday, December 10, 2021 at 9:43:52 PM UTC+3, Paul Rubin wrote:
> > Rick C <gnuarm.del...@gmail.com> writes:
> > More srsly an MCU with ~128 bytes of ram (like the midrange ATTinys) is
> > perfectly useful and respectable. I've been programming those things a
> > little bit recently. But, they usually have 4K or more of program store
> > on the MCU. Having to use the GA144 ram as program memory (sharing it
> > with application data), or being limited to the 64 words (= 144 bytes)
> > of mask rom at each node, is horribly constricting, as the code on the
> > GA site shows. They had to do crazy things to make even simple programs
> > fit.
> >
> ATTiny make sense only in legacy applications. Cortex-M0 solutions are
> much more powerful at lesser price.

I have no idea why you say that. CM0 processors may be small and cheap, but basically just hold their own against 8 bit MCUs. Having more capability is only useful if you *have* a use for it. They still sell no small quantity of 4 bit MCUs, not because they are "legacy" applications, but because these parts are cheaper for the application.

> Does GA144 have any practical usage beyond research papers? AFAIK, there
> are no commercial products based on GA144...

More importantly, it is hard to devise a practical application where a GA144 does the job in a better way than any other device. I'm not saying there are none, but they are few and far between and mostly not worth getting involved in the software for the GA144.

--

Rick C.

--++ Get 1,000 miles of free Supercharging
--++ Tesla referral code - https://ts.la/richard11209

On Friday, December 10, 2021 at 3:24:55 PM UTC-5, Paul Rubin wrote:
> I believe GA tried to land some kind of deal making an electronic
> signboard of some sort, using GA144 nodes to control a bunch of
> different lighting elements. However, the customer apparently switched
> to a conventional approach at the last minute.

Where did you hear that?

--

Rick C.

-+-- Get 1,000 miles of free Supercharging
-+-- Tesla referral code - https://ts.la/richard11209

On Saturday, December 11, 2021 at 2:03:34 AM UTC+3, gnuarm.del...@gmail.com wrote:
> On Friday, December 10, 2021 at 2:49:54 PM UTC-5, Nickolay Kolchin wrote:
> > On Friday, December 10, 2021 at 9:43:52 PM UTC+3, Paul Rubin wrote:
> > > Rick C <gnuarm.del...@gmail.com> writes:
> > > More srsly an MCU with ~128 bytes of ram (like the midrange ATTinys) is
> > > perfectly useful and respectable. I've been programming those things a
> > > little bit recently. But, they usually have 4K or more of program store
> > > on the MCU. Having to use the GA144 ram as program memory (sharing it
> > > with application data), or being limited to the 64 words (= 144 bytes)
> > > of mask rom at each node, is horribly constricting, as the code on the
> > > GA site shows. They had to do crazy things to make even simple programs
> > > fit.
> > >
> > ATTiny make sense only in legacy applications. Cortex-M0 solutions are
> > much more powerful at lesser price.
> I have no idea why you say that. CM0 processors may be small and cheap, but basically just hold their own against 8 bit MCUs. Having more capability is only useful if you *have* a use for it. They still sell no small quantity of 4 bit MCUs, not because they are "legacy" applications, but because these parts are cheaper for the application.

I don't follow you. Cortex-M0 have more I/O, more RAM, more Flash, more
HZ, less power consumption and price starts from $0.35 at Digikey. There
are zero reasons to choose 8-bit MCU unless:

- You already have a board that needs small customisation.
- You already have software for 8-bit
- You know nothing about Cortex and don't want to learn.

And 4-bit MCU are blast from past. I can't even imagine situation when this
things may be used in new designs...

> > Does GA144 have any practical usage beyond research papers? AFAIK, there
> > are no commercial products based on GA144...
> More importantly, it is hard to devise a practical application where a GA144 does the job in a better way than any other device. I'm not saying there are none, but they are few and far between and mostly not worth getting involved in the software for the GA144.

About 5-7 years ago, we briefly considered GA144 for application that required
extremely low power consumption. But programming looked too complex and
the idea was ditched.

Rick C <gnuarm.deletethisbit@gmail.com> writes:
>> I believe GA tried to land some kind of deal making an electronic
>> signboard of some sort
> Where did you hear that?

Probably here on CLF some ways back. I don't remember more specifics.

Meanwhile, there are LEDs like the APA102 ("dotstar") that have their
own tiny MCU connected to the RGB led die, so you can put them on an SPI
bus and address them individually, tell them to change color, etc. It
would sure be nice if the on-led mcu was itself programmable and there
was a shared clock bus, so you could do stuff like marquee displays
without having to control each individual led from a centralized
processor.

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> They still sell no small quantity of 4 bit MCUs, not because they are
> "legacy" applications, but because these parts are cheaper for the
> application.

I didn't realize 4 bit mcu's were still a thing, at least packaged ones,
instead of being in a corner of an asic or something. There are Padauk
8-bit MCU'S that get as low as 3 cents each though. I don't think you
can get a Cortex M0 MCU for that.

As for the ATTiny, I've heard it described as a fairly nice
multi-function analog chip with a marginally useful digital cpu
attached, to coordinate the analog stuff. Cortex M0 MCU's in that story
are fairly nice digital cpu's with marginally useful analog peripherals
attached, to communicate with the outside world.

On Saturday, December 11, 2021 at 3:29:06 AM UTC+3, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
> > They still sell no small quantity of 4 bit MCUs, not because they are
> > "legacy" applications, but because these parts are cheaper for the
> > application.
> I didn't realize 4 bit mcu's were still a thing, at least packaged ones,
> instead of being in a corner of an asic or something. There are Padauk
> 8-bit MCU'S that get as low as 3 cents each though. I don't think you
> can get a Cortex M0 MCU for that.

Never heard about Padauk before. I was tricked by Digikey pricing on
8-MCUs.

>
> As for the ATTiny, I've heard it described as a fairly nice
> multi-function analog chip with a marginally useful digital cpu
> attached, to coordinate the analog stuff. Cortex M0 MCU's in that story
> are fairly nice digital cpu's with marginally useful analog peripherals
> attached, to communicate with the outside world.

Sounds doubtful. Can you share some links on subject?

On Friday, December 10, 2021 at 11:43:52 AM UTC-7, Paul Rubin wrote:
> Wayne Morellini is right that we don't have ironclad mathematical proof
> that GA isn't getting billion-dollar deals from hush-hush customers and
> keeping quiet about them. But, in the real world, such deals would
> result in financial expansion of the company, that would be visible as
> new hiring, new products, carefully worded announcements, GA staff
> driving Ferraris around, etc. So there is decent practical inference
> that such deals aren't happening.

When I first heard about the GA144, my assumption was that the
"killer app" was encryption cracking. This involves trying out a lot of
possible keys --- the keys are chosen by some heuristic to hopefully
try out the more likely ones first --- the try-out keys still have to be
tested though, and this can be done in parallel.

As for Charles Moore driving a Ferrari, this seems unlikely.
If he is making money from the NSA, he would want to keep a low profile.
Most people would consider this to be dirty money.

On Saturday, December 11, 2021 at 4:43:52 AM UTC+10, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
> > the GA144 ... It's an embedded computer, an MCU which has a very
> > different application space. Unfortunately, the GA144 has no
> > identified application space, so it has no market and no sales to
> > speak of. I bought three of them. Does that count?
> If you bought 3 chips that's 432 processors, so it's a start ;-).
>
> More srsly an MCU with ~128 bytes of ram (like the midrange ATTinys) is
> perfectly useful and respectable. I've been programming those things a
> little bit recently. But, they usually have 4K or more of program store
> on the MCU. Having to use the GA144 ram as program memory (sharing it
> with application data), or being limited to the 64 words (= 144 bytes)
> of mask rom at each node, is horribly constricting, as the code on the
> GA site shows. They had to do crazy things to make even simple programs
> fit.

If they had 4 cores with 1MB each, with one having access to all MB, and shared memory in between (either as part of the 4MB, or in-between the 1MB areas) 20 years ago, we would go yahoo! The data passing would be really quick, even just pointer passing or just that a preknown area is now free, and to swap from the other area when you are finished with it. and The main cpu could use the other CPUs for parallel processing. It would look like either a big memory segment on the middle, with 4 cores around it, or 4 cores in a pool of memory )sea of memory). We can see twenty of years ago, that would be revolutionary, for us, but this also applies to how the current chips could have been designed, with their shared memory in between the chips for quick message passing, and substantial code and data space. Using dual memory access techniques, every inner core has direct access to 16 cores of memory. If only the energy could be low enough, a large amount of energy beats the existing cons scheme, when used. I would make it so that any segment of memory is not used, it is turned off. But, in this scheme, a simple come file system could use unused segments as long term storage for data not requiring high speed use or access, put aside. With the data with higher need being parked close to where it's to be used, preferably in the processors prime memory space, if any left (for efficiency). But, you can change your ratio here, to suite potential applications. At the moment, you combine present memory, for a high compatibility version at virtually the same energy requirements. Going a step up, you take all that plus drop every second core, to divert to memory, to enlarge that memory pool. With both, you can use the existing communications, or memory message passing, with existing comparability. You have the processors and memory stripped, but you could do rows, where a CPU can reach 6 memory spaces. Still not much memory, but easier. Now, if you replace more cores, you get to a processors surrounded by memory. This might be small or as large as required.

Now, if we step back. We realise we can have one core with a large memory access, passing work to the array. But, the array can still accept data directly off chip, independently of the main processor, and process it across the chip and pas it out, and still maintain soft compatibility with the current chip. But, here, we can see there is a further opportunity. The main chip could have access to all memory on chip, and the ability to use an attached memory die in a cheap multi chip module type. Which memory that is addressed, is based on what part of the address space which is used. Slow down only happens when there is conflicting access requests, but proper programming only does that when needed. If you have to depend on compensating for the programmer doing the wrong thing, you reduce fine efficiency. You should depend on the programmer normally doing the right thing (outside of errors). Now, performance from the off memory die can be based on the memory being serialed in from off chip into a memory segment that the processor then performs as it loads, in n associative memory model. In cheap mass memory models, they rely on this serial segment nature, so, you are still going have to wait for that memory to perform anyway. Here, if you do it right, you only really pay if you branch forwards. In other words, the segment is a little cache. But, the present misc memory is within these sorts of memory chip segment ranges. Now, you have a chip you can package with or without extra memory.

Now, one other great improvement, is to switch to phase signalling, even for on chip inter processor communications. You still maintain some comparability, but greatly expand usability and programming ease.

The memory as the wire.

Anyway, why can't we do memory as a grid, using silicon on insulator capacitive memory techniques. No transistors needed in the grid, greater density.. Speed and reliability? But, there are a lot of things which have to hang around before they are used.
How come they weren't doing stuff like this?

> It also didn't help that the Polyforth VM that they include in the rom
> on 3 the of the GA144 nodes is completely undocumented. They were very
> eager for someone to target a C compiler to the GA144, so I remember
> looking at the code for that VM but finding it more confusing than I was
> willing to deal with.

Yes, those were some obvious advancements. But, again, a single processor with a big memory, could have done that at speed. Passing out work to the array. An interrupt being replaced by a communications from a processor that either receives a pull on a pin, or decided it needs one. In geoworks, they used a simple control passing model. Being the programmer with a single code set, you control a the responses, so it's not a problem. The main processor can perform units of work, occasionally checking if a message is to be serviced. The processor sending the message, can already be working on a response and parallel, or even have surrounding processors contributing. You are at liberty to make it work as best as you can.

...

> So if they replaced half the GA144's nodes with ram, they might have
> been better off.

...

> Wayne Morellini is right that we don't have ironclad mathematical proof
> that GA isn't getting billion-dollar deals from hush-hush customers and
> keeping quiet about them. But, in the real world, such deals would
> result in financial expansion of the company, that would be visible as
> new hiring, new products, carefully worded announcements, GA staff
> driving Ferraris around, etc. So there is decent practical inference
> that such deals aren't happening.

Lol! They should be signing deals worth billions, but the indication is, they have been surviving, which means they are maybe doing little more than what we already know, tech development demos for companies looking at using their products. But, then we don't know about other funding. I, in no way, think there are billions flowing around. However, maybe under SF or GA, they were over here doing stuff with the bionic ear mob, and after they announced a super hearing aid (not to mention the existing internal hearing aid could benefit) and received some advise ce how it could be fine easier, and a cheaper version came out.

Where this is a big market, is as an alternative to arm. AMD, had multiple times tried to do it with mips (or was it SPARC). You could approach such a company with a sweet heart of the sweet heart deals. A separate company owned by AMD mostly. Joint development of an advanced ARM alternative. They contribute, GA designs, they contribute to the design, and GA contributes a better design, and so on, until you reach a very good design that AMD is very happy with on performance. You may still offer custom design, you offer something for the current GA market, the MCU market, and the ARM market. AMD, gets three new product lines they don't service very much, and a custom design facility for big customers, that say Google could approach to design a new device. AMD staff learn how to design this stuff, and current staff, can retire. Then the AMD staff design increasingly better stuff to compete with arm etc. AMD can then archive the sort of portable device penetration they always wanted. Notice, here I'm saying, the main design to sell on, is the advanced 32 bit+ design.

On Sat, 11 Dec 2021, 13:51 Hugh Aguilar, <hughaguilar96@gmail.com> wrote:
On Friday, December 10, 2021 at 11:43:52 AM UTC-7, Paul Rubin wrote:
> Wayne Morellini is right that we don't have ironclad mathematical proof
> that GA isn't getting billion-dollar deals from hush-hush customers and
> keeping quiet about them. But, in the real world, such deals would
> result in financial expansion of the company, that would be visible as
> new hiring, new products, carefully worded announcements, GA staff
> driving Ferraris around, etc. So there is decent practical inference
> that such deals aren't happening.

When I first heard about the GA144, my assumption was that the
"killer app" was encryption cracking. This involves trying out a lot of
possible keys --- the keys are chosen by some heuristic to hopefully
try out the more likely ones first --- the try-out keys still have to be
tested though, and this can be done in parallel.

As for Charles Moore driving a Ferrari, this seems unlikely.
If he is making money from the NSA, he would want to keep a low profile.
Most people would consider this to be dirty money.

On Friday, December 10, 2021 at 7:24:24 PM UTC-5, Nickolay Kolchin wrote:
> On Saturday, December 11, 2021 at 2:03:34 AM UTC+3, gnuarm.del...@gmail.com wrote:
> > On Friday, December 10, 2021 at 2:49:54 PM UTC-5, Nickolay Kolchin wrote:
> > > On Friday, December 10, 2021 at 9:43:52 PM UTC+3, Paul Rubin wrote:
> > > > Rick C <gnuarm.del...@gmail.com> writes:
> > > > More srsly an MCU with ~128 bytes of ram (like the midrange ATTinys) is
> > > > perfectly useful and respectable. I've been programming those things a
> > > > little bit recently. But, they usually have 4K or more of program store
> > > > on the MCU. Having to use the GA144 ram as program memory (sharing it
> > > > with application data), or being limited to the 64 words (= 144 bytes)
> > > > of mask rom at each node, is horribly constricting, as the code on the
> > > > GA site shows. They had to do crazy things to make even simple programs
> > > > fit.
> > > >
> > > ATTiny make sense only in legacy applications. Cortex-M0 solutions are
> > > much more powerful at lesser price.
> > I have no idea why you say that. CM0 processors may be small and cheap, but basically just hold their own against 8 bit MCUs. Having more capability is only useful if you *have* a use for it. They still sell no small quantity of 4 bit MCUs, not because they are "legacy" applications, but because these parts are cheaper for the application.
> I don't follow you. Cortex-M0 have more I/O, more RAM, more Flash, more
> HZ, less power consumption and price starts from $0.35 at Digikey. There
> are zero reasons to choose 8-bit MCU unless:
>
> - You already have a board that needs small customisation.
> - You already have software for 8-bit
> - You know nothing about Cortex and don't want to learn.

I don't know what part of cheaper you don't understand. If you don't need any of the things you list the CM0 has that the 8 bit part doesn't and the 8 bit part is cheaper, you use the 8 bit part. When working in high volumes you save every penny possible, literally.

BTW, I don't find the $0.35 part you mention, or actually I do, but it is an obsolete part. The lowest priced active part Digikey lists is $0.44 but is in a WLCSP fine pitch package which requires very fine features on the PWB, again a higher cost issue.

The cheapest part in a leaded package is $0.49 and uses a 20 pin SSOP package. If that package is not suitable the next cheapest part is $0.70. Also, there is something screwy about the price. That part is listed as $0.44, but on the order page you have to buy tubes to get that price, otherwise it is $1.17. No one wants to work with tubes. Tape and reel is the preferred package. The $0.70 part is not from Digikey, but rather Rochester and is in *bulk*!!! That means the parts are in a plastic bag. To order on a reel the part is now $1.05.

> And 4-bit MCU are blast from past. I can't even imagine situation when this
> things may be used in new designs...

Yes, that's true. You can't imagine. The reality is if you have a high volume application where every penny counts, you can develop and validate a design using an 8 bit MCU, give that design to an Asian manufacturer and they will supply you with 4 bit MCUs that will do the same job the same way at a lower price.

> > > Does GA144 have any practical usage beyond research papers? AFAIK, there
> > > are no commercial products based on GA144...
> > More importantly, it is hard to devise a practical application where a GA144 does the job in a better way than any other device. I'm not saying there are none, but they are few and far between and mostly not worth getting involved in the software for the GA144.
> About 5-7 years ago, we briefly considered GA144 for application that required
> extremely low power consumption. But programming looked too complex and
> the idea was ditched.

Yeah, programming a GA144 is a bitch. Simple test cases are not at all bad, but a real world application gets very ugly, very fast. It's not clear to me the GA144 is really all that low power. If you use processors they consume about a mA or two each as I recall. If you aren't using the GA144 processors much other types of MCUs can also achieve low idle power. To need the GA144 for low power work means your design has to fit in a particular corner where the transition between sleep and running full speed has to be rapid (conventional processors require wake up time for their oscillators to turn on) AND the timing has to be totally non-critical so the processors can run asynchronously. If these conditions are not part of your design, you can use a standard MCU and live a rich, full life.

Looking back, I see many examples of GA information focusing on one or another view of the GA144 where it seemed to have an advantage, but only in isolation rather than looking at real world designs. The whole issue of the processors being async is not of much value other than being able to stop on a dime. Real world apps virtually always require clocking in some manner to stay in sync with the outside world, either a clock signal or a data handshake is always needed unless it is some sort of totally self contained app like a watch type video game. What were those things called where you had a virtual pet on your wrist?

--

Rick C.

-+-+ Get 1,000 miles of free Supercharging
-+-+ Tesla referral code - https://ts.la/richard11209

On Friday, December 10, 2021 at 7:24:59 PM UTC-5, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
> >> I believe GA tried to land some kind of deal making an electronic
> >> signboard of some sort
> > Where did you hear that?
> Probably here on CLF some ways back. I don't remember more specifics.

I didn't mean which street corner. I mean who would have such knowledge of GA144 applications and be able to talk about it? This is the sort of thing that *is* covered by NDA.

> Meanwhile, there are LEDs like the APA102 ("dotstar") that have their
> own tiny MCU connected to the RGB led die, so you can put them on an SPI
> bus and address them individually, tell them to change color, etc. It
> would sure be nice if the on-led mcu was itself programmable and there
> was a shared clock bus, so you could do stuff like marquee displays
> without having to control each individual led from a centralized
> processor.

I don't know why you say these LED drivers are MCUs. I am familiar with such devices and they are probably just three counters to count the duty cycle. The serial interface is very simple so a one shot (digital or analog) can discriminate one pulses from zero pulses.

The "RGB" die does not contain the digital logic in any event. The "RGB" die isn't even one die. There are a total of four dice, one each for R, G and B and a digital driver chip to support comms and PWM drive the LEDs. The colors of an LED are produced by different doping agents so it's not possible to make different colors on a single die. There are many close up images of these parts available that clearly show the separate dice.

--

Rick C.

-++- Get 1,000 miles of free Supercharging
-++- Tesla referral code - https://ts.la/richard11209

On Saturday, December 11, 2021 at 12:26:28 PM UTC+3, gnuarm.del...@gmail.com wrote:
> On Friday, December 10, 2021 at 7:24:24 PM UTC-5, Nickolay Kolchin wrote:
> > On Saturday, December 11, 2021 at 2:03:34 AM UTC+3, gnuarm.del...@gmail..com wrote:
> > > On Friday, December 10, 2021 at 2:49:54 PM UTC-5, Nickolay Kolchin wrote:
> > > > On Friday, December 10, 2021 at 9:43:52 PM UTC+3, Paul Rubin wrote:
> > > > > Rick C <gnuarm.del...@gmail.com> writes:
> > > > > More srsly an MCU with ~128 bytes of ram (like the midrange ATTinys) is
> > > > > perfectly useful and respectable. I've been programming those things a
> > > > > little bit recently. But, they usually have 4K or more of program store
> > > > > on the MCU. Having to use the GA144 ram as program memory (sharing it
> > > > > with application data), or being limited to the 64 words (= 144 bytes)
> > > > > of mask rom at each node, is horribly constricting, as the code on the
> > > > > GA site shows. They had to do crazy things to make even simple programs
> > > > > fit.
> > > > >
> > > > ATTiny make sense only in legacy applications. Cortex-M0 solutions are
> > > > much more powerful at lesser price.
> > > I have no idea why you say that. CM0 processors may be small and cheap, but basically just hold their own against 8 bit MCUs. Having more capability is only useful if you *have* a use for it. They still sell no small quantity of 4 bit MCUs, not because they are "legacy" applications, but because these parts are cheaper for the application.
> > I don't follow you. Cortex-M0 have more I/O, more RAM, more Flash, more
> > HZ, less power consumption and price starts from $0.35 at Digikey. There
> > are zero reasons to choose 8-bit MCU unless:
> >
> > - You already have a board that needs small customisation.
> > - You already have software for 8-bit
> > - You know nothing about Cortex and don't want to learn.
> I don't know what part of cheaper you don't understand. If you don't need any of the things you list the CM0 has that the 8 bit part doesn't and the 8 bit part is cheaper, you use the 8 bit part. When working in high volumes you save every penny possible, literally.
>
> BTW, I don't find the $0.35 part you mention, or actually I do, but it is an obsolete part. The lowest priced active part Digikey lists is $0.44 but is in a WLCSP fine pitch package which requires very fine features on the PWB, again a higher cost issue.
>
> The cheapest part in a leaded package is $0.49 and uses a 20 pin SSOP package. If that package is not suitable the next cheapest part is $0.70. Also, there is something screwy about the price. That part is listed as $0.44, but on the order page you have to buy tubes to get that price, otherwise it is $1.17. No one wants to work with tubes. Tape and reel is the preferred package. The $0.70 part is not from Digikey, but rather Rochester and is in *bulk*!!! That means the parts are in a plastic bag. To order on a reel the part is now $1.05.
> > And 4-bit MCU are blast from past. I can't even imagine situation when this
> > things may be used in new designs...
> Yes, that's true. You can't imagine. The reality is if you have a high volume application where every penny counts, you can develop and validate a design using an 8 bit MCU, give that design to an Asian manufacturer and they will supply you with 4 bit MCUs that will do the same job the same way at a lower price.

Your calculations make sense only for projects will many millions units shipment
expectation. And these are rare even on IOT market.

On Saturday, December 11, 2021 at 7:07:48 AM UTC-5, Nickolay Kolchin wrote:
> On Saturday, December 11, 2021 at 12:26:28 PM UTC+3, gnuarm.del...@gmail.com wrote:
> > On Friday, December 10, 2021 at 7:24:24 PM UTC-5, Nickolay Kolchin wrote:
> > > And 4-bit MCU are blast from past. I can't even imagine situation when this
> > > things may be used in new designs...
> > Yes, that's true. You can't imagine. The reality is if you have a high volume application where every penny counts, you can develop and validate a design using an 8 bit MCU, give that design to an Asian manufacturer and they will supply you with 4 bit MCUs that will do the same job the same way at a lower price.
> Your calculations make sense only for projects will many millions units shipment
> expectation. And these are rare even on IOT market.

Nonsense! Virtually every product sold at Walmart or any other retail establishment is sold in the millions. Looking around me I see what probably amounts to some dozen or two MCUs depending on how many MCUs are in my laptop. The window AC unit and remote almost certainly have 4 or 8 bit MCUs as well as the ceiling light fixture and it's remote. The dorm size refrigerator likely has a 4 or 8 bit MCU. My car remote most likely has a 4 or 8 bit MCU. My other car remote likely has a 4 or 8 bit MCU. I don't know what they put in laptops these days. PC keyboards used to have an 8 bit MCU. Now it's either that or integrated with some other chip. I have an LED measuring unit in my bag which might have a 32 bit MCU for the math.

That's six to one for the 8 bitters. Heck, even if a product only sells a few hundred thousand, a dime difference in cost means a few tens of thousands of dollars. Yeah, no one with half a brain leaves that on the table.

Besides, what you said was,

> There are zero reasons to choose 8-bit MCU unless:
>
> - You already have a board that needs small customisation.
> - You already have software for 8-bit
> - You know nothing about Cortex and don't want to learn.

I'm just refuting your statements. Cost is a valid and significant reason to choose an MCU other than a 32 bit ARM. If you check any source of market info you will find the volume of 8 bit MCU units shipped is as high as 32 bit units and continues to grow clearly indicating continued new design starts. The 32 bit unit sales by dollars is higher, but then we know the reason for that.

--

Rick C.

-+++ Get 1,000 miles of free Supercharging
-+++ Tesla referral code - https://ts.la/richard11209

On Saturday, December 11, 2021 at 4:50:34 PM UTC+3, gnuarm.del...@gmail.com wrote:
> On Saturday, December 11, 2021 at 7:07:48 AM UTC-5, Nickolay Kolchin wrote:
> > On Saturday, December 11, 2021 at 12:26:28 PM UTC+3, gnuarm.del...@gmail.com wrote:
> > > On Friday, December 10, 2021 at 7:24:24 PM UTC-5, Nickolay Kolchin wrote:
> > > > And 4-bit MCU are blast from past. I can't even imagine situation when this
> > > > things may be used in new designs...
> > > Yes, that's true. You can't imagine. The reality is if you have a high volume application where every penny counts, you can develop and validate a design using an 8 bit MCU, give that design to an Asian manufacturer and they will supply you with 4 bit MCUs that will do the same job the same way at a lower price.
> > Your calculations make sense only for projects will many millions units shipment
> > expectation. And these are rare even on IOT market.
> Nonsense! Virtually every product sold at Walmart or any other retail establishment is sold in the millions. Looking around me I see what probably amounts to some dozen or two MCUs depending on how many MCUs are in my laptop. The window AC unit and remote almost certainly have 4 or 8 bit MCUs as well as the ceiling light fixture and it's remote. The dorm size refrigerator likely has a 4 or 8 bit MCU. My car remote most likely has a 4 or 8 bit MCU. My other car remote likely has a 4 or 8 bit MCU. I don't know what they put in laptops these days. PC keyboards used to have an 8 bit MCU. Now it's either that or integrated with some other chip. I have an LED measuring unit in my bag which might have a 32 bit MCU for the math.
>
> That's six to one for the 8 bitters. Heck, even if a product only sells a few hundred thousand, a dime difference in cost means a few tens of thousands of dollars. Yeah, no one with half a brain leaves that on the table.
>
> Besides, what you said was,
> > There are zero reasons to choose 8-bit MCU unless:
> >
> > - You already have a board that needs small customisation.
> > - You already have software for 8-bit
> > - You know nothing about Cortex and don't want to learn.
> I'm just refuting your statements. Cost is a valid and significant reason to choose an MCU other than a 32 bit ARM. If you check any source of market info you will find the volume of 8 bit MCU units shipped is as high as 32 bit units and continues to grow clearly indicating continued new design starts. The 32 bit unit sales by dollars is higher, but then we know the reason for that.
>

You don't understand how economics works at this scale.

1. When you order 10M chips, you don't buy them on digikey. You make
direct contact with manufacturer. And price will be completely
different.

2. You don't choose components using price as the only metric. If you
desire stable production in millions, you must also evaluate logistics
and manufacturer stability. And this may be more important than price.

3. You should count programmers work. I.e. for well-known hardware with
large library backlog like STM32 -- you need 2 man. For limited
hardware which is unknown to developers, you may need bigger team or
more time for software development. This leads to budget increase in
several hundreds of thousands dollars.

You don't understand that 4/8-bits devices you see around, were
designed decades ago. They are still sold and produced, cause the
process is established and there is no need to fix "working thing".

For example, we reused old ATmega board for "land detector" on new
Helicopter. We have a lot of them in stock, programming required only
several dozens lines of code, board is already well tested and
certified. If we use modern MCU, the board will be smaller, more
powerful and consume less energy. But why waste time when we already
have ready to use solution?

Paul Rubin <no.email@nospam.invalid> writes:
>If you bought 3 chips that's 432 processors, so it's a start ;-).

On first reading, I thought about the iAPX432, which I remembered to
consist of 3 chips[1]. Of course, it was unlikely that you meant
that, so I then reinterpreted this with a more likely meaning: 3 GA144
chips.

[1] It's actually a little different:
<https://en.wikipedia.org/wiki/Intel_iAPX_432#Development> says: The
core of the design - the main processor - was termed the General Data
Processor (GDP) and built as two integrated circuits: one (the 43201)
to fetch and decode instructions, the other (the 43202) to execute
them. Most systems would also include the 43203 Interface Processor
(IP) which operated as a channel controller for I/O, and an Attached
Processor (AP), a conventional Intel 8086 which provided "processing
power in the I/O subsystem"

>I do keep wondering how many LUT4 it would take to implement an F18-like
>processor (e.g. b16-small) in an FPGA.

I dimly remember this being discussed here, with the b16-small costing
~300 LUTs and the b16-dsp costing ~600 LUTs (concerning the b16 name:
Bernd Paysan first developed the b16-dsp under the name b16, then the
b16-small under the name b16-small; in a later presentation he renamed
the b16-dsp into b16-dsp, and the b16-small into b16).

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On Saturday, December 11, 2021 at 10:06:56 AM UTC-5, Nickolay Kolchin wrote:
> On Saturday, December 11, 2021 at 4:50:34 PM UTC+3, gnuarm.del...@gmail.com wrote:
> > On Saturday, December 11, 2021 at 7:07:48 AM UTC-5, Nickolay Kolchin wrote:
> > > On Saturday, December 11, 2021 at 12:26:28 PM UTC+3, gnuarm.del...@gmail.com wrote:
> > > > On Friday, December 10, 2021 at 7:24:24 PM UTC-5, Nickolay Kolchin wrote:
> > > > > And 4-bit MCU are blast from past. I can't even imagine situation when this
> > > > > things may be used in new designs...
> > > > Yes, that's true. You can't imagine. The reality is if you have a high volume application where every penny counts, you can develop and validate a design using an 8 bit MCU, give that design to an Asian manufacturer and they will supply you with 4 bit MCUs that will do the same job the same way at a lower price.
> > > Your calculations make sense only for projects will many millions units shipment
> > > expectation. And these are rare even on IOT market.
> > Nonsense! Virtually every product sold at Walmart or any other retail establishment is sold in the millions. Looking around me I see what probably amounts to some dozen or two MCUs depending on how many MCUs are in my laptop. The window AC unit and remote almost certainly have 4 or 8 bit MCUs as well as the ceiling light fixture and it's remote. The dorm size refrigerator likely has a 4 or 8 bit MCU. My car remote most likely has a 4 or 8 bit MCU. My other car remote likely has a 4 or 8 bit MCU. I don't know what they put in laptops these days. PC keyboards used to have an 8 bit MCU. Now it's either that or integrated with some other chip. I have an LED measuring unit in my bag which might have a 32 bit MCU for the math.
> >
> > That's six to one for the 8 bitters. Heck, even if a product only sells a few hundred thousand, a dime difference in cost means a few tens of thousands of dollars. Yeah, no one with half a brain leaves that on the table.
> >
> > Besides, what you said was,
> > > There are zero reasons to choose 8-bit MCU unless:
> > >
> > > - You already have a board that needs small customisation.
> > > - You already have software for 8-bit
> > > - You know nothing about Cortex and don't want to learn.
> > I'm just refuting your statements. Cost is a valid and significant reason to choose an MCU other than a 32 bit ARM. If you check any source of market info you will find the volume of 8 bit MCU units shipped is as high as 32 bit units and continues to grow clearly indicating continued new design starts. The 32 bit unit sales by dollars is higher, but then we know the reason for that.
> >
> You don't understand how economics works at this scale.

Wow! You just don't give up do you? You need to know when you are beaten.

> 1. When you order 10M chips, you don't buy them on digikey. You make
> direct contact with manufacturer. And price will be completely
> different.

Yeah, but you don't have that pricing and there is no reason to think a 32 bit ARM using a larger die will cost less at any quantity than an 8 bit MCU on a smaller die.

> 2. You don't choose components using price as the only metric. If you
> desire stable production in millions, you must also evaluate logistics
> and manufacturer stability. And this may be more important than price.

And none of this is the issue being discussed. I refer you to your statement quoted above...

"There are zero reasons to choose 8-bit MCU unless:"...

> 3. You should count programmers work. I.e. for well-known hardware with
> large library backlog like STM32 -- you need 2 man. For limited
> hardware which is unknown to developers, you may need bigger team or
> more time for software development. This leads to budget increase in
> several hundreds of thousands dollars.

Wow! You are really reaching... The guy who showed me how important it was to save every penny was designing children's' toys, apparently a cutthroat business where the design review would argue over a single resistor as it means thousands of dollars in profit. The designer was an individual, so none of your "teams". He was also under very tight schedules as Santa waits for no toy.

> You don't understand that 4/8-bits devices you see around, were
> designed decades ago. They are still sold and produced, cause the
> process is established and there is no need to fix "working thing".

Sorry, that is pure BS. Every microwave oven doesn't use the same part with the same programming that was done "decades ago". That is literally your noise that you just made up!

> For example, we reused old ATmega board for "land detector" on new
> Helicopter. We have a lot of them in stock, programming required only
> several dozens lines of code, board is already well tested and
> certified. If we use modern MCU, the board will be smaller, more
> powerful and consume less energy. But why waste time when we already
> have ready to use solution?

What does that have to do with microwaves or air conditioners? They *want* to save every penny in production because the development cost is puny in comparison. You have lost this argument. I'm not going to continue explaining the same facts to you over and over. Price matters in the largest quantity portion of the market. 32 bit ARMs just can't compete on price with the 8 bit MCUs. That is very clear and you are just back peddling. Give it up.

--

Rick C.

+--- Get 1,000 miles of free Supercharging
+--- Tesla referral code - https://ts.la/richard11209

On Saturday, December 11, 2021 at 8:18:37 PM UTC+3, gnuarm.del...@gmail.com wrote:
> On Saturday, December 11, 2021 at 10:06:56 AM UTC-5, Nickolay Kolchin wrote:
> > On Saturday, December 11, 2021 at 4:50:34 PM UTC+3, gnuarm.del...@gmail..com wrote:
> > > On Saturday, December 11, 2021 at 7:07:48 AM UTC-5, Nickolay Kolchin wrote:
> > > > On Saturday, December 11, 2021 at 12:26:28 PM UTC+3, gnuarm.del...@gmail.com wrote:
> > > > > On Friday, December 10, 2021 at 7:24:24 PM UTC-5, Nickolay Kolchin wrote:
> > > > > > And 4-bit MCU are blast from past. I can't even imagine situation when this
> > > > > > things may be used in new designs...
> > > > > Yes, that's true. You can't imagine. The reality is if you have a high volume application where every penny counts, you can develop and validate a design using an 8 bit MCU, give that design to an Asian manufacturer and they will supply you with 4 bit MCUs that will do the same job the same way at a lower price.
> > > > Your calculations make sense only for projects will many millions units shipment
> > > > expectation. And these are rare even on IOT market.
> > > Nonsense! Virtually every product sold at Walmart or any other retail establishment is sold in the millions. Looking around me I see what probably amounts to some dozen or two MCUs depending on how many MCUs are in my laptop. The window AC unit and remote almost certainly have 4 or 8 bit MCUs as well as the ceiling light fixture and it's remote. The dorm size refrigerator likely has a 4 or 8 bit MCU. My car remote most likely has a 4 or 8 bit MCU. My other car remote likely has a 4 or 8 bit MCU. I don't know what they put in laptops these days. PC keyboards used to have an 8 bit MCU. Now it's either that or integrated with some other chip. I have an LED measuring unit in my bag which might have a 32 bit MCU for the math.
> > >
> > > That's six to one for the 8 bitters. Heck, even if a product only sells a few hundred thousand, a dime difference in cost means a few tens of thousands of dollars. Yeah, no one with half a brain leaves that on the table..
> > >
> > > Besides, what you said was,
> > > > There are zero reasons to choose 8-bit MCU unless:
> > > >
> > > > - You already have a board that needs small customisation.
> > > > - You already have software for 8-bit
> > > > - You know nothing about Cortex and don't want to learn.
> > > I'm just refuting your statements. Cost is a valid and significant reason to choose an MCU other than a 32 bit ARM. If you check any source of market info you will find the volume of 8 bit MCU units shipped is as high as 32 bit units and continues to grow clearly indicating continued new design starts. The 32 bit unit sales by dollars is higher, but then we know the reason for that.
> > >
> > You don't understand how economics works at this scale.
> Wow! You just don't give up do you? You need to know when you are beaten.
> > 1. When you order 10M chips, you don't buy them on digikey. You make
> > direct contact with manufacturer. And price will be completely
> > different.
> Yeah, but you don't have that pricing and there is no reason to think a 32 bit ARM using a larger die will cost less at any quantity than an 8 bit MCU on a smaller die.
> > 2. You don't choose components using price as the only metric. If you
> > desire stable production in millions, you must also evaluate logistics
> > and manufacturer stability. And this may be more important than price.
> And none of this is the issue being discussed. I refer you to your statement quoted above...
>
> "There are zero reasons to choose 8-bit MCU unless:"...
> > 3. You should count programmers work. I.e. for well-known hardware with
> > large library backlog like STM32 -- you need 2 man. For limited
> > hardware which is unknown to developers, you may need bigger team or
> > more time for software development. This leads to budget increase in
> > several hundreds of thousands dollars.
> Wow! You are really reaching... The guy who showed me how important it was to save every penny was designing children's' toys, apparently a cutthroat business where the design review would argue over a single resistor as it means thousands of dollars in profit. The designer was an individual, so none of your "teams". He was also under very tight schedules as Santa waits for no toy.
> > You don't understand that 4/8-bits devices you see around, were
> > designed decades ago. They are still sold and produced, cause the
> > process is established and there is no need to fix "working thing".
> Sorry, that is pure BS. Every microwave oven doesn't use the same part with the same programming that was done "decades ago". That is literally your noise that you just made up!
> > For example, we reused old ATmega board for "land detector" on new
> > Helicopter. We have a lot of them in stock, programming required only
> > several dozens lines of code, board is already well tested and
> > certified. If we use modern MCU, the board will be smaller, more
> > powerful and consume less energy. But why waste time when we already
> > have ready to use solution?
> What does that have to do with microwaves or air conditioners? They *want* to save every penny in production because the development cost is puny in comparison. You have lost this argument. I'm not going to continue explaining the same facts to you over and over. Price matters in the largest quantity portion of the market. 32 bit ARMs just can't compete on price with the 8 bit MCUs. That is very clear and you are just back peddling. Give it up.
>

You talk about things you know nothing about. I bet you were never
involved in any serious hardware project.

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> I don't know why you say these LED drivers are MCUs. I am familiar
> with such devices and they are probably just three counters to count
> the duty cycle. The serial interface is very simple so a one shot
> (digital or analog) can discriminate one pulses from zero pulses.

There are two common versions, one of which ("Neopixel") has some
specific timing requirements, and a fancier one ("DotStar") with an SPI
interface, so it has separate clock and data lines and you can bit bang
it from MicroPython. I was referring to the SPI one. But both of them
are addressible, so some decoding is needed, etc. I remember reading
somewhere that the SPI one had an MCU, though presumably a very
rudimentary one. The other one may be simpler, I don't know.

I suppose even the SPI one could be done with a digital circuit simpler
than an MCU, so maybe they do it that way. But it would still take some
dozens of gates etc.

> "RGB" die isn't even one die. There are a total of four dice,

Ah ok, that makes sense.

On Saturday, December 11, 2021 at 10:59:34 AM UTC-7, Nickolay Kolchin wrote:
> On Saturday, December 11, 2021 at 8:18:37 PM UTC+3, gnuarm.del...@gmail.com wrote:
> > What does that have to do with microwaves or air conditioners?
> > They *want* to save every penny in production because the development cost is puny in comparison.
> > ...
> >
> You talk about things you know nothing about. I bet you were never
> involved in any serious hardware project.

My primary criteria for choosing which processor to use, in the unlikely case that
I were in management and got the choice, would be to maximize the fun aspect.
This is so I could have cool coworkers rather than corporate drone types.
The Taiwanese use a variant of the 6502 in their Furby toy. That would be fun to program!
For a microwave, the 65c02 would be an overkill though. :-(
A PIC12 would be more realistic --- still pretty fun --- somewhat of a boring project though
because all it does is turn the thing on and off for specified amounts of time.

I considered MFX assembly-language to be fun. :-)
My idea of fun doesn't necessarily correspond to most people's idea of fun.
The only addressing-mode supported was inherent --- none of the instructions had operands.
There was no way to change the control-flow except with the NXT instruction.
There was no instruction to do 16-bit integer addition --- this required a pretty complicated function.
This was a "serious hardware project" though --- it was used in laser-etching machines.
The days of being able to build your own processor that competes with mainstream processors
is past. :-( In 1994, the competition was using an MC68000 programmed in C, but the
MiniForth built on a Lattice isp1048 PLD and an 8032 was higher performing and less expensive.
Nowadays pretty much everybody uses the ARM Cortex for motion-control, programmed in C.
Somebody like Nickolay Kolchin would get hired for that --- I would not --- my experience is too
esoteric and obsolete, plus Tom Hart refuses to admit that I wrote MFX anyway.

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> On first reading, I thought about the iAPX432

Yeah, the number 432 reminded me of that as well, but I meant three
GA144's. Everyone knows that Forth development is so efficient that
selling only 3 chips was enough to fund GA engineering through several
new features ;-).

> I dimly remember this being discussed here, with the b16-small costing
> ~300 LUTs and the b16-dsp costing ~600 LUTs

Oh that is cool. The FPGA that I mentioned was described here:

https://www.renesas.com/us/en/about/press-room/renesas-enters-fpga-market-first-ultra-low-power-low-cost-family-addressing-low-density-high-volume

50 cents for a part with 1000 LUTs. But, it doesn't say anything about
block ram, so no idea if it is really usable for a b16-small, at least
with a nontrivial amount of program code. Its stacks as designed also
live in block ram, but maybe LUTs could be used for them instead, as a
LUT is basically a 16 bit RAM.

> (concerning the b16 name: Bernd Paysan... in a later presentation...
> renamed the b16-dsp into b16-dsp, and the b16-small into b16).

Oh I must not have seen the later one. The dsp name is interesting
since iirc the first design didn't support multiplication, which on an
fpga with dsp blocks is "free", so maybe there was a later redesign.

The b16-small was imho a little bit TOO small, and could have used
another 1 or 2 stack levels to make programming a little easier.

On Saturday, December 11, 2021 at 12:59:34 PM UTC-5, Nickolay Kolchin wrote:
> On Saturday, December 11, 2021 at 8:18:37 PM UTC+3, gnuarm.del...@gmail.com wrote:
> > On Saturday, December 11, 2021 at 10:06:56 AM UTC-5, Nickolay Kolchin wrote:
> > > On Saturday, December 11, 2021 at 4:50:34 PM UTC+3, gnuarm.del...@gmail.com wrote:
> > > > On Saturday, December 11, 2021 at 7:07:48 AM UTC-5, Nickolay Kolchin wrote:
> > > > > On Saturday, December 11, 2021 at 12:26:28 PM UTC+3, gnuarm.del....@gmail.com wrote:
> > > > > > On Friday, December 10, 2021 at 7:24:24 PM UTC-5, Nickolay Kolchin wrote:
> > > > > > > And 4-bit MCU are blast from past. I can't even imagine situation when this
> > > > > > > things may be used in new designs...
> > > > > > Yes, that's true. You can't imagine. The reality is if you have a high volume application where every penny counts, you can develop and validate a design using an 8 bit MCU, give that design to an Asian manufacturer and they will supply you with 4 bit MCUs that will do the same job the same way at a lower price.
> > > > > Your calculations make sense only for projects will many millions units shipment
> > > > > expectation. And these are rare even on IOT market.
> > > > Nonsense! Virtually every product sold at Walmart or any other retail establishment is sold in the millions. Looking around me I see what probably amounts to some dozen or two MCUs depending on how many MCUs are in my laptop. The window AC unit and remote almost certainly have 4 or 8 bit MCUs as well as the ceiling light fixture and it's remote. The dorm size refrigerator likely has a 4 or 8 bit MCU. My car remote most likely has a 4 or 8 bit MCU. My other car remote likely has a 4 or 8 bit MCU. I don't know what they put in laptops these days. PC keyboards used to have an 8 bit MCU. Now it's either that or integrated with some other chip. I have an LED measuring unit in my bag which might have a 32 bit MCU for the math.
> > > >
> > > > That's six to one for the 8 bitters. Heck, even if a product only sells a few hundred thousand, a dime difference in cost means a few tens of thousands of dollars. Yeah, no one with half a brain leaves that on the table.
> > > >
> > > > Besides, what you said was,
> > > > > There are zero reasons to choose 8-bit MCU unless:
> > > > >
> > > > > - You already have a board that needs small customisation.
> > > > > - You already have software for 8-bit
> > > > > - You know nothing about Cortex and don't want to learn.
> > > > I'm just refuting your statements. Cost is a valid and significant reason to choose an MCU other than a 32 bit ARM. If you check any source of market info you will find the volume of 8 bit MCU units shipped is as high as 32 bit units and continues to grow clearly indicating continued new design starts. The 32 bit unit sales by dollars is higher, but then we know the reason for that.
> > > >
> > > You don't understand how economics works at this scale.
> > Wow! You just don't give up do you? You need to know when you are beaten.
> > > 1. When you order 10M chips, you don't buy them on digikey. You make
> > > direct contact with manufacturer. And price will be completely
> > > different.
> > Yeah, but you don't have that pricing and there is no reason to think a 32 bit ARM using a larger die will cost less at any quantity than an 8 bit MCU on a smaller die.
> > > 2. You don't choose components using price as the only metric. If you
> > > desire stable production in millions, you must also evaluate logistics
> > > and manufacturer stability. And this may be more important than price..
> > And none of this is the issue being discussed. I refer you to your statement quoted above...
> >
> > "There are zero reasons to choose 8-bit MCU unless:"...
> > > 3. You should count programmers work. I.e. for well-known hardware with
> > > large library backlog like STM32 -- you need 2 man. For limited
> > > hardware which is unknown to developers, you may need bigger team or
> > > more time for software development. This leads to budget increase in
> > > several hundreds of thousands dollars.
> > Wow! You are really reaching... The guy who showed me how important it was to save every penny was designing children's' toys, apparently a cutthroat business where the design review would argue over a single resistor as it means thousands of dollars in profit. The designer was an individual, so none of your "teams". He was also under very tight schedules as Santa waits for no toy.
> > > You don't understand that 4/8-bits devices you see around, were
> > > designed decades ago. They are still sold and produced, cause the
> > > process is established and there is no need to fix "working thing".
> > Sorry, that is pure BS. Every microwave oven doesn't use the same part with the same programming that was done "decades ago". That is literally your noise that you just made up!
> > > For example, we reused old ATmega board for "land detector" on new
> > > Helicopter. We have a lot of them in stock, programming required only
> > > several dozens lines of code, board is already well tested and
> > > certified. If we use modern MCU, the board will be smaller, more
> > > powerful and consume less energy. But why waste time when we already
> > > have ready to use solution?
> > What does that have to do with microwaves or air conditioners? They *want* to save every penny in production because the development cost is puny in comparison. You have lost this argument. I'm not going to continue explaining the same facts to you over and over. Price matters in the largest quantity portion of the market. 32 bit ARMs just can't compete on price with the 8 bit MCUs. That is very clear and you are just back peddling. Give it up.
> >
> You talk about things you know nothing about. I bet you were never
> involved in any serious hardware project.

Ok, so you've given up trying to defend your position and are attacking ad hominem. So clearly you *have* thrown in the towel.

--

Rick C.

+--+ Get 1,000 miles of free Supercharging
+--+ Tesla referral code - https://ts.la/richard11209

On Saturday, December 11, 2021 at 3:39:13 PM UTC-5, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
> > I don't know why you say these LED drivers are MCUs. I am familiar
> > with such devices and they are probably just three counters to count
> > the duty cycle. The serial interface is very simple so a one shot
> > (digital or analog) can discriminate one pulses from zero pulses.
> There are two common versions, one of which ("Neopixel") has some
> specific timing requirements, and a fancier one ("DotStar") with an SPI
> interface, so it has separate clock and data lines and you can bit bang
> it from MicroPython. I was referring to the SPI one. But both of them
> are addressible, so some decoding is needed, etc. I remember reading
> somewhere that the SPI one had an MCU, though presumably a very
> rudimentary one. The other one may be simpler, I don't know.
>
> I suppose even the SPI one could be done with a digital circuit simpler
> than an MCU, so maybe they do it that way. But it would still take some
> dozens of gates etc.
> > "RGB" die isn't even one die. There are a total of four dice,
> Ah ok, that makes sense.

Both SPI and the custom interface are incredibly simple. SPI is a shift register with clock, data and strobe inputs. I don't know exactly how it operates in this case because they use very long strings of these things and SPI normally shifts data to ALL the devices in the link before latching the data with the strobe. Each device uses 24 bits of data so that's a lot of data on a long string.

The custom interface sends data and clock together on one wire with PWM. The first 24 bits are accepted by the first device. Then it passes on any remaining bits with reclocking to avoid PWM distortion through the daisy chain. The second device accepts the next 24 bits and so on; simple, reliable..

None of this requires anywhere near the amount of logic an MCU requires, 48 bits of register, a bit of logic and an internal RC timer... oh, almost forgot the 24 bits of counter... still, just a few hundred transistors max. But who knows, maybe they can build a very, very simple CPU in a few hundred transistors. This would not take much of a CPU.

--

Rick C.

+-+- Get 1,000 miles of free Supercharging
+-+- Tesla referral code - https://ts.la/richard11209

On Saturday, December 11, 2021 at 3:51:59 PM UTC-5, Hugh Aguilar wrote:
> On Saturday, December 11, 2021 at 10:59:34 AM UTC-7, Nickolay Kolchin wrote:
> > On Saturday, December 11, 2021 at 8:18:37 PM UTC+3, gnuarm.del...@gmail..com wrote:
> > > What does that have to do with microwaves or air conditioners?
> > > They *want* to save every penny in production because the development cost is puny in comparison.
> > > ...
> > >
> > You talk about things you know nothing about. I bet you were never
> > involved in any serious hardware project.
> My primary criteria for choosing which processor to use, in the unlikely case that
> I were in management and got the choice, would be to maximize the fun aspect.
> This is so I could have cool coworkers rather than corporate drone types.
> The Taiwanese use a variant of the 6502 in their Furby toy. That would be fun to program!
> For a microwave, the 65c02 would be an overkill though. :-(
> A PIC12 would be more realistic --- still pretty fun --- somewhat of a boring project though
> because all it does is turn the thing on and off for specified amounts of time.

As a drone you probably would have to implement the UI you are given, but if you are the boss and get to choose that could be interesting. I see no small number of borked UIs on microwaves. One I used today has a +30 second function built into the start button. But if you reach it just after the timer counts to zero it does nothing. That function could have been put in another button as they often do on these units so that it would start up immediately and my popcorn would finish popping with minimal interruption.

> I considered MFX assembly-language to be fun. :-)
> My idea of fun doesn't necessarily correspond to most people's idea of fun.
> The only addressing-mode supported was inherent --- none of the instructions had operands.
> There was no way to change the control-flow except with the NXT instruction.
> There was no instruction to do 16-bit integer addition --- this required a pretty complicated function.
> This was a "serious hardware project" though --- it was used in laser-etching machines.
> The days of being able to build your own processor that competes with mainstream processors
> is past. :-( In 1994, the competition was using an MC68000 programmed in C, but the
> MiniForth built on a Lattice isp1048 PLD and an 8032 was higher performing and less expensive.
> Nowadays pretty much everybody uses the ARM Cortex for motion-control, programmed in C.
> Somebody like Nickolay Kolchin would get hired for that --- I would not --- my experience is too
> esoteric and obsolete, plus Tom Hart refuses to admit that I wrote MFX anyway.

You say it doesn't have "16-bit integer addition", so what does it have? How is addition done?

--

Rick C.

+-++ Get 1,000 miles of free Supercharging
+-++ Tesla referral code - https://ts.la/richard11209

Nickolay Kolchin <nbkolchin@gmail.com> writes:
> Never heard about Padauk before. I was tricked by Digikey pricing on
> 8-MCUs.

These articles are pretty good:

https://cpldcpu.wordpress.com/2019/08/12/the-terrible-3-cent-mcu/

https://jaycarlson.net/2019/09/06/whats-up-with-these-3-cent-microcontrollers/

>> As for the ATTiny, I've heard it described as a fairly nice
>> multi-function analog chip with a marginally useful digital cpu
> Sounds doubtful. Can you share some links on subject?

This page has nice descriptions of the current ATTiny stuff, though
not the above formulation:

https://github.com/SpenceKonde/megaTinyCore

A gadget I'm messing with uses the ATTiny1616 and I find it nice to
program. You just apt-get install avr-gcc and a few other things and
get a dev environment that is fairly normal for C programming. Maybe
someday I'll put a Forth on it.

It's a sub-$1 part with many nice features including a low powered sleep
mode with programmable pullups on the gpio's. The gadget uses that
feature to keep an LED lit at low power while the cpu is sleeping. The
ADC is also apparently quite a lot better than the one in the RP2040.
The one in ST parts may be better though.

The 1616 is available in a 20 pin, 3mm*3mm VQFN package. That is
important for this application. I don't know of any comparable ARM part
available in such a small package that is not WLCSP, which is far harder
to work with. I'd be interested if you know of something.

On 10/12/2021 19:43, Paul Rubin wrote:
> Rick C <gnuarm.deletethisbit@gmail.com> writes:
>> the GA144 ... It's an embedded computer, an MCU which has a very
>> different application space. Unfortunately, the GA144 has no
>> identified application space, so it has no market and no sales to
>> speak of. I bought three of them. Does that count?
>
> If you bought 3 chips that's 432 processors, so it's a start ;-).
>
> More srsly an MCU with ~128 bytes of ram (like the midrange ATTinys) is
> perfectly useful and respectable. I've been programming those things a
> little bit recently. But, they usually have 4K or more of program store
> on the MCU. Having to use the GA144 ram as program memory (sharing it
> with application data), or being limited to the 64 words (= 144 bytes)
> of mask rom at each node, is horribly constricting, as the code on the
> GA site shows. They had to do crazy things to make even simple programs
> fit.
>
> It also didn't help that the Polyforth VM that they include in the rom
> on 3 the of the GA144 nodes is completely undocumented. They were very
> eager for someone to target a C compiler to the GA144, so I remember
> looking at the code for that VM but finding it more confusing than I was
> willing to deal with.
>
> They said something at one point about a later chip possibly having
> flash memory for programs, which would help a lot. Flash apparently
> needs a different fab process. A block of ram would be just as good
> though. Was there ever even a proposed application that would use most
> or all of the 144 nodes? The GA144's predecessor (the SeaFORTH) had 40
> nodes, and I think there may have been one with 28 nodes, maybe earlier.
> So if they replaced half the GA144's nodes with ram, they might have
> been better off.
>
> I had one idea for a GA144 application that couldn't easily be done in a
> conventional MCU because it needed very low latency i/o (a few ns from
> input to output), but I decided after a while that it would be easier to
> do that with a small FPGA.
>
> Wayne Morellini is right that we don't have ironclad mathematical proof
> that GA isn't getting billion-dollar deals from hush-hush customers and
> keeping quiet about them. But, in the real world, such deals would
> result in financial expansion of the company, that would be visible as
> new hiring, new products, carefully worded announcements, GA staff
> driving Ferraris around, etc. So there is decent practical inference
> that such deals aren't happening.
>
> I do keep wondering how many LUT4 it would take to implement an F18-like
> processor (e.g. b16-small) in an FPGA. There is supposedly a 50 cent
> FPGA now with 1000 LUT (no idea of block ram). If a reasonably fast
> stack processor can fit in < 500 of that, leaving the user 500 for other
> purposes, that seems like a useful alternative to the RISC-V that
> everyone wants to use now. It apparently takes 1000 LUT to make even a
> very slow RISC-V.
>
Hi Paul,

> It also didn't help that the Polyforth VM that they include in the rom
> on 3 the of the GA144 nodes is completely undocumented.

Maybe you missed this :
http://www.greenarraychips.com/home/documents/greg/DB005-120825-PF-REF.pdf

I bought one of the GA development boards for around $500, and ran
polyForth on it, so I can confirm that this is possible.

polyForth ran surprisingly fast considering how little current it was
using, and the impedence mis-match between the 18 bit GA144 and the 16
bit polyForth VM.

For me, this is pure experimental science and does not need to make
money, although it would be nice if it did ;-)

Times change, and the emphasis these days seems to be the IoT, where low
power and small code size are becoming important again.

The GA144 shows one way to design hardware and software to meet these
kinds of constraints, so it may yet find a market...

Cheers,
Howerd