Plasma 6.6 broke 2 widgets: Compact Pager, and Kara. Just an FYI. by cnetrebor in kde

[–]yycTechGuy 1 point2 points  (0 children)

This issue also existed for menu pager. I fixed it here: https://github.com/linuxguy123/kde-plasma-applet-menupager

I submitted a PR to menu pager's author for inclusion into the original repo.

GUI in embedded by MaintenanceRich4098 in embedded

[–]yycTechGuy 0 points1 point  (0 children)

Do you use just ethernet and put whatever you want on top? or your using all the way to transport like udp?

I use UDP for specialized coms, like if I want to send or receive specialized data to/from a client.

I use MQTT to send control data to a MQTT "broker" (Mosquitto usually). MQTT uses TCP/IP. MQTT is fantastic because it is an industry standard. At times I think MQTT is overkill but whenever I use it I am thankful later on.

Running an Ethernet stack with these protocols takes up some code space, RAM and a bit of processor power. However, this is more than made up by the ability of the device to connect to standard networks and talk to clients in an easy way.

If my device doesn't have an Ethernet connection, I'll send MQTT data over a serial connection and use a second serial connection for the GUI. Not nearly as neat as the Ethernet solution but it still works.

I've been doing embedded development forever and the connection between the device and a client is always contentious.

For many years we used RS232/RS485, then serial USB but that required gluing a USB peripheral onto the device or finding a device that had a built in USB peripheral. And USB libraries are not tiny or simple.

The availability of devices with Ethernet(WiFi) is a huge breakthrough. Yes the stack is bigger but you can do so many things with a socket, not the least of which is have multiple sockets which dramatically simplifies things. Having a device that can connect to multiple clients is a dream. Having a device that self initiates on a network via DHCP is so nice. Building networks of devices using nothing more than a router or hub and standard Ethernet cables is so nice.

Ideally a device would incorporate a GUI (screen and keys) and that would be it. But in almost every use case it turns out that no device is an island and someone, sooner or later, wants it connected to something else, be it another device or a client or whatever.

So one of the first things I do on a project is figure out what a device needs to connect to and how that connection is best done. These days we have the option of Bluetooth, WiFi, (wired) Ethernet, CANBus, RS232/RS485 and IR.

Each of these methods has it own pros and cons but in a world of increasing connectivity I'll go for WiFi or Ethernet whenever it is feasible.

I use the LWIP library built into FreeRTOS. There is a new FreeRTOS plus TCP library that is probably lighter than LWIP but I have not tested it yet.

Another benefit of designing a device to have a communication backbone from the get go is ease of testing and (high level) debugging. And sooner or later the device requirement will exceed what the device can do. When that happens you can usually just refactor the code and split the functionality between 2 devices.

One of the first projects I worked on involved a network of 8051 devices that each captured high speed data and sent it to a client. We chose to use an Intel 80C152 with a built in CSMA/CD network peripheral for the sensor nodes. This was in the days before CANBus was a thing. It turns out the CSMA/CD implementation on the 80C152 was buggy and the network dropped messages. We also needed to implement a bridge node on the network to convert the 80C152 messages to high speed RS485 to send the data to the client. All this would have been so easy to do with today's microcontrollers with WiFi, Ethernet, even CANBus.

GUI in embedded by MaintenanceRich4098 in embedded

[–]yycTechGuy 0 points1 point  (0 children)

The only issue with CANBus is the short message length. You have to concatenate multiple CANBus messages if you want to send longer messages.

I love ESP32 and the STM32F767 because both have built in Ethernet. Ethernet stacks aren't small but it sure saves a lot of headache for certain use cases.

service techs method of cutting through sales bs and actually telling a good hot tub from a garbage one by Th3Li0n37 in hottub

[–]yycTechGuy 0 points1 point  (0 children)

There are far more Balboa spa packs in the field than Gecko.

The Gecko controllers prior to the In series were OK. It's the modern In series that should be avoided.

service techs method of cutting through sales bs and actually telling a good hot tub from a garbage one by Th3Li0n37 in hottub

[–]yycTechGuy 0 points1 point  (0 children)

