On 1/27/2020 5:53 PM, Don Y wrote:
> With "few" intensity levels desired, I plan to drive LED
> with a crude PWM signal directly from an IRQ (i.e., push
> bits out a hardware port at each IRQ).

...

> What problems might I encounter with this approach?  (I'm
> mainly worrying about visual artifacts)

This turned out better than I'd expected!  I prototyped a 240 channel device
(hacked a previous FPGA design so I didn't have to BUILD anything in order to
capture 'scope traces) Latency and overruns are non-problems -- immeasurable!
(I added an "overrun flag" to the design to detect if an ISR failed to finish
updating ALL of the outputs before the *next* ISR came along)

But, that's largely because my foreground is slicker than snot!  The ISR could
easily be replaced by a DMA but that would be a foolish waste of resources (and
an unnecessary constraint on future CPU implementations).  As it stands, all I
need is a parallel interface and some number of discrete, consecutive addresses
to be updated by the ISR -- so, I can quickly port the hardware to a variety of
different CPUs.  No PWM controllers, I2C interfaces, programmed hardware, etc.

[In the short term, I'll port the code to an ISA PC running a bloated FOSS OS
and see if that slows things down enough to be a problem!  I'm also going to
hack together a sloppy PIO PATA (slow!) interface to compete with this ISR to
see what sort of problems a deliberately sloppy synthetic ISR manifests.]

Jitter and skew are also nonexistent due to the double-buffered design.  Often
the easiest solutions are the best!  :>

Next, layout a preproduction board and increase the drive to ~500mA per
channel.  (And, contemplate a 5A/channel implementation as the approach seems
applicable to a variety of different I/Os that I'd not previously considered!)

Sadly, the guy at the local university who was going to do the testing of the
visual aspects of this approach has backed out of that commitment -- the
University is largely shutdown due to COVID19.  But, he's offered his "test
plan" for me to use along with some specialized equipment to visually capture
artifacts.

Attached, an excerpt from an announcement email to those of my colleagues who
are presently using my codebase...

========================================================================

The BD documents cover the full API; this just gives a quick overview.
Remember, this is the equivalent of a "hardware interface"; you'll
want to build an abstraction layer atop it.  E.g., use symbolics
for different cycle patterns:  OFF/DIM/BRIGHT, COOL/WARM/HOT/SCORCHING,
STOPPED/SLOW/FAST, etc.  I'll send along the handler for the indicator
array I designed, as an example, under separate cover.

----8<----8<----

[Error handling elided -- you already know the potential issues!]

# instantiate a copy of the PWM controller on the targeted node
factory := MyContext=>resolve("ORB Factory")
pwmA := factory=>instantiate("PWM Controller", nodeA)

# drop the Handle to effectively create an invariant
factory = nil

# N.B. the PWM controller determines number of signals supported by the
# "local" hardware -- along with their "I/O" addresses -- and configures
# its local ISR to service them.  This frees the client from having to know
# what a particular Node's hardware can do.

# *** THE ISR MUST BE HOSTED ON THE SAME NODE AS THE PWM CONTROLLER!! ***
# It's not practical to make real-time guarantees across processor nodes
# for such closely-coupled activities.  Of course, layers *atop* that can
# be hosted anywhere a Handle is available!

# No need to bind the Handle for the PWM instance to a Name as you're
# the only one referencing it.  And, holding onto the Handle is just as
# easy as retrieving that Handle from a Context!  Additionally, holding
# the Handle ensures you will be notified of pertinent events "as they
# happen" (e.g., if the object dies or faults)

# configure the PWM for the desired number of intervals-per-PWM-cycle
# as well as their relative weights and the overall cycle frequency
rate := 100.0
intervals := 13 :: 5 :: 2 :: 2 :: 2 :: 1
pwmA=>configure(rate, intervals)   # forces all outputs off; stops PWM
pwmA=>start()

# if you never export the pwmA Handle, then guaranteed exclusive use!
# otherwise, you'll need locks or rely on first-come, first served.
# Individual methods are atomic but method sequences make no guarantees!
# As usual, no *policy* decisions imposed by the implementation.

# As you'll undoubtedly interface to this through an upper-layer handler,
# the locks at this level can be hidden.  But, sharing Handles to *that*
# handler would likewise require coordination, of some sort.

# The service is connection based so different clients could, potentially,
# compete to specify different configurations and drive states.  You decide
# how that should be handled in your respective applications -- you could
# create specific capabilities for each output to allow independant control
# of their desired states while the controller does the actual updates,
# /en masse/

...

# check how many discrete outputs are being controlled by this instance
signals := pwmA=>drives()

# set all outputs to 20% duty cycle
for (output := 0; output < signals; output++)
    pwmA=>duty(output, 20.0)

# make new settings available to the hardware (via its ISR)
# this allows multiple outputs to be altered while ensuring
# the "update" appears in synchrony.
# As a result, if you want to expose changes to individual
# outputs, you must publish() after each change!
pwmA=>publish()

...

duty := pwmA=>ratio(0)         # s.b. 20.0 (or, as close as hardware can get!)

pwmA=>set(0, "  ## #")
duty = pwmA=>ratio(0)          # s.b. 20.0

pwmA=>set(0, " X    ")
duty = pwmA=>ratio(0)          # s.b. 20.0

pwmA=>set(0, "  a bc")
duty = pwmA=>ratio(0)          # s.b. 20.0

wave := pwmA=>intervals(0)     # s.b. "  a bc"

# Note that none of these duty cycle changes have been publish()ed!

# I'm not fond of the whitespace use; open to suggestions!!  Would be
# nice if compiler could verify proper data type ("width") but it's
# size is constrained by the hardware, not the API.  No practical
# limit on intervals-per-cycle so bit-arrays aren't a good fit!

...

if (pwmA=>opens())
     fault("load(s) dropped!")
     do_something()

if (pwmA=>overrun())
     fault("service failure!")

...

# In the event of overrun, one might reconfigure the service to support
# greater latency.  I've not been able to trip this error, yet, in practice,
# even at "rate"s of 1KHz (i.e., intervals as small as 40us, for this config)!
# But, an application with a "sloppier" foreground might have problems.
# Note that there is no guarantee that the shortest interval will be the
# most likely to be overrun, in any particular application!

# Think of this in a manner similar to a UART overrun or any other comm
# channel overrun.  You may NOT be able to recover the lost data so your
# remedies are limited!  OTOH, you LIKELY don't want to just ignore the
# problem as it may be chronic -- a design flaw or some other system aspect

rate := 90.0
intervals := 2 :: 2 :: 2 :: 2 :: 2 :: 2 :: 2 :: 2 :: 2 :: 2 :: 2 :: 2 :: 1
pwmA=>configure(rate, intervals)   # forces all outputs off; stops PWM
pwmA=>acknowledge()                # clear signaled overrun
pwmA=>start()

# N.B. this configuration increases the static load on the node as the
# total number of IRQs per second (unit time) is now 1170.  That was just
# 600 in the previous configuration.  The amount of work ("cost") per IRQ
# is constant -- the number of "outputs" transferred to the hardware in each
# IRQ -- so this represents a doubling of that cost, despite increasing the
# shortest interval by ~10%.  (see the BD documents for specific examples
# and analysis regarding the advantages of this configuration)

pwmA=>duty(0, 20.0)
duty = pwmA=>ratio(0)            # s.b. 20.0
wave = pwmA=>intervals(0, '#')   # s.b. "##          #" (or similar)

# N.B. server can build waveform from any appropriate combination of intervals!
# So, if you have a preference, use the set() method instead of duty()!

# I'm also unhappy with that variadic implementation; s.b. one way or another?
# But, without inventing a new data type, I think this is as good as it gets.

On Friday, January 31, 2020 at 4:59:42 AM UTC-5, David Brown wrote:
> On 31/01/2020 02:21, Rick C wrote:
> > On Thursday, January 30, 2020 at 7:18:01 PM UTC-5, David Brown
> > wrote:
> >> 
> >> You are suggesting that no one used a microcontroller simply to
> >> save wiring?  They would, for example, put a microcontroller in a
> >> car door if they needed it to control an electric window or door
> >> lock motor, but not simply to reduce the number of wires?  I find
> >> that hard to believe. Obviously there are costs involved in having
> >> the more distributed system - you have more devices to program
> >> (both in terms of software development, and in extra steps during
> >> production), fault-finding is likely to be harder, and you might
> >> have more wiring (communications bus, low voltage, low current
> >> supply, and perhaps high power supply to power lights or
> >> actuators).  But equally obviously you save on cables, you save on
> >> cabling, you save on cable ducts and paths.
> >> 
> >> I can believe that Tesla, with cars with a great many sensors
> >> scattered around, see more benefits in this than some other
> >> manufacturers might.
> >> 
> >> But I can't believe other manufacturers didn't think about it, and
> >> I can't believe their choices as to when to use separate wires and
> >> when to use distributed nodes would be made other than primarily by
> >> economics (perhaps considering the development costs, risks of
> >> software bugs causing recalls, service costs, etc., as well as
> >> simple manufacturing costs).
> >> 
> >> Whether the patent is "valid" or not will depend on legalities and
> >> who is willing to pay their lawyers the most money, as much as
> >> whether it technically fulfils the requirements.  Patents are
> >> supposed to cover ideas that are realisable, useful, and
> >> non-obvious to experts in the field.  This one definitely fails on
> >> that last point.  (Unless there is significantly more to the patent
> >> than your brief description here.)
> > 
> > Believe what you want.  Obviously no one has done this because auto
> > makers are not patent adverse.  They may or may not have thought
> > about it.
> 
> That does not follow.  Maybe you are right that no automotive
> manufacturers have done this before - but it is also possible that they
> did not think that every single obvious little design decision needs a
> patent.  I know auto manufacturers are enthusiastic about filing for
> patents on trivial things, but surely even they have limits.

Your terminology is biased and pointless, e.g. "every single obvious little design decision".  Clearly there is a significant advantage to using this method.  There are also costs since everything is a trade off.  Tesla was the first company to see the value in this idea as cars become ever more complex and the effort required to use microelectronics in cars ever diminishes.  End of discussion.  Tesla 1, entrenched automotive industry 0. 


> I have no special insight into the workings of automotive companies here
> - and there are many of them, perhaps with different attitudes.  It
> /could/ be that the the engineers have grumbled for decades about all
> the wires without anyone ever thinking of decentralisation.  It /could/
> be that they wanted to decentralise with extra microcontrollers to save
> wiring, but management or legal said no, for no good technical or
> economic reason.  (More likely, I think, is that the cost calculations
> are more complex than they might first appear, and that the reduction in
> wires isn't actually a benefit in many situations.  The other
> possibility is for legal departments to fear lawsuits if someone claims
> the extra microcontrollers made the car unsafe.)

Yes, there are always trade offs, both in implementation and in the effort to change a process.  Bottom line is Tesla sees the one true path in this matter, others didn't... until now. 


> > I'm tired of arguing of the point.  
> 
> Sorry, I thought this was a discussion - not an argument.

At one point it was, less so now that much of the language has become focused on demeaning the idea behind the patent.  Many solutions are obvious if you think about it.  That is not the nature of "obvious" in the patent requirements.  Using a screwdriver to turn a left handed screw is obvious.  Using it to pry open a pain can is obvious.  Grinding the tip into a dual pronged shape to use it on Pig Nose fasteners may seem obvious, but that would constitute an invention under patent law if no one else was using it in a visible manner. 


> > Of course there's ways to argue
> > the claim.  But with the big companies no one does that between each
> > other because it's a battle no one wins but the lawyers.
> > 
> 
> Indeed.  That is what makes the whole patent system an expensive joke
> and a hinder to progress.

Companies respecting each other's patents don't make anything expensive.  They usually trade patent rights costing each other nothing, allowing the world to see the contents of the patents which is what patents are all about. 


> > Every car maker in existence has the same wiring problem as Tesla.
> > I've heard many times how onerous the amount of wiring is.  That's
> > the big reason why they use a bus for talking to the various
> > processors under the hood and dash.  And yet there is no known
> > example in public exposure of adding an MCU to act simply as a wiring
> > reduction feature.  So it clearly meets the criteria you point out.
> > 
> 
> /I/ have added microcontrollers to designs purely to simplify wiring.
> I've done it for decades.  I'm sure most people in this group can say
> the same.  I haven't done it in a car, because I haven't designed
> electronics for a car - but I'd do it there if I were designing car
> electronics.  Do you mean to say Tesla has got a patent on doing this
> specifically in cars, even though others have done it in all sorts of
> other systems without patents?

That is very common under patent law.  Many design features used in minicomputers were patented a second time when used for the first time in single chip microcomputers.  That's a "novel application". 

If you don't like patent law, take that up with someone else.  That's a different discussion. 


> > So believe what you want, Tesla has the patent and others don't.
> > 
> 
> As you say, auto manufacturers are not shy about patents - and they
> don't fight about them.  If another manufacturer wanted to use this same
> technique and Tesla had it covered by a patent, they would license the
> patent from Tesla.  They would reach an agreement on royalties - they
> always do, because fighting it in court costs too much for both parties.

Musk has said there would be no royalty on any of their patents.  Not sure how to interpret that.  He many mean they would cross license something else.  He has said their motor and battery patents would be open to anyone who wishes to uses them, but he didn't say they were "open" implying there would need to be a license negotiation... just not for cash.  Hart to tell what he meant. 


> > BTW, you really should try trimming a post once in a while.  It's
> > very liberating.
> > 
> 
> Yes, which is why I /do/ trim posts.  But like most Usenet users, I
> could always be better at it.
> 
> On a similar point, you could try following Usenet standards for line
> breaks.  You don't usually post formatted text (like code snippets), so
> reflowing your posts is merely a minor inconvenience.  But it does not
> harm to follow the standards.

I have no control over line breaks.  Sorry, I gave up mucking with unreliable posting software and use Google Groups now.  Anyone who doesn't like how Google handles the line breaks needs to take it up with them, not me.  

-- 

  Rick C.

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

On 31/01/2020 02:21, Rick C wrote:
> On Thursday, January 30, 2020 at 7:18:01 PM UTC-5, David Brown
> wrote:
>> 
>> You are suggesting that no one used a microcontroller simply to
>> save wiring?  They would, for example, put a microcontroller in a
>> car door if they needed it to control an electric window or door
>> lock motor, but not simply to reduce the number of wires?  I find
>> that hard to believe. Obviously there are costs involved in having
>> the more distributed system - you have more devices to program
>> (both in terms of software development, and in extra steps during
>> production), fault-finding is likely to be harder, and you might
>> have more wiring (communications bus, low voltage, low current
>> supply, and perhaps high power supply to power lights or
>> actuators).  But equally obviously you save on cables, you save on
>> cabling, you save on cable ducts and paths.
>> 
>> I can believe that Tesla, with cars with a great many sensors
>> scattered around, see more benefits in this than some other
>> manufacturers might.
>> 
>> But I can't believe other manufacturers didn't think about it, and
>> I can't believe their choices as to when to use separate wires and
>> when to use distributed nodes would be made other than primarily by
>> economics (perhaps considering the development costs, risks of
>> software bugs causing recalls, service costs, etc., as well as
>> simple manufacturing costs).
>> 
>> Whether the patent is "valid" or not will depend on legalities and
>> who is willing to pay their lawyers the most money, as much as
>> whether it technically fulfils the requirements.  Patents are
>> supposed to cover ideas that are realisable, useful, and
>> non-obvious to experts in the field.  This one definitely fails on
>> that last point.  (Unless there is significantly more to the patent
>> than your brief description here.)
> 
> Believe what you want.  Obviously no one has done this because auto
> makers are not patent adverse.  They may or may not have thought
> about it.

That does not follow.  Maybe you are right that no automotive
manufacturers have done this before - but it is also possible that they
did not think that every single obvious little design decision needs a
patent.  I know auto manufacturers are enthusiastic about filing for
patents on trivial things, but surely even they have limits.

I have no special insight into the workings of automotive companies here
- and there are many of them, perhaps with different attitudes.  It
/could/ be that the the engineers have grumbled for decades about all
the wires without anyone ever thinking of decentralisation.  It /could/
be that they wanted to decentralise with extra microcontrollers to save
wiring, but management or legal said no, for no good technical or
economic reason.  (More likely, I think, is that the cost calculations
are more complex than they might first appear, and that the reduction in
wires isn't actually a benefit in many situations.  The other
possibility is for legal departments to fear lawsuits if someone claims
the extra microcontrollers made the car unsafe.)

> 
> I'm tired of arguing of the point.  

Sorry, I thought this was a discussion - not an argument.

> Of course there's ways to argue
> the claim.  But with the big companies no one does that between each
> other because it's a battle no one wins but the lawyers.
> 

Indeed.  That is what makes the whole patent system an expensive joke
and a hinder to progress.

> Every car maker in existence has the same wiring problem as Tesla.
> I've heard many times how onerous the amount of wiring is.  That's
> the big reason why they use a bus for talking to the various
> processors under the hood and dash.  And yet there is no known
> example in public exposure of adding an MCU to act simply as a wiring
> reduction feature.  So it clearly meets the criteria you point out.
> 

/I/ have added microcontrollers to designs purely to simplify wiring.
I've done it for decades.  I'm sure most people in this group can say
the same.  I haven't done it in a car, because I haven't designed
electronics for a car - but I'd do it there if I were designing car
electronics.  Do you mean to say Tesla has got a patent on doing this
specifically in cars, even though others have done it in all sorts of
other systems without patents?

> 
> So believe what you want, Tesla has the patent and others don't.
> 

As you say, auto manufacturers are not shy about patents - and they
don't fight about them.  If another manufacturer wanted to use this same
technique and Tesla had it covered by a patent, they would license the
patent from Tesla.  They would reach an agreement on royalties - they
always do, because fighting it in court costs too much for both parties.

> BTW, you really should try trimming a post once in a while.  It's
> very liberating.
> 

Yes, which is why I /do/ trim posts.  But like most Usenet users, I
could always be better at it.

On a similar point, you could try following Usenet standards for line
breaks.  You don't usually post formatted text (like code snippets), so
reflowing your posts is merely a minor inconvenience.  But it does not
harm to follow the standards.

On Thursday, January 30, 2020 at 7:18:01 PM UTC-5, David Brown wrote:
> 
> You are suggesting that no one used a microcontroller simply to save 
> wiring?  They would, for example, put a microcontroller in a car door if 
> they needed it to control an electric window or door lock motor, but not 
> simply to reduce the number of wires?  I find that hard to believe. 
> Obviously there are costs involved in having the more distributed system 
> - you have more devices to program (both in terms of software 
> development, and in extra steps during production), fault-finding is 
> likely to be harder, and you might have more wiring (communications bus, 
> low voltage, low current supply, and perhaps high power supply to power 
> lights or actuators).  But equally obviously you save on cables, you 
> save on cabling, you save on cable ducts and paths.
> 
> I can believe that Tesla, with cars with a great many sensors scattered 
> around, see more benefits in this than some other manufacturers might.
> 
> But I can't believe other manufacturers didn't think about it, and I 
> can't believe their choices as to when to use separate wires and when to 
> use distributed nodes would be made other than primarily by economics 
> (perhaps considering the development costs, risks of software bugs 
> causing recalls, service costs, etc., as well as simple manufacturing 
> costs).
> 
> Whether the patent is "valid" or not will depend on legalities and who 
> is willing to pay their lawyers the most money, as much as whether it 
> technically fulfils the requirements.  Patents are supposed to cover 
> ideas that are realisable, useful, and non-obvious to experts in the 
> field.  This one definitely fails on that last point.  (Unless there is 
> significantly more to the patent than your brief description here.)

Believe what you want.  Obviously no one has done this because auto makers are not patent adverse.  They may or may not have thought about it.  

I'm tired of arguing of the point.  Of course there's ways to argue the claim.  But with the big companies no one does that between each other because it's a battle no one wins but the lawyers.  

Every car maker in existence has the same wiring problem as Tesla.  I've heard many times how onerous the amount of wiring is.  That's the big reason why they use a bus for talking to the various processors under the hood and dash.  And yet there is no known example in public exposure of adding an MCU to act simply as a wiring reduction feature.  So it clearly meets the criteria you point out.  

So believe what you want, Tesla has the patent and others don't.  

BTW, you really should try trimming a post once in a while.  It's very liberating. 

-- 

  Rick C.

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

On 31/01/2020 00:08, Rick C wrote:
> On Thursday, January 30, 2020 at 3:22:04 PM UTC-5, David Brown
> wrote:
>> On 30/01/2020 17:06, Rick C wrote:
>>> On Thursday, January 30, 2020 at 4:25:55 AM UTC-5, David Brown 
>>> wrote:
>>>> On 29/01/2020 20:40, Rick C wrote:
>>>>> On Wednesday, January 29, 2020 at 1:28:44 PM UTC-5, Paul
>>>>> Rubin wrote:
>>>>>> Rick C <gnuarm.deletethisbit@gmail.com> writes:
>>>>>>> How would you be driving 1000s of LEDs from one chip?
>>>>>>> That seems like a disaster.
>>>>>> 
>>>>>> Right, so now the multiple chips have to communicate
>>>>>> somehow.
>>>>> 
>>>>> Yes, "somehow".  Perhaps we can use magic??!!!
>>>>> 
>>>>> 
>>>>>>> Yes, 1000s of LEDs is a rare application indeed.
>>>>>> 
>>>>>> It happens with large display signs, but indicators?  Most 
>>>>>> anyone would use LCD screens these days.  Didn't your car 
>>>>>> replace the whole dashboard with an LCD screen?
>>>>> 
>>>>> Not the whole dashboard, there are two displays in my car and
>>>>> a bunch of controls around the steering column.
>>>>> 
>>>>> But there are still many, many LEDs blinking, nodding and
>>>>> winking all around us every day even though most of them are
>>>>> at best ignored and at worst tolerated... very few ever
>>>>> looked at.
>>>>> 
>>>>> However, the multiplexing of controls and inputs is a very
>>>>> valid concept.  Speaking of my car, it has a central
>>>>> processor in the dash and many, many things are connected to
>>>>> it.  This creates a LOT of wiring.  Tesla has a patent on
>>>>> using a chip to multiplex controls over a bus (I can't
>>>>> believe no one is doing that), greatly reducing the wiring in
>>>>> a car.  It seems that while buses are very commonly used in
>>>>> cars, it didn't occur to anyone to put an MCU in each door,
>>>>> one or two in the back of the car, one in the steering
>>>>> column, etc., to allow a single four wire run to each of
>>>>> these devices to control all the indicators, actuators, 
>>>>> speakers, illuminators and sensors in each area.
>>>>> 
>>>>> It sure seems obvious to me.  I guess the auto industry
>>>>> really is a bit technology adverse.
>>>>> 
>>>> 
>>>> Not only is it obvious (who in this newsgroup hasn't been doing
>>>> it forever?), but it has been standard in the auto industry
>>>> for decades. The CAN bus is about 35 years old, and was
>>>> created /precisely/ for distributed processing of sensors,
>>>> indicators, actuators, etc., in cars. This was followed by the
>>>> LIN bus about 20 years ago, precisely to make it cheaper to
>>>> have even more small microcontrollers around the car.
>>>> 
>>>> I have no idea about Tesla's patent here, but your description 
>>>> makes it sound utterly trivial.  That is not unusual for
>>>> patents, of course.
>>> 
>>> Please reread my post and focus on what is being accomplished
>>> with the idea, not the fact that a bus is being used.  It's all
>>> there. You only need to read it without a preconceived idea of
>>> what I wrote.
>>> 
>> 
>> When the CAN bus started to become more popular, and in particular
>> when LIN was developed, it was so that you could have four wire
>> cables around the car with a microcontroller in each door, sensor,
>> light, or whatever. Modern cars can have hundreds of
>> microcontrollers.  The two things hang together as one idea.  This
>> is not a new - it was obvious to you, and obvious to everyone else,
>> and it has been obvious for decades.  (The balance of economics for
>> when you have a new node on the bus, and when you run multiple
>> wires from one node, has of course changed over time.)
> 
> You aren't grasping the idea at all.  Yes, car makers have been using
> the bus to tie together all the MCUs scattered around the car.  But
> the MCUs were only there if there was some need for an MCU that had
> nothing to do with wiring.  Look at the cables the go to car doors or
> the harnesses that run to the rear of the car.  They are a LOT more
> than four wires.
> 
> Then once again, re-read my original post about this.  You still
> aren't connecting the dots at all.  There's really nothing else I can
> do but repeat what I wrote before.  So either understand that post,
> or we should just give up on trying to convey this idea.
> 
> It's a valid patent and will save a lot of money for anyone who uses
> it.  That's why no one else ever used it before.  I know I've thought
> about it before.  I assumed car makers either had some reason why it
> wouldn't work for them.  Obviously Tesla feels it will work just fine
> and I agree.  Reducing the number of wires in a car solves a lot of
> problems and will save a lot of assembly work.
> 

You are suggesting that no one used a microcontroller simply to save 
wiring?  They would, for example, put a microcontroller in a car door if 
they needed it to control an electric window or door lock motor, but not 
simply to reduce the number of wires?  I find that hard to believe. 
Obviously there are costs involved in having the more distributed system 
- you have more devices to program (both in terms of software 
development, and in extra steps during production), fault-finding is 
likely to be harder, and you might have more wiring (communications bus, 
low voltage, low current supply, and perhaps high power supply to power 
lights or actuators).  But equally obviously you save on cables, you 
save on cabling, you save on cable ducts and paths.

I can believe that Tesla, with cars with a great many sensors scattered 
around, see more benefits in this than some other manufacturers might.

But I can't believe other manufacturers didn't think about it, and I 
can't believe their choices as to when to use separate wires and when to 
use distributed nodes would be made other than primarily by economics 
(perhaps considering the development costs, risks of software bugs 
causing recalls, service costs, etc., as well as simple manufacturing 
costs).

Whether the patent is "valid" or not will depend on legalities and who 
is willing to pay their lawyers the most money, as much as whether it 
technically fulfils the requirements.  Patents are supposed to cover 
ideas that are realisable, useful, and non-obvious to experts in the 
field.  This one definitely fails on that last point.  (Unless there is 
significantly more to the patent than your brief description here.)

On Thursday, January 30, 2020 at 3:22:04 PM UTC-5, David Brown wrote:
> On 30/01/2020 17:06, Rick C wrote:
> > On Thursday, January 30, 2020 at 4:25:55 AM UTC-5, David Brown
> > wrote:
> >> On 29/01/2020 20:40, Rick C wrote:
> >>> On Wednesday, January 29, 2020 at 1:28:44 PM UTC-5, Paul Rubin 
> >>> wrote:
> >>>> Rick C <gnuarm.deletethisbit@gmail.com> writes:
> >>>>> How would you be driving 1000s of LEDs from one chip?  That
> >>>>> seems like a disaster.
> >>>> 
> >>>> Right, so now the multiple chips have to communicate somehow.
> >>> 
> >>> Yes, "somehow".  Perhaps we can use magic??!!!
> >>> 
> >>> 
> >>>>> Yes, 1000s of LEDs is a rare application indeed.
> >>>> 
> >>>> It happens with large display signs, but indicators?  Most
> >>>> anyone would use LCD screens these days.  Didn't your car
> >>>> replace the whole dashboard with an LCD screen?
> >>> 
> >>> Not the whole dashboard, there are two displays in my car and a
> >>> bunch of controls around the steering column.
> >>> 
> >>> But there are still many, many LEDs blinking, nodding and winking
> >>> all around us every day even though most of them are at best
> >>> ignored and at worst tolerated... very few ever looked at.
> >>> 
> >>> However, the multiplexing of controls and inputs is a very valid 
> >>> concept.  Speaking of my car, it has a central processor in the
> >>> dash and many, many things are connected to it.  This creates a
> >>> LOT of wiring.  Tesla has a patent on using a chip to multiplex
> >>> controls over a bus (I can't believe no one is doing that),
> >>> greatly reducing the wiring in a car.  It seems that while buses
> >>> are very commonly used in cars, it didn't occur to anyone to put
> >>> an MCU in each door, one or two in the back of the car, one in
> >>> the steering column, etc., to allow a single four wire run to
> >>> each of these devices to control all the indicators, actuators,
> >>> speakers, illuminators and sensors in each area.
> >>> 
> >>> It sure seems obvious to me.  I guess the auto industry really is
> >>> a bit technology adverse.
> >>> 
> >> 
> >> Not only is it obvious (who in this newsgroup hasn't been doing it 
> >> forever?), but it has been standard in the auto industry for
> >> decades. The CAN bus is about 35 years old, and was created
> >> /precisely/ for distributed processing of sensors, indicators,
> >> actuators, etc., in cars. This was followed by the LIN bus about 20
> >> years ago, precisely to make it cheaper to have even more small
> >> microcontrollers around the car.
> >> 
> >> I have no idea about Tesla's patent here, but your description
> >> makes it sound utterly trivial.  That is not unusual for patents,
> >> of course.
> > 
> > Please reread my post and focus on what is being accomplished with
> > the idea, not the fact that a bus is being used.  It's all there.
> > You only need to read it without a preconceived idea of what I
> > wrote.
> > 
> 
> When the CAN bus started to become more popular, and in particular when 
> LIN was developed, it was so that you could have four wire cables around 
> the car with a microcontroller in each door, sensor, light, or whatever. 
>   Modern cars can have hundreds of microcontrollers.  The two things 
> hang together as one idea.  This is not a new - it was obvious to you, 
> and obvious to everyone else, and it has been obvious for decades.  (The 
> balance of economics for when you have a new node on the bus, and when 
> you run multiple wires from one node, has of course changed over time.)

You aren't grasping the idea at all.  Yes, car makers have been using the bus to tie together all the MCUs scattered around the car.  But the MCUs were only there if there was some need for an MCU that had nothing to do with wiring.  Look at the cables the go to car doors or the harnesses that run to the rear of the car.  They are a LOT more than four wires.  

Then once again, re-read my original post about this.  You still aren't connecting the dots at all.  There's really nothing else I can do but repeat what I wrote before.  So either understand that post, or we should just give up on trying to convey this idea. 

It's a valid patent and will save a lot of money for anyone who uses it.  That's why no one else ever used it before.  I know I've thought about it before.  I assumed car makers either had some reason why it wouldn't work for them.  Obviously Tesla feels it will work just fine and I agree.  Reducing the number of wires in a car solves a lot of problems and will save a lot of assembly work. 

-- 

  Rick C.

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

On 30/01/2020 17:06, Rick C wrote:
> On Thursday, January 30, 2020 at 4:25:55 AM UTC-5, David Brown
> wrote:
>> On 29/01/2020 20:40, Rick C wrote:
>>> On Wednesday, January 29, 2020 at 1:28:44 PM UTC-5, Paul Rubin 
>>> wrote:
>>>> Rick C <gnuarm.deletethisbit@gmail.com> writes:
>>>>> How would you be driving 1000s of LEDs from one chip?  That
>>>>> seems like a disaster.
>>>> 
>>>> Right, so now the multiple chips have to communicate somehow.
>>> 
>>> Yes, "somehow".  Perhaps we can use magic??!!!
>>> 
>>> 
>>>>> Yes, 1000s of LEDs is a rare application indeed.
>>>> 
>>>> It happens with large display signs, but indicators?  Most
>>>> anyone would use LCD screens these days.  Didn't your car
>>>> replace the whole dashboard with an LCD screen?
>>> 
>>> Not the whole dashboard, there are two displays in my car and a
>>> bunch of controls around the steering column.
>>> 
>>> But there are still many, many LEDs blinking, nodding and winking
>>> all around us every day even though most of them are at best
>>> ignored and at worst tolerated... very few ever looked at.
>>> 
>>> However, the multiplexing of controls and inputs is a very valid 
>>> concept.  Speaking of my car, it has a central processor in the
>>> dash and many, many things are connected to it.  This creates a
>>> LOT of wiring.  Tesla has a patent on using a chip to multiplex
>>> controls over a bus (I can't believe no one is doing that),
>>> greatly reducing the wiring in a car.  It seems that while buses
>>> are very commonly used in cars, it didn't occur to anyone to put
>>> an MCU in each door, one or two in the back of the car, one in
>>> the steering column, etc., to allow a single four wire run to
>>> each of these devices to control all the indicators, actuators,
>>> speakers, illuminators and sensors in each area.
>>> 
>>> It sure seems obvious to me.  I guess the auto industry really is
>>> a bit technology adverse.
>>> 
>> 
>> Not only is it obvious (who in this newsgroup hasn't been doing it 
>> forever?), but it has been standard in the auto industry for
>> decades. The CAN bus is about 35 years old, and was created
>> /precisely/ for distributed processing of sensors, indicators,
>> actuators, etc., in cars. This was followed by the LIN bus about 20
>> years ago, precisely to make it cheaper to have even more small
>> microcontrollers around the car.
>> 
>> I have no idea about Tesla's patent here, but your description
>> makes it sound utterly trivial.  That is not unusual for patents,
>> of course.
> 
> Please reread my post and focus on what is being accomplished with
> the idea, not the fact that a bus is being used.  It's all there.
> You only need to read it without a preconceived idea of what I
> wrote.
> 

When the CAN bus started to become more popular, and in particular when 
LIN was developed, it was so that you could have four wire cables around 
the car with a microcontroller in each door, sensor, light, or whatever. 
  Modern cars can have hundreds of microcontrollers.  The two things 
hang together as one idea.  This is not a new - it was obvious to you, 
and obvious to everyone else, and it has been obvious for decades.  (The 
balance of economics for when you have a new node on the bus, and when 
you run multiple wires from one node, has of course changed over time.)

On Thursday, January 30, 2020 at 4:25:55 AM UTC-5, David Brown wrote:
> On 29/01/2020 20:40, Rick C wrote:
> > On Wednesday, January 29, 2020 at 1:28:44 PM UTC-5, Paul Rubin
> > wrote:
> >> Rick C <gnuarm.deletethisbit@gmail.com> writes:
> >>> How would you be driving 1000s of LEDs from one chip?  That seems
> >>> like a disaster.
> >> 
> >> Right, so now the multiple chips have to communicate somehow.
> > 
> > Yes, "somehow".  Perhaps we can use magic??!!!
> > 
> > 
> >>> Yes, 1000s of LEDs is a rare application indeed.
> >> 
> >> It happens with large display signs, but indicators?  Most anyone
> >> would use LCD screens these days.  Didn't your car replace the
> >> whole dashboard with an LCD screen?
> > 
> > Not the whole dashboard, there are two displays in my car and a bunch
> > of controls around the steering column.
> > 
> > But there are still many, many LEDs blinking, nodding and winking all
> > around us every day even though most of them are at best ignored and
> > at worst tolerated... very few ever looked at.
> > 
> > However, the multiplexing of controls and inputs is a very valid
> > concept.  Speaking of my car, it has a central processor in the dash
> > and many, many things are connected to it.  This creates a LOT of
> > wiring.  Tesla has a patent on using a chip to multiplex controls
> > over a bus (I can't believe no one is doing that), greatly reducing
> > the wiring in a car.  It seems that while buses are very commonly
> > used in cars, it didn't occur to anyone to put an MCU in each door,
> > one or two in the back of the car, one in the steering column, etc.,
> > to allow a single four wire run to each of these devices to control
> > all the indicators, actuators, speakers, illuminators and sensors in
> > each area.
> > 
> > It sure seems obvious to me.  I guess the auto industry really is a
> > bit technology adverse.
> > 
> 
> Not only is it obvious (who in this newsgroup hasn't been doing it
> forever?), but it has been standard in the auto industry for decades.
> The CAN bus is about 35 years old, and was created /precisely/ for
> distributed processing of sensors, indicators, actuators, etc., in cars.
>  This was followed by the LIN bus about 20 years ago, precisely to make
> it cheaper to have even more small microcontrollers around the car.
> 
> I have no idea about Tesla's patent here, but your description makes it
> sound utterly trivial.  That is not unusual for patents, of course.

Please reread my post and focus on what is being accomplished with the idea, not the fact that a bus is being used.  It's all there.  You only need to read it without a preconceived idea of what I wrote.  

-- 

  Rick C.

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