On 12/24/2023 2:41 PM, rhor...@gmail.com wrote:
> On Saturday, December 23, 2023 at 12:47:50 PM UTC-6, Don Y wrote:
>>> Again, via what means? Telekenesis?
>
>> Um, maybe via the hardware RESET?
>
> Until two days ago, I did not know the Raspberry Pi had one. It doesn't have one on its 40 pin I/O interface, which is surprising. If I do use it, I am going to have to ask my clients to solder on their Raspberry Pi's, and a lot of these people have never held a soldering iron in their lives. 'Not exactly the best recommendation for a product, I must say. How often do you tell your clients they are going to have to take one of their own devices and solder on it?
Who chose the rPi?
> Meanwhile, I can only notice the fact it was someone other than you who pointed out the actual location of the RUN port on the Pi and that it is not on the I/O header where a person developing a board like this has direct access to it.
Wow, so you're nitpicking because I told you it existed but didn't tell
you where to find it -- even before you had told me WHICH rPi you were using?
Growth the f*ck up.
>> New to this field, eh?
>
> If starting in 1972 constitutes "new", then I guess so.
And, after 50 years, you didn't know"
- processors have a RESET ability
- the product YOU (?) chose had one
Maybe the NEXT 50 years will improve upon your education...
>> Sure seems like a piss poor design.
>
> Talk to the developers. Since they are all volunteers and are not paid for their work, I am sure they will be happy to deal with your arrogant attitude.
That's an oblique way of saying they are cheap and don't want
to BUY a working design.
Is your DENTIST similarly inclined?
> Meanwhile, what, exactly, do you suggest as an alternative? It must be able to load and run Debian Linux, get updates from the internet, and cost less than $40. You also have to convince the developers to support it, and I have been unable to get them to even support the Orange Pi or similar boards. 'Not that I blamer them.
THEY decided it has to run Debian. Why should I be constrained by
their choice? What if they had equally arbitrarily decided it
should be YELLOW?
>> Do you tolerate many of the other items you use ROUTINELY refusing to operate AS EXPECTED?
>
> Yes, but then I live in the real world. Thank goodness, because if everything always worked as expected, I would not have had a job for the last 40 years.
Ah, the real world that I design in has consequences for failures and
faulty products. Cars being recalled, providers being sued, etc.
These tend to be big incentives to get things RIGHT.
Volunteers usually don't worry about these things because they aren't
the ones being sued!
>> (Or, do you simply EXPECT this to fail, often?)
>
> Based on historical data, yes. One of the systems went down an hour and 8 minutes ago. Fortunately, this time it recovered by itself. It doesn't always.
Wow, you've found a problem that's harder to solve than designing interstellar
space probes with multi decade missions!
>> Can you assure yourself (and your customers) that it will NEVER recur often
>> enough that it fails to perform its intended function?
>
> No. Does General Motors? IBM? General Electric? Microsoft? Hell, even a Rolls Royce will "fail to proceed", and it will take a good chunk out of $1 million. We are talking about free software that runs on a free operating system hosted on a $35 SBC.
They wouldn't select a $35 SBC for the solution! Or, were know how to
use it in such a way that it didn't fail.
>> How do you know it won't need THREE -- or FOUR -- or COUNTLESS such "shutdowns"?
>
> I know for a probable fact that will happen. Again, so what?
It's a "probable fact" that it will REPEATEDLY fail. So,
why not just NOT deploy it and claim the (non-deployed)
product is failing as expected and NOT providing the desired service?
Or, why not design a solution that actually works?
I.e., find smarter volunteers and "customers" that are
willing to pay more than $35 for a solution. (i.e., THAT
declares the value of your product, to the customer).
I wouldn't pay more than $35 for a doorbell. So, I guess
their problem is of similar value.
>> You haven't identified the cause so how can you be sure you've got a cure?
>
> When the exact cause or causes are not known, treating the symptoms frequently works well enough. This is doubly true when it is known the cause absolutely cannot be addressed. 'Sort of like there is no way for me to stop you from spouting nonsense.
Ah, and there's the rub. Yo' don't understand engineering so it sounds like
nonsense to you. Well, it would also sound like nonsense to a child...
>>> The Arduino will take care of that.
>
>> And the Arduino will be 100% reliable.
>
> No. Unfortunately, you did not design the Arduino, so it is not 100% reliable </sacasm>
So, you've put an unreliable monitor into a product to monitor an
unreliable design. Why not add yet another? Eventually, ONE of them
will sort out what's going on.
>> "Why don't they make aircraft out of the same material that they
>> use for their Black Boxes?"
>
> I see I can rest my case.
>
>>> In teh past, it was not unusual for the micro-SD card to become corrupted when
>>> the Pi shuts down. When that happens, the system is tost anyway until a new
>>> SD card is inserted.
>
>> So, the solution *IS* the problem! "Buy two!"
>
> Which solves nothing, especially since it is going to be fairly difficult to get most of the demographic to buy one.
So, it's not worth -- to them -- the price you are paying for the components.
Or, it isn't reliable enough to be worth that.
Sounds like your "volunteers" have a poor grasp of the problem AND the market.
>>> About 2 releases ago, they seem to have fixed that issue,
>
>> Who is "they"?
>
> Who do you think? The software developers. Who else would fix software?
You haven't said if "they" are you, a party with which you have influence or
control, a supplier or...
>> Are you a customer or a supplier?
>
> I am a customer of the software, and a potential supplier of supplemental hardware, if this works. What does it matter?
It matters to the extent that you have a stake in the decision making
process. A customer can find an alternate supplier. A supplier can
risk losing their customers due to poor design choices.
A customer that CAN'T find an alternate supplier is at the mercy of
his supplier. A supplier who can't "fix" the design is at the mercy of
the market finding an alternative that makes his efforts/investment
wasted.
A client of mine recounted a story where they sold a piece of expensive
equipment to a customer of theirs. The customer returned it, irate,
because it was obviously "hand built/wired/etc." and they didn't
consider it "made to professional standards" (whatever those are).
A few weeks later, they asked to repurchase it when they discovered
that it was the *only* product serving their small, niche market.
(Gee, no wonder it was built in quantities of *one*!)
>> but if it hapens again, it happens. Nothing can automatically fix that in this arena.
>
>> Nothing that you've apparently *tried*. Or, you've tied your hands with
>> a particular solution before completely exploring what's possible.
>
> This is a product that must cost less than $50 and will probably at the very most sell perhaps 200 or so units. It is supplemental to software that only is supported to run on the Raspberry Pi and Beaglebone SBCs. Are you volunteering your time and resources to investigate and "fix the issue"? I thought not.
Of course not. Why would I care about *your* problem? Some markets
can't be addressed under the constraints that folks would *like* to
apply. I'm sure NASA would have loved to be able to go to the moon
for a few thousand (!) dollars -- and, only a handful of times.
Can't squeeze the balloon at both ends. The desire to *go*
was greater than the desire to do so cheaply.
>>> When that is down, the entire system fails.
>
>> So, yet another bad solution. Sure starts to sound like a HOBBYIST
>> approach to a problem and not an ENGINEERED solution.
>
> It is a hobbyist product. So what? Are you suggesting there is something wrong with that? If products designed for hobbyist use are beneath your magnificence, then quit bothering to comment.
You didn't point that out at the onset of your post.
Most of us (here) design products for sale -- for folks
who understand the value of the devices that they
want to purchase. Tell us you want something on the
cheap for folks who "have short arms" and no one will
spend much time trying to understand your problem.
Because your counterarguments will be predictably "we
don't have the time, money, expertise, etc. to do that".
>> Is there some reason we can't know what it *does*
>
> How is that relevant to my questions? 'Not that your attitude or any of your comments compel cooperation on my part, but it is a holiday light and multimedia display primarily designed to control WS281x pixel strings. The industry as a whole, as it happens, involves many millions of dollars worldwide, but many hobbyists, such as I, indulge themselves in it.
None of your QUESTIONS compel answers on MY part. Yet, I took
it upon myself to offer you advice as to issues that could
assist your initial posted effort.
For that, I am rewarded by a guy who is defensive of his ignorance.
If the industry is "millions of dollars worldwide" (which is
true of probably MOST applications, "worldwide"), then someone
will solve your problem for a few *dollars*. Because they
won;t rely on "volunteers" to come up with a solution
as they will expect to reap the profits from those "millions
of dollars" of potential sales.
So, if you *want* to solve the problem, realize the OPPORTUNITY
that you claim exists and finance a *real* solution. And, prepare
to scale up quickly as that few dollar solution will likely be
copied, quickly, and sold direct by the firm that you outsource to
build the things FOR you.
>> that you would be so patient with such a half-assed solution?
>
> I am not patient. I do recognize when a "solution" is not worth the time, cost, and effort.
>
>> No one. *But*, none of my clients would accept a solution that
>> "sort-of, almost worked... EXCEPT when _____".
>
> Well, bully for you. I don't know who your clients are - nor care, really - but my professional industry (which this is not) involves trillions of dollars and billions in revenue, of which my company raked in a good 20%, and involved clients such as AT&T, Verizon (both of whom were also competitors), T-Mobile, the U.S. Department of Defense, the National Security Agency, Intel, Microsoft, and others I cannot mention. We never offered them any 100% guarantees, and some of them payed us millions a year. If I am incredibly lucky, I might make $500 off this.
Then why are you bothering? Surely it means SOMETHING to you. I spend $500
in a few hours of my time. Wouldn't you prefer to be able to say you've
come up with a solution that *works* (for however much/little money it
nets you) than to waste your time on something that doesn't?
Why not just put a MECHANICAL timer on the power supply and have it,
UNCONDITIONALLY, power off the rPi for a few seconds every HOUR?
Isn't that solution just as bad as yours? And, likely you can find
something COTS that can be repurposed to that goal!
>> "What happens if this ______ happens while we're in surgery?"
>
> Most of the world is not comprised of surgeons, although as it happens, a mistake of mine did once possibly contribute to the death of an infant. I am not happy about it.
If you assume some applications are less important than others, then
you don't give your best effort to the design of ALL applications.
>> "If this _______ happens, how long will the manufacturing line be shut down?
>
> Not even a single millisecond. But then not everyone is as wonderful as you. OTOH, when and why did this thread come to be about you and your customers? How does that apply to whether the two components I mentioned will work to my satisfaction?
Apparently, you and the customers you are addressing have low standards.
You can probably save a few pennies by omitting the silkscreen, using
85C caps, soldering direct instead of using connectors, etc. If
you don't care about the quality of the product...
>> Until, of course, you decide to look for a REAL solution!
>
> Oh, brother.
>
>>> That has not been the most common issue, however, and in any
>>> case has nothing to do woith my original question.
>
>> And I've not asked or commented about them.
>
> Then you are doing nothing but wasting our time.
Because I didn't ask about OTHER things that you didn't mention?
"In particular, this board supports a high speed fan and a Peltier
cooler or other 12V, 5A cooling system. That has not been the most
common issue, however, and in any case has nothing to do woith my
original question."
>> Wrong answer. Code *size* has no bearing on what a "smaller"
>> ...
>> space was 64KB for code+data).
>
> I repeat: Oh, brother.
My sentiments, exactly: "Oh, brother! This guy with 50 years experience
STILL is clueless about software, processors, etc. Arduinos and rPis...
(sigh)"
>> Some deployments take more. > It runs poorly on a single CPU, if at all in some cases.
>
>> You haven't hesitated to ADD an MCU so why are you afraid of adding a second CPU?
>
> Because no one would pay the extra money. It would kill the project before it even got started.
Because you are looking at the problem wrong. The rPi is the problem.
Remove *it* and you've got "$35" to play with!
But, that's obviously beyond your capabilities as you've bought into the
idea that you *need* an rPi, Linux, Peltier cooler, etc. to solve this
problem.
If you looked at it "from scratch", your approach would likely not
be so constrained. But, you'd need to be able to point to THE issues
that are causing the problems so you could focus on addressing THOSE
in your NEW solution.
>> Sixteen Gigs of storage minimum is suggested and at least 512M of RAM.
>
>> I.e., you can access a smaller portion over a similar
>
> *I* am not doing anything. Linux is. Do you have a problem with people running Linux or writing software for it?
The problem seems to be that their software isn't reliable on the rPi
in YOUR application. It's not *my* problem, at all!
>> (I designeda 1-bit wide DRAM array in a product
>
> Yeah, we all know how wonderful you are.
I've got a trophy here to remind folks who forget.
>> Yes, sounds more and more like a HOBBYIST product...
>
> Yeah, so what? In the U.S. alone, the hobbyist industry accounts for over $14 billion a year in revenue. Gaming accounts for gawd knows how much worldwide. My professional work is not part of the hobbyist industry, but many hundreds of thousands of people's employment is, and this personal project is. What, exactly, is your point? How does it relate to the questions at hand?
Because the whole approach is not "well conceived". It's like a client
saying "let's take a PC and..."
Why a PC? Just because it's a computer? There's a computer in my phone.
Why not use that one, instead? Or, the one in my mouse? Or...
Hobbyists try to piece together solutions from "stuff they can get".
This ties one or both of their hands. And, leads to unforseen
consequences down the road when their (usually) ill-defined goals
meet up with reality.
A ("professional") designer looks at the problem and ENTIRE solution
space and finds the best solution to fit the criteria specified.
And, stands a helluvalot better chance of hitting his target.
> Just out of curiosity, did you sneer at the developers of the Nintendo or Playstation?
I seem to recall them sold by real companies, not hobbyists operating
out of garages.
>> Again, you've said nothing that REQUIRES an rPi or
>> precludes the use of something else. I've run network stacks
>> on PICs.
>
> No, I haven't, because it has absolutely nothing to do with the topic. Aside from the fact the software is only supported on one other hardware platform, this project is for a daughterboard that attaches to a Raspberry Pi. Selecting some other platform would completely eliminate the entire project. 'Satisfied?
How does it have nothing to do with the project? It is the reason
behind your perceived need!
Select that "other platform" and eliminate the project -- and the problem!
>> So, $35 for something that ALMOST works. Sounds like a plan!
>
> No, the plan is to ignore anything else coming from you unless you can manage to bring it on-topic and ditch the attitude.
That's great! I can look forward to not seeing any more of
your posts!
Be sure to keep us appraised of your "successes". Maybe add an
electomechanical counter to each device so you can reliably
report how often it activates -- to justify its use over a simpler
"reset the processor every minute" approach.
Holly Hapidays!