Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #29135 > unrolled thread

Poor man's PWM

Back to article view | Back to comp.arch.embedded

Contents

  Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-01-27 17:53 -0700
    Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-27 19:29 -0800
      Re: Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-01-28 20:11 -0700
        Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-28 20:11 -0800
    Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-28 11:29 +0100
      Re: Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-01-28 20:34 -0700
        Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-28 20:32 -0800
        Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-29 12:53 +0100
    Re: Poor man's PWM Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2020-01-28 14:43 +0100
      Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-28 12:03 -0800
      Re: Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-01-28 20:54 -0700
        Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-28 21:54 -0800
          Re: Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-01-29 00:17 -0700
            Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-28 23:40 -0800
              Re: Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-01-29 00:54 -0700
              Re: Poor man's PWM Paul Rubin <no.email@nospam.invalid> - 2020-01-29 00:04 -0800
                Re: Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-01-29 02:17 -0700
          Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-29 13:21 +0100
            Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-29 09:51 -0800
              Re: Poor man's PWM Paul Rubin <no.email@nospam.invalid> - 2020-01-29 10:07 -0800
                Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-29 10:14 -0800
                  Re: Poor man's PWM Paul Rubin <no.email@nospam.invalid> - 2020-01-29 10:28 -0800
                    Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-29 11:40 -0800
                      Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-30 10:25 +0100
                        Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-30 08:06 -0800
                          Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-30 21:21 +0100
                            Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-30 15:08 -0800
                              Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-31 01:17 +0100
                                Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-30 17:21 -0800
                                  Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-31 10:59 +0100
                                    Re: Poor man's PWM Rick C <gnuarm.deletethisbit@gmail.com> - 2020-02-01 10:18 -0800
              Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-30 10:20 +0100
                Re: Poor man's PWM Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-01-30 10:13 +0000
            Re: Poor man's PWM Paul Rubin <no.email@nospam.invalid> - 2020-01-29 09:57 -0800
              Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-30 10:29 +0100
        Re: Poor man's PWM Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2020-01-29 16:34 +0100
    Re: Poor man's PWM Dimiter_Popoff <dp@tgi-sci.com> - 2020-01-28 17:39 +0200
      Re: Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-01-28 19:58 -0700
        Re: Poor man's PWM Dimiter_Popoff <dp@tgi-sci.com> - 2020-01-29 18:54 +0200
    Re: Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-01-29 00:17 -0700
      Re: Poor man's PWM David Brown <david.brown@hesbynett.no> - 2020-01-29 13:39 +0100
        Re: Poor man's PWM Paul Rubin <no.email@nospam.invalid> - 2020-01-29 10:08 -0800
    Re: Poor man's PWM Don Y <blockedofcourse@foo.invalid> - 2020-04-27 20:13 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#29163

On Wednesday, January 29, 2020 at 1:07:40 PM UTC-5, Paul Rubin wrote:
> Rick C <gnuarm.deletethisbit@gmail.com> writes:
> > Design the circuit needed to drive an LED and duplicate it for N
> > outputs without worry.
> 
> But then there is the matter of getting the signals out to the LEDs.  Do
> you want to use 1000s of wires, or have some kind of fanout protocol?
> Either way is a pain.

How would you be driving 1000s of LEDs from one chip?  That seems like a disaster. 


> Of course the whole problem is fictional, but if they are really
> indicators, addressible LED's and some CAN bus stuff seems like the way
> to go.

Yes, 1000s of LEDs is a rare application indeed.  

On a project like this the devil is in the details.  But I will say using FPGAs as a solution is often overlooked because of the lack of familiarity with them and the imaginary difficulties in working with them.  

People don't use them much, so they reach for the hammer.  Some problems are actually screws, but if you want to use it, a hammer still works.  

-- 

  Rick C.

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

[toc] | [prev] | [next] | [standalone]

#29164

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, 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?

[toc] | [prev] | [next] | [standalone]

#29165

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. 

-- 

  Rick C.

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

[toc] | [prev] | [next] | [standalone]

#29167

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.

[toc] | [prev] | [next] | [standalone]

#29170

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

[toc] | [prev] | [next] | [standalone]

#29171

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.)

[toc] | [prev] | [next] | [standalone]

#29172

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

[toc] | [prev] | [next] | [standalone]

#29173

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.)

[toc] | [prev] | [next] | [standalone]

#29174

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

[toc] | [prev] | [next] | [standalone]

#29175

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.

[toc] | [prev] | [next] | [standalone]

#29178

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

[toc] | [prev] | [next] | [standalone]

#29166