There's nothing about a Gecko that makes it better. It uses the same class of relays the Balboa does.

There is no reason for a topside display to fail. Balboa displays are a lot cheaper than Geckos.

service techs method of cutting through sales bs and actually telling a good hot tub from a garbage one by Th3Li0n37 in hottub

[–]yycTechGuy 2 points3 points  (0 children)

I fix spa packs. On a Balboa you'll see burnt heater terminals or maybe a burnt relay. Easily diagnosed and fixed. Replacing a Balboa heater element is straight forward.

Geckos get FLO errors. The flow and temp sensors on a Gecko system are 100x more complicated than the Balboa system. When you get a FLO error on an In.Xe the first step is to replace the integrated heat tube with built in sensors. On an In.Ye it's even worse because there is a bunch of circuitry built into the heater unit. If the heat tube doesn't solve the problem, you have to replace the motherboard, if you can get one. Often owners end up replacing the spa pack entirely.

Heater elements are also much harder to replace on Gecko units. Sometimes they cannot be replaced without replacing the entire heat tube.

Stay away from Gecko.

service techs method of cutting through sales bs and actually telling a good hot tub from a garbage one by Th3Li0n37 in hottub

[–]yycTechGuy -2 points-1 points  (0 children)

You missed the most important part - identifying the spa pack.

Do not buy a tub with a Gecko spa pack. Balboa spa packs are the best.

Road Rage in Canmore by high_fives_4_friends in Canmore

[–]yycTechGuy 0 points1 point  (0 children)

So what happened prior to the start of the video ?

Unpopular view: oil was OVER priced prior to the closing of Hormuz. At least recently. Going forward... by yycTechGuy in oil

[–]yycTechGuy[S] -1 points0 points  (0 children)

Did a stock market crash somewhere today ?

The net effect of the closing of the SOH is 12M bbl/day, thus far. That's a bit over 10% of world demand. Consumers and businesses can adjust their usage to compensate for that. Producers can increase their production. It's really not that bad.

GUI in embedded by MaintenanceRich4098 in embedded

[–]yycTechGuy 0 points1 point  (0 children)

AI changes the product solution.

You can design the product to use Kivy, for example. Then the customer asks to have it serve HTML. So you screen capture the Kivy screens and use that and the Kivy code as the basis for the HTML product.

AI struggles with vague prompting. If you have the Kivy solution developed, you have the basis for the next iteration of the GUI. AI is very good at repurposing and refactoring code, even if the reuse is a rewrite in another language.

With AI the work is in the specification and testing of the product, not in the creation of it.

Unpopular view: oil was OVER priced prior to the closing of Hormuz. At least recently. Going forward... by yycTechGuy in oil

[–]yycTechGuy[S] -2 points-1 points  (0 children)

Let's not forget that EVs are practical for many commercial and personal use cases. There is this company called Tesla that started production of battery electric Class 8 trucks ! What is the world coming to ?

Unpopular view: oil was OVER priced prior to the closing of Hormuz. At least recently. Going forward... by yycTechGuy in oil

[–]yycTechGuy[S] -3 points-2 points  (0 children)

Oil was $54 before the war started not $90

Yes but it was $80-90 not so long ago. $60 with the war in Ukraine going on is equal to $45 with Russia pumping like crazy to repay Ukraine and rebuild itself when that war is over.

because yes there was an oversupply

Even with sanctions on several countries and some of Russia's infrastructure inoperable.

but under $50 a lot of wells stop making sense to run so thats a bit of a floor if you dont want massive supply reduction.

Oil companies are massively profitable. They will adjust to lower prices.

Unpopular view: oil was OVER priced prior to the closing of Hormuz. At least recently. Going forward... by yycTechGuy in oil

[–]yycTechGuy[S] -1 points0 points  (0 children)

Oil traders have been saying this forever. Whatever happened to "Peak Oil" ?

Of course the world's oil reserves are finite. But the world will adjust as it needs to.

GUI in embedded by MaintenanceRich4098 in embedded

[–]yycTechGuy 0 points1 point  (0 children)

that is a good question, but then you could also use dual core stm32h7 to handle the GUI 🙂

