Actually, I am fairly sure - but not certain - it will work, and I am a little less sure it will work well enough. I have included a link to a schematic of the design below. "Switch 1" is actually a GPIO output pin from an Arduino, and R5 is actuallyA Raspberry Pi. The intent is to have the Arduino shut down the RPi when a certain variable is true and turn it back on when the variable is false. The default will be for the RPi to be on until the Arduino's GPIO pin goes high, producing a 3.3V signal
In particular, Optocoupler X5 does not have a BJT output. I have a ton of H11F1 Optocouplers (read that: free) which I need to use, and they have symmetrical bilateral silicon photo-detectors as their outputs. Micro-Cap does not have an exact matchfor this, but I think the FET output Coupler will work just fine to switch the P-Channel X4 MOSFET. If anyone knows of any reason why an H11F1 Optocoupler will not work here, please let me know.
A bit more worrisome is the PC-Channel MOSFET. Micro-Cap does not have an exact match for the PMV28XPEAR MOSFET I need to use. Again, I think it will work, but I am not certain. I tried several different MOSFETs in the simulator, and some performquite well, with less than 0.1V drop, but others have as much as 0.25V drop in the same situation, which is a bit too much. The PMV28XPEAR has a quite low Rds of around 40 milliohms, but I am not at all sure a somewhat higher Rds is why some of the
http://siliconventures.net/images/Raspberry%20Pi%20Lighting%20HAT%20switch,jpg.JPG
Actually, I am fairly sure - but not certain - it will work, and I am a little less sure it will work well enough. I have included a link to a schematic of the design below. "Switch 1" is actually a GPIO output pin from an Arduino, and R5 is actuallyA Raspberry Pi. The intent is to have the Arduino shut down the RPi when a certain variable is true and turn it back on when the variable is false. The default will be for the RPi to be on until the Arduino's GPIO pin goes high, producing a 3.3V signal
In particular, Optocoupler X5 does not have a BJT output. I have a ton of H11F1 Optocouplers (read that: free) which I need to use, and they have symmetrical bilateral silicon photo-detectors as their outputs. Micro-Cap does not have an exact matchfor this, but I think the FET output Coupler will work just fine to switch the P-Channel X4 MOSFET. If anyone knows of any reason why an H11F1 Optocoupler will not work here, please let me know.
A bit more worrisome is the PC-Channel MOSFET. Micro-Cap does not have an exact match for the PMV28XPEAR MOSFET I need to use. Again, I think it will work, but I am not certain. I tried several different MOSFETs in the simulator, and some performquite well, with less than 0.1V drop, but others have as much as 0.25V drop in the same situation, which is a bit too much. The PMV28XPEAR has a quite low Rds of around 40 milliohms, but I am not at all sure a somewhat higher Rds is why some of the
http://siliconventures.net/images/Raspberry%20Pi%20Lighting%20HAT%20switch,jpg.JPG
Actually, I am fairly sure - but not certain - it will work, and I am a little less sure it will work well enough. I have included a link to a schematic of the design below. "Switch 1" is actually a GPIO output pin
from an Arduino, and R5 is actually A Raspberry Pi. The intent is to have the Arduino shut down the RPi when a certain variable is true and turn it back on when the variable is false. The default will be for the RPi to be
on until the Arduino's GPIO pin goes high, producing a 3.3V signal at R4, which energizes the X5 Optocoupler's LED and turns off the X4 MOSFET.
fredag den 22. december 2023 kl. 19.45.55 UTC+1 skrev Don Y:
On 12/22/2023 6:53 AM, rhor...@gmail.com wrote:
Actually, I am fairly sure - but not certain - it will work, and I am a*Why* do you want to remove power from the rPi? Are you trying to
little less sure it will work well enough. I have included a link to a
schematic of the design below. "Switch 1" is actually a GPIO output pin
from an Arduino, and R5 is actually A Raspberry Pi. The intent is to have >>> the Arduino shut down the RPi when a certain variable is true and turn it >>> back on when the variable is false. The default will be for the RPi to be >>> on until the Arduino's GPIO pin goes high, producing a 3.3V signal at R4, >>> which energizes the X5 Optocoupler's LED and turns off the X4 MOSFET.
*conserve* power? Ensure a "restart from POST"? Deactivate
the rPi regardless of what it may be doing at the time? etc.
If trying to conserve power, have you looked at total power consumption
when the rPi is running vs. held in reset?
If trying to ensure a restart or unconditionally deactivate the
rPi, forcing reset can also do the trick.
Be sure to consider the case where the Arduino is powering *up*
and the GPIO(s) will likely be indeterminate (e.g., external pullup
in input mode -- causing your rPi to be OFF until the Arduino
can successfully start, set the GPIO to output mode AND drive
it low (to enable the rPi).
Also, if the rPi is doing something of value, consider any
synchronization issues that may be part of the Arduino
interaction (e.g., if you just power it on/off, there is
no guarantee it will "remember" particular data values
correctly; memory and I/O cycles will be "abused")
easy enough with linux on a PI, gpio-shutdown and gpio-poweroff are standard drivers
with a gpio you signal to gpio-shutdown to do a shutdown, gpio-poweroff signals via gpio
that turning off the power is safe
fredag den 22. december 2023 kl. 22.20.36 UTC+1 skrev Don Y:
On 12/22/2023 12:08 PM, Lasse Langwadt Christensen wrote:
fredag den 22. december 2023 kl. 19.45.55 UTC+1 skrev Don Y:The *Arduino* is the device that is directly controlling the power *to*
On 12/22/2023 6:53 AM, rhor...@gmail.com wrote:
Actually, I am fairly sure - but not certain - it will work, and I am a >>>>> little less sure it will work well enough. I have included a link to a >>>>> schematic of the design below. "Switch 1" is actually a GPIO output pin >>>>> from an Arduino, and R5 is actually A Raspberry Pi. The intent is to have >>>>> the Arduino shut down the RPi when a certain variable is true and turn it >>>>> back on when the variable is false. The default will be for the RPi to be >>>>> on until the Arduino's GPIO pin goes high, producing a 3.3V signal at R4, >>>>> which energizes the X5 Optocoupler's LED and turns off the X4 MOSFET. >>>> *Why* do you want to remove power from the rPi? Are you trying to*conserve* power? Ensure a "restart from POST"? Deactivate
the rPi regardless of what it may be doing at the time? etc.
If trying to conserve power, have you looked at total power consumption >>>> when the rPi is running vs. held in reset?
If trying to ensure a restart or unconditionally deactivate the
rPi, forcing reset can also do the trick.
Be sure to consider the case where the Arduino is powering *up*
and the GPIO(s) will likely be indeterminate (e.g., external pullup
in input mode -- causing your rPi to be OFF until the Arduino
can successfully start, set the GPIO to output mode AND drive
it low (to enable the rPi).
Also, if the rPi is doing something of value, consider any
synchronization issues that may be part of the Arduino
interaction (e.g., if you just power it on/off, there is
no guarantee it will "remember" particular data values
correctly; memory and I/O cycles will be "abused")
easy enough with linux on a PI, gpio-shutdown and gpio-poweroff are standard drivers
with a gpio you signal to gpio-shutdown to do a shutdown, gpio-poweroff signals via gpio
that turning off the power is safe
the rPi. So, unless there is some other mechanism for the Arduino *tell*
the rPi (not mentioned or shown in schematic) that it is about to pull
the plug on the rPi, the rPi will just find power removed from under it...
so you need two gpios and enabling two standard drivers
On Friday, December 22, 2023 at 12:45:55 PM UTC-6, Don Y wrote:
*Why* do you want to remove power from the rPi? Are you trying to
*conserve* power?
No. The entire system may use up to several thousand watts. (On AC line power, of course, not on 5VDC ) The Pi's power use is immaterial.
Ensure a "restart from POST"?
No
Deactivate the rPi regardless of what it may be doing at the time? etc.
Yes, although usually it won't be doing anything. It will have suffered a kernel panic, or something. The watchdog removes power for a few seconds
and then restorers it.
The Arduino will also permanently disable the Pi if
the environmental temperature goes too high. A few times last year the temperatures in the case rose to over 70C.
If trying to ensure a restart or unconditionally deactivate the rPi,
forcing reset can also do the trick.
How? The kernel has panicked (or something), and the Pi is locked up. Other than removing power, how am I to reset it?
Be sure to consider the case where the Arduino is powering *up* and the
GPIO(s) will likely be indeterminate (e.g., external pullup in input mode
-- causing your rPi to be OFF until the Arduino can successfully start,
set the GPIO to output mode AND drive it low (to enable the rPi).
Yes, of course. That is all part of the startup. The first line in the Arduino code will set up the pim and drive the GPIO low. Obviously, I can't do anything about anything until then. If the Pi's operation is delayed by
a few seconds, c'est la vie.
Also, if the rPi is doing something of value,
When the Pi is locked up, the "value" of its operations are moot. Getting
it back online is the only issue at hand. The last time the system locked up, the guy was away, and it took over a week for him to come back and
unplug and re-plug the power.
consider any synchronization issues that may be part of the Arduino
interaction (e.g., if you just power it on/off, there is no guarantee it
will "remember" particular data values correctly; memory and I/O cycles
will be "abused")
They are not synchronized. Operation is asynchronous. The Arduino monitors two lines from the Pi. One is toggled continuously by software every few milliseconds. If the toggling stops, the Arduino assumes the Pi has stopped functioning and kills power. The second line is held low by the Pi until it wants to disable the Arduino,
presumably because the Pi wants to shut down
or perform maintenance. This sends the Arduino into a permamnet loop, insuring it will never kill power. The only way to re-enable the watchdog
is to manually restart the Arduino.
Here are pictures of the current board design: http://siliconventures.net/images/Raspberry%20Pi%20Board%20Top.JPG http://siliconventures.net/images/Raspberry%20Pi%20Board%20Bottom.JPG
On Friday, December 22, 2023 at 7:47:26 PM UTC-6, Don Y wrote:
The point is that you (the OP) has to THINK about whetherObviously. Again, this is a watchdog.
or not the rPi can just be "unceremoniously" powered on/off.
If the Arduino determines the Pi has locked up, it reboots it. SOP for a watchdog circuit.
On Friday, December 22, 2023 at 1:08:52 PM UTC-6, Lasse Langwadt Ch= >ristensen wrote:
easy enough with linux on a PI, gpio-shutdown and gpio-poweroff are stand= >ard drivers
with a gpio you signal to gpio-shutdown to do a shutdown, gpio-poweroff s= >ignals via gpio
that turning off the power is safe
No, this is a watchdog. It must be separate from the Pi. If the Pi locks = >up - which happens a lot -
On Friday, December 22, 2023 at 11:15:28?AM UTC-6, Fred Bloggs wrote:safe.) That is nothing compared to the maximum 5 amperes the circuit has to handle. Finally, the opto-coupler is going to be completely dead more than 99% of the time. It will only be energized for about 10 seconds or so whenever it shuts down the Pi,
Well, first of all, why would I scrap something I can use and for which I have already paid? Secondly, the opto-coupler only uses a couple of milliamps, at most, and that only if I reduce the size of R4. (Which, actually, I think I will just to behttp://siliconventures.net/images/Raspberry%20Pi%20Lighting%20HAT%20switch,jpg.JPGScrap that archaic and unnecessary power hog opto. Use this instead:
footprint, makes for .350 x 245 K/W= 83oC junction temperature rise. Tjmax of 175oC means your max operating environment is 175-83= 91oC= 200oF, which should be okay, unless it's under a car hood or something like that. Just don't put it near anythingYeah, I have some 2N3904 transistors, and a few others. See above.
https://www.amazon.com/Chanzon-N-Channel-Bipolar-Junction-Transistor/dp/B083TNW1M1/ref=sr_1_1_sspa?th=1
If 1.8R is representative of the RP circuit, which is nearly 3 Amps, then you have to stay with the PMV28XPEAR, a great part for the application. RDS max is 38mR, making power dissipation 3^2 x 0.038= 350 mW which with a max Rtheta,j-a in standard
It's worse than under a car hood, unfortunately. It's outside. In South Texas. (And potentially other very hot places.) In direct sunlight. In an air-tight enclosure. The board has a 12V, high speed fan, and a drive for a Peltier cooler.
On Friday, December 22, 2023 at 9:38:15?AM UTC-6, John Larkin wrote:at cooler temperatures), both of which are pretty low. Of course, I agree with you it SHOULD work, but I am a nervous sort of guy, I guess, when I am not certain of something.
Well, one would think, but some of the MOSFETs I modeled dropped as much as 0.25 Volts. Others modeled to be less than 0.06 volts. The spec sheet says the threshold of the PMV28XPEA is between -0.6 and -1.3V and the Rds-on at 5A is a max of 50ma (lesshttp://siliconventures.net/images/Raspberry%20Pi%20Lighting%20HAT%20switch,jpg.JPGThat has to work. Maybe delete R3. Any low-threshold, low Rds-on pfet
will work.
R3 is just a safety measure to make sure nothing spurious triggers the LED.
It isn't really necessary, of course, but I habitually provide stray current protection whenever I a dealing with semiconductors. Admittedly, diodes are pretty immune. I have been caught a couple of times when I did not short the base / emitter orgate /source of a transistor. It was amusing watching my flashlight slowly turn on all by itself, I must say.
On Saturday, December 23, 2023 at 6:27:35 AM UTC-6, Jan Panteltje w=
rote:
=No, this is a watchdog. It must be separate from the Pi. If the Pi locks=
up - which happens a lot -Pis do not normally lock up, I am posting this from a Pi4 8GB
Not usually, no. I have dozens of them running 24/7, and most do not lock = >up very often, at all. It seems to be this software that is a bit wonky. = >As part of this recent project, I found out that the Pis running it reboot = >every few hours or so. Apparently, every once in a while, they fail to rec= >over.
The systems running this software vary a great deal. The one here at my ho= >use is a 3B+ with a 250G SSD and a 32G SD card. The one I am testing is ru= >nning on a Zero W with a 16G SD card. The only other thing directly attach= >ed is a 3.3 - 5V level shifter attached to pin 2 (GPIO 18), and of course t= >he po5V power supply.
It is online, posting this from it, runs many applications, a.o. firefox = >webbrowser,
This application is by design headless. If it finds any working IP ports, = >it announces their IP addresses over the audio port. If not, it brings up = >a default tether on 192.168.8/24.
There must be something wrong with your code or hardware.
It's not my code. Since it happens on all types of Pis in all sorts of sit= >uations I expect it is not the hardware, but I am investigating.
I have older Pis that had even longer uptimes, like almost a year until I=had to disconnect it when I moved house...
Hmm, this is interesting. All the Pis inside my house except three are pow= >ered via POE from a Cisco 3560-E. I didn't know this previously, but they = >all rebooted six days ago. Something must have burped on that switch. The=
three that are locally powered have been up 23 days, 203 days, and 557 day=
s, respectively. All of them are running software I wrote, incidentally.
But.. all run from an UPS.
Mains dips will kill a Pi, maybe that is it?
No, the one here at my house is on a battery that lasts over 48 hours when = >power fails. It isn't exactly a UPS, because it only supplies 12VDC and 5V= >DC. This is the board I use with it:
http://siliconventures.net/images/Raspberry%20Pi%20UPS%20Top.JPG >http://siliconventures.net/images/Raspberry%20Pi%20UPS%20Bottom.JPG
It is a Pi3B+ (needed for 5GHz WiFi), and it sits in a much larger enclosur= >e with a 5 port Ethernet switch, an FM transmitter, two 120mm fans, and a v= >ery large heat sink.
lørdag den 23. december 2023 kl. 14.03.40 UTC+1 skrev rhor...@gmail.com:
On Saturday, December 23, 2023 at 2:47:59 AM UTC-6, Don Y wrote:
A reset is insufficient?
Again, via what means? Telekenesis?
(What you've described is "Ensuring a restart from POST".)Well, OK. I don't care whether the Pi reboots from POST or from a saved image, as long as any issues are cleared.
Have you quantified how often this is *expected* to occur? TheTo you? No. The systems in question in past years failed once a week or sometimes more. Now they fail once every month or two. Some less, some more often? hey fail invariably if certain attached equipment loses power.
distribution of expected failure events?
And, determined that your remedy will "fix" the problem -- withoutNo. Again, so what? In fact, I know it *WILL* sometimes automatically recur.
it immediately reoccurring?
Occasionally the power has needed to be shut down twice or one a couple
of occasions twice before the Pi recovers.
The Arduino will take care of that.
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.
About 2 releases ago, they seem to have fixed that issue,
but if it hapens again, it happens. Nothing can automatically fix that in this arena.
and even those who use multiple Pis have a single master that runs all the rest.Presumably, the rPi adds value to theThat is an understatement. Many people run these systems entirely on a single Pi,
design so one would assume you would want it to be operational
more often than not.
When that is down, the entire system fails.
Most people at this point just put up with it, and go outside and unplkug
the Pi and plug it back in. Some shut off the Pi during the day, and restart it every night. That mostly eliminates the issue for them, but many, like me, run 24/7.
At this point, I am almost compelled to ask you, "Who died and made you Pope?The Arduino will also permanently disable the Pi ifThen either figure out how to alter the operating environment
the environmental temperature goes too high. A few times last year the >>>> temperatures in the case rose to over 70C.
or change the approach to the problem.
I will handle it the way I choose, thank you. In particular, this board supports a high speed fan and a Peltier cooler or other 12V, 5A cooling system. Tht has not been the most common issue, however, and in any
case has nothing to do woith my original question.
I thank you for your input, but I have already taken care of the other
issues in a reasonable fashion.
Or, as the Arduino seems to be TRUSTED to operate in thoseIt won't. It can't. Not even close. The software takes up at a >> bare minimum 4 Gigabytes.
extremes, let *it* do the work of the rPi.
Some deployments take more. > It runs poorly on a single CPU, if at all in some cases.
Sixteen Gigs of storage minimum is suggested and at least 512M of RAM.
The Arduino I am using has a total of less than 50 Kilobytes of RAM
total, and no external storage. It also has no Wifi and no Ethernet,
and both are required, as well as multiple USB ports.
It's amazing that a $35 SBC canhandle this much, but a $4 MCO won't, and that is no surprise.
You keep saying that. How? The Pi has no hardware reset, at least not up untilIf trying to ensure a restart or unconditionally deactivate the rPi, >>>>> forcing reset can also do the trick.
the Pi 5, and I am unsure of its' having one.
Are youj talking about the Pico? No, this software is Linux based, and runs on the Raspberry Pi models A & B and the Pi ZeroW. There is no RUN pin.How? The kernel has panicked (or something), and the Pi is locked up. OtherYou haven't indicated WHICH rPi you are using. Try bringing RUN to
than removing power, how am I to reset it?
ground.
https://static.packt-cdn.com/products/9781786467577/graphics/image_11_024.png
https://raw.githubusercontent.com/raspberrypisig/raspberrypisig.github.io/master/assets/images/rpi3runheader.jpg
https://i.stack.imgur.com/mwnCX.jpg
On Saturday, December 23, 2023 at 12:47:50 PM UTC-6, Don Y wrote: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?
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
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.
New to this field, eh?
If starting in 1972 constitutes "new", then I guess so.
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.
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 getthem to even support the Orange Pi or similar boards. 'Not that I blamer them.
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.
(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.
SBC.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
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?
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.
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>
"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.
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?
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?
resources to investigate and "fix the issue"? I thought not.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
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.
happens, involves many millions of dollars worldwide, but many hobbyists, such as I, indulge themselves in it.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
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 athat 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
"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 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?
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.
Wrong answer. Code *size* has no bearing on what a "smaller"
...
space was 64KB for code+data).
I repeat: Oh, brother.
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.
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?
(I designeda 1-bit wide DRAM array in a product
Yeah, we all know how wonderful you are.
people's employment is, and this personal project is. What, exactly, is your point? How does it relate to the questions at hand?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
Just out of curiosity, did you sneer at the developers of the Nintendo or Playstation?
platform would completely eliminate the entire project. 'Satisfied?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
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.
On Saturday, December 23, 2023 at 9:45:17?AM UTC-6, John Larkin wrote:
I designed an acoustic monitor system for MTF, the NASA rocket test
site in Mississippi, with the boxes up on telephone poles. The big
hazard wasn't temperature or humidity, it was the locals shooting at
them just for fun.
Well, in Mississippi - AKA Redneck Central, what else did you expect? :-)
We were accused of spurious low frequency oscillations, which turned
out to be the subsonic mating calls of bull alligators.
Well, in Mississippi - AKA Gator Central, what else did you expect? :-)
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 90:57:05 |
Calls: | 6,717 |
Calls today: | 1 |
Files: | 12,252 |
Messages: | 5,358,858 |
Posted today: | 1 |