On 29/01/2020 18:51, Rick C wrote:
> On Wednesday, January 29, 2020 at 7:21:41 AM UTC-5, David Brown
> wrote:
>> 
>> FPGAs are great for making lots of PWM channels, but it would not
>> be so easy to route those signals to the LEDs.  So you'd want
>> multiple distributed FPGAs with serial links between them.  It
>> could be done, but I'd expect it to be more development effort.
> 
> Yes, but every time we discuss FPGAs I believe you show how little
> you know about them.  This is very much a perfect application for
> small, low cost FPGAs.  There is enough logic in each one to drive as
> many LEDs as is convenient.  The development time is likely less than
> using MCUs since you can just develop your code without any worries
> of using interrupts to fake a sequential processor into appearing to
> provide parallel processing.

Of course FPGA's /could/ be used.  And small, cheap FPGA's are small and
cheap.

This system would need software to generate or otherwise control the
values to be used on all the PWM channels.  That would be /software/.

My suggestion involves developing hardware :

1. A board with a microcontroller that has a fast SPI peripheral, DMA,
enough memory, and whatever is needed for receiving or generating the
picture data.

2. Dumb boards with LED controller chips, with SPI in on one side and
out on the other side.  You use as many of these as needed for scaling.

On the software side, you have:

1. Software on the microcontroller for receiving or generating the
picture data.

2. Software for generating the PWM values for the picture.

3. Software to set up SPI, DMA and a timer.


Your solution would need hardware :

1. A board with a microcontroller (or FPGA with a processor) with some
fast bus (SPI, or something else) to the slave boards, and whatever is
needed for receiving or generating the picture data.

2. Slave boards with small, cheap FPGA's, with bus in and out of the
card, and lots of PWM signals.  You need LED driver hardware to power
the LEDs, and perhaps monitoring for currents (depending on the quality
of the display you are targeting).  You need a system for programming or
configuring the FPGAs, preferably in the bus (for simpler production and
updates).

It needs FPGA firmware:

1. If the main board uses an FPGA rather than a plain microcontroller,
that needs to be designed.

2. The small FPGA's need multiple PWM's, a daisy-chain bus (such as
SPI), and coordination of data between these.  It's not magic and would
be a straightforward task for an experienced FPGA designer, but it is
not insignificant either.  If you want current feedback and regulation,
that would be a good deal more work.

It needs software:

1. Software on the microcontroller for receiving or generating the
picture data.

2. Software for generating the PWM values for the picture.

3. Software to set up SPI, DMA and a timer (or whatever other bus is used).



I can't imagine how you think an FPGA solution is less development work
- it requires FPGA design in addition to everything else, not as an
alternative.  Note also that it requires three experts (or an expert in
three fields), rather than just two.

> 
> Design the circuit needed to drive an LED and duplicate it for N
> outputs without worry.  Simulate it in all it's gory detail and then
> run the final result with a high probability of success the first
> time.
> 

Or simply /don't/ design the circuit needed to drive an LED, because it
is in the driver chip.  That is obviously simpler.

And what is this about "using interrupts to fake a sequential processor
into appearing to provide parallel processing" ?  You are /way/ out to
sea on this one - utter nonsense.

You regularly accuse me of not knowing much about FPGAs.  I think you
know little about software development (your fondness for Forth suggests
your experience is limited to extremely simple programs on extremely
limited devices - it is a fine language for tiny stack-based processors,
but not for anything else).  You are so solidly FPGA-focused that you
see FPGA's everywhere, and are unable to imagine solutions that don't
involve them, or why there might be better solutions.  In particular,
you simply don't understand how software works - because you are
thinking in terms of FPGA design, and assume that sequential processor
software has to simulate parallel logic.

[toc] | [prev] | [next] | [standalone]

#29169

On 30/01/20 09:20, David Brown wrote:
>   In particular,
> you simply don't understand how software works - because you are
> thinking in terms of FPGA design, and assume that sequential processor
> software has to simulate parallel logic.

Amusingly the usual "problem" is the inverse: people coding
parallel logic as if it was sequential code :)

Apart from that, skimming the thread leads me to agree
with you PoV.

[toc] | [prev] | [next] | [standalone]

#29160

David Brown <david.brown@hesbynett.no> writes:
> The way I have seen big LED signs done is with chains of LED driver
> chips.  Each chip supports 8 to 24 chains of LEDs...

Another idea might be use Neopixel strips or whatever those things are
officially called.  Each LED has its own chip inside so you send it an
RGB value and it lights up at the color and brightness you tell it.
They are addressible, there's an older style with a timing based
interface, and a newer style that uses SPI directly:

https://www.adafruit.com/product/3919  etc.
https://www.adafruit.com/product/2240  These are the SPI ones

[toc] | [prev] | [next] | [standalone]

#29168

On 29/01/2020 18:57, Paul Rubin wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> The way I have seen big LED signs done is with chains of LED driver
>> chips.  Each chip supports 8 to 24 chains of LEDs...
> 
> Another idea might be use Neopixel strips or whatever those things are
> officially called.  Each LED has its own chip inside so you send it an
> RGB value and it lights up at the color and brightness you tell it.
> They are addressible, there's an older style with a timing based
> interface, and a newer style that uses SPI directly:
> 
> https://www.adafruit.com/product/3919  etc.
> https://www.adafruit.com/product/2240  These are the SPI ones
> 

I haven't seen LED's with controllers built in before, but it doesn't
surprise me that they exist.  Thanks for the links and hints - these
(the LEDs themselves, rather than the strips) could be interesting
devices for some applications.

[toc] | [prev] | [next] | [standalone]

#29157

Am 29.01.2020 um 04:54 schrieb Don Y:
> Hi Hans-Bernhard,
> 
> On 1/28/2020 6:43 AM, Hans-Bernhard Bröker wrote:
>> Am 28.01.2020 um 01:53 schrieb Don Y:
>>> But, instead of having N different times at which the IRQ
>>> might be signalled (for the N+1 different duty cycles) in
>>> each refresh interval, I plan on having log2(N) times, each
>>> delimiting an period "twice" as long as the previous.  This
>>> keeps the hardware cheaper than dirt 
>>
>> I rather much doubt that.  If there are indeed "few" intensity levels, 
>> i.e. 16 rather than 1024, this approch will at most reduce the overall 
>> software-PWM interrupt rate by a factor of 4;
> 
> Which means the timer can be four times FASTER!

No, it really doesn't.  Reducing the overall interrupt rate is, at most, 
the top of this iceberg.  The aspect that invariably drives CPU speed 
requirements, and thus cost, here is the peak interrupt rate, and your 
proposal doesn't affect that at all: you still have two interrupts to 
serve at 1/(16 * f) for PWM output frequency of f Hertz.

Also, your proposal will actually _increase_ the overall number of 
interrupts* for cases where you have to turn on one LED twice in the cycle.

> Obviously you're not a hardware person.  

Enjoying yourself throwing ad-hominems around, much?

> E.g., with a 10KHz *peak* IRQ rate, you'd have 100us to respond to THAT
> IRQ and get the next data ready -- simply COPYING it from a FIXED
> LOCATION to another FIXED I/O LOCATION -- for the timer to transfer
> to the LED "(hammer) drivers" coincident with the *next* IRQ.

Those 100 us are not the problem.  It's the latency of the interrupt 
routine, and its raw processing time.  The actual time between turning 
on and off that output has to be the same every time round, to within a 
few percents, or the thing will flicker abominablly, particularly at 
duty cycle '1'.  That means interrupt timing (including run-time of the 
handler itself) has to be stable down to a few us.

>> Overall, hardware that can implement this scheme will thus hardly be 
>> any cheaper than hardware that can implement the usual one.

> Really?  How much for 20 PWM channels?  200?  2000?  (I have a 2000 LED
> "moving message" sign at my feet, here -- wanna bet it DOESN'T have
> 2000 PWM channels?  Or, 2000 programmable current sources?)

That puts just as much burden on your scheme as it would on a 
straight-forward one.  Those 100us will appear mighty short if you were 
to do any work involving 2000 independent inputs on a cheap-ish micro.

PWM generation is rightfully delegated to dedicated hardware units, 
whether inside the CPU or outside.  SW is, ultimately, the wrong tool 
for this job.

>> Your plan also destroys any possibilities to distribute those EM 
>> emissions (and power supply loads) more evenly by staggering the PWM 
>> cycles of several LEDs. That aspect becomes more important as the 
>> loads get heavier, of course: 20 mA LEDs are a piece of cake, 20 
>> Ampere heaters not so much.
> 
> They are *indicators*, not *illuminators*.
> 
> I'm going to give you 20 (or 200 or 2000) DEDICATED PWM channels.  How 
> are YOU
> going to stagger theur cycles?  

By distributing their starting points evenly across the base cycle. 
Possibly, in a higher-level routine, keep a watch out for any time slot 
that has higher workload than others, and shift that around.