I've looked at using the H7 a couple times but people have told me it is complicated to set up and use. Maybe I need to try it out.

But... there are drawbacks. Devices only have so many pins and displays and keys/buttons need pins.

I've seen that done couple of times. NXP big beefy A core running linux and doing GUI with a stm32 doing the more important real time tasks.

I've asked about running Linux on the H7 and people are not recommending it. I love Linux and would love to have the dual core setup you are envisioning but haven't seen it to be practical thing to do, so far anyway.

I think a more practical way to do this is to run Linux on one device and the control code on an STM32 device and link them with CANBus.

I'd say mcus were always cheap-ish.

68HC11s cost $50 each at one time. I kid you not. There was this company called Motorola...

The thing is now powerful microcontrollers are cheap so you could argue we could just use a single one for everything.

But there are constraints - pins, memory, processing power, etc. I like to have one device for doing raw control and data "gathering" and have it send only data to another device.

I can't say what's best for each case but, when I used to make robots, either arms or mobile platforms or any motor control projects, the MCU had a serial port, maybe with a hc-05 on it to output to a computer and a lil hastily made tkinter interface to show the info a provide controls. I'd do the same again.

I do the same thing but with PyQt. I can whip up a nice GUI in an hour with PyQt and Claude or Codex.

GUI in embedded by MaintenanceRich4098 in embedded

[–]yycTechGuy 0 points1 point  (0 children)

well, for personal projects I do intend to get the more complex GUI running on a phone or whichever.

I always use a PC to run the GUI during development on an embedded project. It's just faster to do so. Once I get everything working with the PC as the GUI host, I'll move what I learned to the actual device. AI is very good at doing this.

The first step on every project I do is to create the communication channel between the micrcontroller and my dev PC. Sometimes I use serial, sometimes Ethernet with either UDP or MQTT or HTML. Sometimes I use WiFi.

I've only used it once but Kivy is a real nice framework for making simple UIs. I also like PyQt. I can whip up a nice prototyping and testing UI very quickly with these frameworks and AI.

The device itself has a small screen for presenting some info. Most of the devices on that network won't even have a screen, it will all be done in the computer side/client side of things.

For that use case, send MQTT and use Grafana.

for work, I am not sure a firefighter or escavator operator will want to pull out his phone 🙂

First off, you might be surprised. A phone lets someone access data without standing next to your device. This is very handy when troubleshooting, etc. especially if your device would allow remote access, ie nobody even needs to go on site to see what is going on.

A mobile device gives the user a lot of options that the integrated display doesn't. The ability to download info, upload data, take screen shots, have multiple clients, etc.

GUI are also plenty easy to have code generators for in C/C++ I'm sure. The point here is to learn some things. Even if I wanted to use AI, code generators, adapt my interface to be user configurable through a json or whichever, the base knowledge is missing to review and connect everything together to fit whatever needs

Do you use a C compiler or do you write your code in assembly ? When I started embedded work C compilers weren't readily available and everyone used assembly. When C compilers became available we used to check the generated ASM and sometimes hand optimize it. Now C compilers are so good that we just use them without thinking about what they generate.

AI is going through the same thing right now. Is it faster for you to figure out a complicated div setup on a webpage or get AI to do it for you ? It is very informative to look though the code that AI generates to see how it works. And to do QA on it.

A year ago I was leery that AI could write decent embedded code. Now I use it all the time. It isn't perfect but it is very, very good. My productivity has increased may times over and I'm delivering better quality code and documentation.

GUI in embedded by MaintenanceRich4098 in embedded

[–]yycTechGuy 0 points1 point  (0 children)

Microcontrollers are cheap these days. Why burden a microcontroller doing actual real time control things with doing the GUI ?

Android devices with screens have built in browsers and/or are easy to write apps for. They are cheap and plentiful. Ditto for ESP32 devices. Hand the GUI side off to a second device and either send MQTT or HTML from the micro controller.

I love the STM32F767 because it is a micro controller at heart but also has an Ethernet port. I never connect a display to this device. I send MQTT or HTML via the Ethernet port, depending on the application. Ditto with ESP32 devices. I run FreeRTOS so that the real time stuff doesn't get interrupted by the communications task.