And at 2000 LEDs, your _are_ talking about quite an illuminator if you 
turn them all on. Avoiding wildly fluctuating loads to the power supply 
does become a factor to consider in that case, particularly if you want 
that supply to stay cheap.

Ultimately one might not need ISRs at all, if just about all that chip 
is going to do is turn on and off LEDs.  It could busy-loop on a 
time-sorted priority queue of switching events instead.

[toc] | [prev] | [next] | [standalone]

#29139

On 1/28/2020 2:53, 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).
> 
> But, instead of having N different times at which the IRQ
> might be signalled (for the N+1 different duty cycles) in
> each refresh interval, I plan on having log2(N) times, each
> delimiting an period "twice" as long as the previous.  This
> keeps the hardware cheaper than dirt and minimizes the
> real-time load on the processor.
> 
> [There are (refresh_rate * log2(N)) IRQs each second instead
> of (refresh_rate * N) IRQs -- though the *instantaneous* IRQ
> rate varies considerably]
> 
> Then, at the level above the driver, build a schedule for which
> intervals to activate the LED.
> 
> E.g., for each level: turn the LED on in intervals:
> 0   None
> 1   1
> 2   2
> 3   1&2
> 4   4
> 5   1&4
> 6   2&4
> ...
> N   All
> 
> What problems might I encounter with this approach?  (I'm
> mainly worrying about visual artifacts)

Hi Don,

whatever PW you do beware the randomness, even small,
from period to period. I did something like that once many years ago
(just wanted to have 3 colours out of a 2 colour LED) and the mixed
colour was quite visibly flickering. I don't remember how much
randomness there was and how it might compare to yours but using
IRQ and bit banging it does invite some, I'd test that before
rolling it out. I think mine used IRQ just to switch tasks and
measure time on a HC11 back then (some 20 years ago) but I don't
think I pushed much to get rid of the flicker, it was not a problem.

Dimiter

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#29141

Hi Dimiter,

On 1/28/2020 8:39 AM, Dimiter_Popoff wrote:
> whatever PW you do beware the randomness, even small,
> from period to period. I did something like that once many years ago
> (just wanted to have 3 colours out of a 2 colour LED) and the mixed
> colour was quite visibly flickering. I don't remember how much
> randomness there was and how it might compare to yours but using
> IRQ and bit banging it does invite some, I'd test that before
> rolling it out. I think mine used IRQ just to switch tasks and
> measure time on a HC11 back then (some 20 years ago) but I don't
> think I pushed much to get rid of the flicker, it was not a problem.

How were you driving it?  I.e., was it a two-lead (bi-color)
device?  Or, THREE?  In the former case, I could see how
the duty cycle in one direction (terminal 1 to terminal 2)
differing from that of the other direction (terminal 2 to
terminal 1) would alter the relative mix of the two colors
and, thus, the resulting color.  In the latter case,
perhaps driving one (or both) anodes/cathodes with a
particular duty cycle to "tune" the color?

The obvious fix is to double-buffer the drive to the device so
that the same signal that prompts the ISR to change the drive
*also* locks in the previous decision to the actual indicator.
This makes the entire IRQ period available for servicing the
ISR without having visual consequences -- for the cost of (an)
external latch(es).  Latency issues go away (largely).

[But, this either requires a "terminal count output" from an
internal timer/counter -or- an external counter/timer driving
an IRQ input (that can also trigger the latches).]

A related problem is how "nearby" indicators are perceived.
E.g., will two different indicators be seen as having differing
intensities even though *intended* to have the same intensity?
I.e., is the visual output of a device "matched" to others
ACROSS THE FULL RANGE OF DRIVE CONDITIONS?  Or, just at
a particular test criteria?

And, how far apart do such devices need to be in order for the user
NOT to be able to perceive (minor) differences?  Two die in the same
package (your case!) is obviously one extreme!

I'm not keen on having to purchase "matched" devices or any
"select at test".  So, would rather just AVOID issues that
could lead to visual aberrations, etc.

[toc] | [prev] | [next] | [standalone]

#29158

On 1/29/2020 4:58, Don Y wrote:
> Hi Dimiter,
> 
> On 1/28/2020 8:39 AM, Dimiter_Popoff wrote:
>> whatever PW you do beware the randomness, even small,
>> from period to period. I did something like that once many years ago
>> (just wanted to have 3 colours out of a 2 colour LED) and the mixed
>> colour was quite visibly flickering. I don't remember how much
>> randomness there was and how it might compare to yours but using
>> IRQ and bit banging it does invite some, I'd test that before
>> rolling it out. I think mine used IRQ just to switch tasks and
>> measure time on a HC11 back then (some 20 years ago) but I don't
>> think I pushed much to get rid of the flicker, it was not a problem.
> 
> How were you driving it?  I.e., was it a two-lead (bi-color)
> device?  Or, THREE?  In the former case, I could see how
> the duty cycle in one direction (terminal 1 to terminal 2)
> differing from that of the other direction (terminal 2 to
> terminal 1) would alter the relative mix of the two colors
> and, thus, the resulting color.  In the latter case,
> perhaps driving one (or both) anodes/cathodes with a
> particular duty cycle to "tune" the color?
> 
> The obvious fix is to double-buffer the drive to the device so
> that the same signal that prompts the ISR to change the drive
> *also* locks in the previous decision to the actual indicator.
> This makes the entire IRQ period available for servicing the
> ISR without having visual consequences -- for the cost of (an)
> external latch(es).  Latency issues go away (largely).
> 
> [But, this either requires a "terminal count output" from an
> internal timer/counter -or- an external counter/timer driving
> an IRQ input (that can also trigger the latches).]
> 
> A related problem is how "nearby" indicators are perceived.
> E.g., will two different indicators be seen as having differing
> intensities even though *intended* to have the same intensity?
> I.e., is the visual output of a device "matched" to others
> ACROSS THE FULL RANGE OF DRIVE CONDITIONS?  Or, just at
> a particular test criteria?
> 
> And, how far apart do such devices need to be in order for the user
> NOT to be able to perceive (minor) differences?  Two die in the same
> package (your case!) is obviously one extreme!
> 
> I'm not keen on having to purchase "matched" devices or any
> "select at test".  So, would rather just AVOID issues that
> could lead to visual aberrations, etc.

Hi Don,
this was the LED indicator of a HV unit, I wanted it green while
operating normally, red if some protection did kick in and yellow
while the voltage was being driven up (at say 100V/s for 4-5 kV).
So the fact it was flickering was no issue at all, it even gave the
impression of an ongoing change.
I probably did not use double-buffering for that indicator on the HC11
that controlled it which did double-buffering for the PWM driving the
HV convertor though (using output compare with double buffering is
the standard way to do PWM on a HC11).

The LED had 2 leads (never had one with 3 so I know that) and the
uncertainty because of latency must have been within microseconds,
may be tens of microseconds (I just do not remember how I did it,
I remember I did not care a lot, saw it flicker but deemed it
good enough and moved on).

Dimiter

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#29149

On 1/27/2020 5:53 PM, Don Y wrote:
> What problems might I encounter with this approach?  (I'm
> mainly worrying about visual artifacts)

(sigh)  I've been considerate and responded to many comments
UNRELATED TO THE QUESTION THAT I POSED (see above).  But,
aside from Dimiter's comments, most have completely ignored
this.

Gee, let's talk about processor choice, next!

Or, programming language!

Or, component selection!

Or, vendor selection!

Or...

I am fully capable of implementing the algorithm proposed -- in
various different ways for various different "loads" (LEDs aren't
the sole application... but, hey, let's digress into even more
unrelated areas to avoid the question posed!).

Where I need assistance is in anticipating how LEDs driven in this
SORT OF manner could potentially have undesirable appearances.
Moving from incandescent and magnetic ballast lighting to CFLs
and LEDs leaves a great many different visual environments
in which a device is viewed.  It would really be annoying if
my scheme suffered in some particular office/lab/home/outdoor
environment that I hadn't anticipated during the design phase.

If you can offer some concrete comments wrt that issue, great!
I get it -- it's not a run-of-the-mill sort of knowledge domain.
No shame in admitting your ignorance!  I've done so with my
question, here.

Feel free to pursue your own implementations on your own dime.
Great if you choose to share them -- in their final form, ready
for critique -- here.  We can then play endless "what if"
games:  what if 10 indicators?  100?  what if they are replaced
with solenoids?  or resistive heaters?  what if more levels?
less levels?  what if we try and drive 30 servomotors while running
the displays?  60?  replace servo motors with stepper motors?
run a full network stack?  *multiple* network interfaces?  live
packet routing?  IPSEC?  etc.

Gee, the fun we can have (and the time we can waste)!

The local University is supposedly renowned for its optics
department.  I will assume that I can find someone there
who will have, at least, a theoretical knowledge of how it
relates to vision.  Unfortunately, it is a VERY large organization
so it will take me time to find the right folks -- I had hoped
someone HERE might have direct experience in the subject  :<

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web