|
Are microcontrollers in a way universal, in theory any program can fit into a microcontroller which means that the same microcontroller can fit the needs of any printed circuit board (since the program on the microcontroller can be adapted to meet the needs of any circuit board)?
I also have a question about car electronics. The car has various parameters, most of then need just to be displayed to the driver (vehicle speed, engine RPM, etc.) and it`s up to the driver to decide the amount & moment when change should be applied to those parameters. If the parameter display is digital I assume some kind of microcontroller is required to transform sensor data into humanly readable onscreen information. But my guess is that there are also parameters that are altered/changed after being read without driver intervention. In this later case the change comes from a microcontroller with a program designed to cause change. So basically a microcontroller can be used to either aid the display of information about various car components or actually change, at it`s own discretion, how those car components operate.
Are my assumptions close to how things are working in practice.
modified 10-Apr-22 10:50am.
|
|
|
|
|
I think you can assume that any microcontroller is Turing complete. So in theory, any microcontroller can replace even the most huge supercomputers. And every computer of any intermediate rank.
But then again: In theory, there is no difference between theory and practice, but in practice there may be.
Microcontrollers tend to have a very short paper tape. Clock speeds may be measured in kHz; memory sizes in kilobytes. (Well, there are as well microcontrollers running at quite a few MHz and addressing gigabytes, but some of them could deserve being called millicontrollers ...).
Microcontrollers are plain CPUs, but often packed with a lot of I/O circuitry on the chip, and some RAM / ROM / Flash - maybe all that the CPU needs in typical applications. Frequently, all that is needed is integrated on the chip, and it may be referred to as a SoC - "System on Chip".
For the car: Anything that can be read as a digital signal can be read by a microcontroller. Many microcontrollers also have one or more analog-to-digital (A/D) converters on-chip, so the signal need not even be digital outside the chip (but the handling of the reading is always done after it has been digitized). Anything that can be controlled through a digital signal can be controlled - call it 'changed', if you prefer - by a microcontroller. Likewise, microcontrollers may have on-chip digital-to-analog (D/A) converters, for (car or other) components that require an analog control signal. In a modern car, lots of components are not manipulated directly by the driver. The driver sends a signal to a controller requesting it to take the necessary steps to obtain some desired result, whether to start the engine, operate the ABS breaking system, or flash the blinkers.
This goes for almost all modern electronics: Today you hardly ever turn a potentiometer or press a switch to make a current flow. You still have dials, but they only serve as signal generators for a processor (/microcontroller) that in turn sends the "real" control signal to the component, possibly after some checking, adjustments, or reshaping.
Most likely, the rich set of I/O facilities typically integrated into the microcontroller makes it far better suited to such control tasks (guess what has inspired its name!) than, say, the typical CPUs found in desktop computers. A microcontroller usually runs a fixed set of software functions, and perform a fixed set of tasks - you boot it up with the software it will need, and do not add any more later. Knowing the tasks it will run, you will know how powerful it has to be, and you select a microcontroller accordingly. For battery driven applications you may also select clock frequency accordingly - the lower the frequency, the longer the battery life.
|
|
|
|
|
wrong forum
modified 4-Apr-22 13:06pm.
|
|
|
|
|
And you expect an answer to this without knowing anything at all about your hardware, the O/S it's running, whether it's a NAS, which vendor it is, or anything else that might be useful?
|
|
|
|
|
I am familiar with mdadm tool (Linux /Ubuntu) and so far I cannot see how to SIMPLY accomplish the task.
Is there another tool I can use ?
|
|
|
|
|
What happens when you try the --remove option?
|
|
|
|
|
I hope this question belogs here.
I have asked this many times and still have no real answer.
In multiboot ( all Linux) system "grub" has an option to boot (automatically) last used OS.
When "grub" menu is displayed such " saved " OS is indicated by asterisk (*) as
first character on the line.
However, UEFI gets into the act and FIRST option in "grub" menu is an entry
"*Ubuntu"
and it is marked , incorrectly , as "last saved OS used".
Allegedly, UEFi "boot firmware " also monitors last SUCCESSFULLY used OS...
No matter how often I change "grub" options - and then update grub - the menu ALWAYS set the asterisk next to the "Ubuntu" label.
It only works when I install new , clean Ubuntu using ISO.
...and I do change the OS using other then "Ubuntu" option in "grub" menu...
|
|
|
|
|
I have done this successfully in the past using the edit feature on the grub menu. As far as I am aware UEFI only controls which device the system boots from.
|
|
|
|
|
It does not help me if it works for you.
I need somebody to tell me why it works the way it does on my hardware.
|
|
|
|
|
Member 14968771 wrote: I need somebody to tell me why it works the way it does on my hardware.
And how are we expected to do that, given we have no access to your system?
|
|
|
|
|
|
I did look at the link, it still does not help finding the relations between "hardware" - firmware setting when multiple OS is involved. I am including part of copy of the most recent OS upgrade
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.13.0-40-generic
Found initrd image: /boot/initrd.img-5.13.0-40-generic
Found linux image: /boot/vmlinuz-5.13.0-39-generic
Found initrd image: /boot/initrd.img-5.13.0-39-generic
Found linux image: /boot/vmlinuz-5.13.0-37-generic
Found initrd image: /boot/initrd.img-5.13.0-37-generic
Found Ubuntu 21.04 (21.04) on /dev/sda2
Found Ubuntu 21.10 (21.10) on /dev/sda4
Found Ubuntu 21.04 (21.04) on /dev/sda5
Found Ubuntu 21.10 (21.10) on /dev/sdb22
Found Ubuntu 21.04 (21.04) on /dev/sdb23
Found Ubuntu 21.04 (21.04) on /dev/sdb25
Found Ubuntu 21.04 (21.04) on /dev/sdb3
Found Ubuntu 21.04 (21.04) on /dev/sdb6
Found Ubuntu 21.10 (21.10) on /dev/sdc17
Found Ubuntu 20.10 (20.10) on /dev/sdc2
Found Ubuntu 21.04 (21.04) on /dev/sdc3
Found Ubuntu 20.10 (20.10) on /dev/sdc4
Found Ubuntu 21.10 (21.10) on /dev/sde10
Found Ubuntu 21.10 (21.10) on /dev/sde30
Adding boot menu entry for UEFI Firmware Settings
done
q5@q5-desktop:~$
The upgrade was performed on /dev/sde31 partition , I should be able to manually set the /dev/sde31 grub default file to activate "save last OS used " .
Most of these "upgrades " wipe out this settingn !
I have done that multiple times and it never works. The "grub menu" always select "ubuntu" and in general runs the first menu - such as /dev/sda2.
There are multiple "ubuntu" files in "setup" and I really do not know how to access these "ubuntu" files to determine which one is actually used. Since "ubuntu" selection in grub menu is BEFORE the system is active I cannot simply "cut and copy" the "grub menu" to post here . Anybody who uses multiple OS system (ubuntu) will be able to understand this . Since I have never run single OS my guess is "grub" menu should not show on such system...no need for multiple OS selection...
|
|
|
|
|
Sorry, I cannot offer any suggestions beyond what is in that link. But I am a little concerned as to all those different devices in use on your system. Maybe it's time for a complete reinstall from clean.
|
|
|
|
|
The problem is - as can be seen - I have done the clean install (of OS) many times and the "select last used OS" only works on clean ISO. I do not like new installs because I have to start all over to install all the "support" software I am using. I do manage to keep my software stuff most of the time...
I really need someone to tell me about these "ubuntu" files and how they fit into OS loading process. They seems to reside on different HDD and I do not know how "UEFI " setup manages them.
|
|
|
|
|
Sorry, I have use ubuntu in multi-boot situations a number of times and have never encountered anything like the situation you are showing. I can only suggest you find a specialist Linux support website where you may find someone with a deeper knowledge.
|
|
|
|
|
1. can hci_get_route return anything but 0 or -1 (error) ?
2. does hci_open_dev returns
"socket" or
"device descriptor" ?
3. as coded in an example
can hci_open_dev return 0?
device_id = hci_get_route(NULL);
if (device_id < 0) {
perror("hci_get_route");
return 0;
}
device_sock = hci_open_dev(device_id);
if (device_sock < 0) {
perror("hci_open_dev");
return 0;
}
|
|
|
|
|
|
I do not want to abuse my posting privileges here - but
I need another terminology answer
I use hcitool to "scan for nearby Bluetooth devices " .
In my logic - to physically scan remote devices a connection has to be made.
Now Bluetooth devices as such are also "paired " and or "connected ".
To apply my logic - right or wrong - before hcitool can "scan" should it "pair " AND then "connect " FIRST?
Yes , I need to look at the hcitool source code and hopefully it is commented enough to support my logic.
I actually was hoping to find somebody who uses hcitool option "cc" - connect , but I better heed my own suggestion and read the source code first...
cheers
:
|
|
|
|
|
That's easy enough to test. Turn on a bluetooth device. Do not pair or connect, and run a scan. I think you'll find that the scan reports the device presence.
My expectations are:
scan - find any nearby device with bluetooth receiver turned on - may or may not report devices that are paired to other servers and not soliciting for connection
pair - establish a connection to a scanned device that is soliciting for a connection
connected - a pairing has been established and the server can communicate with the device.
Keep Calm and Carry On
|
|
|
|
|
My primary reason for ditching "brand X " Bluetooth API was its lacking of resetting the discovered Bluetooth devices.
I am now using "hcitool scan flush " which does reset the data and then does
real scan.
The "hcitool" command responds with a message "Scanning" and takes up to 30 seconds to finish.
There is yet another issue here - sometime it gets stuck in "scanning" and only reasonable way to recover is to reboot the system...
( The API I am using monitors the scanning time and can be adjusted , I have not look into that , not yet. )
That is silly and unacceptable.
How safe or dangerous would it be to stop and restart the
Linux Bluetooth service itself ?
|
|
|
|
|
Why should that be dangerous? Windows updated here and there was a power failure.
(Do not turn of your machine?)
It just kept working.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
No, the system is still ruining OK so I just switch to "terminal " and run "sudo reboot" - a "short" version of plain reboot.
|
|
|
|
|
Member 14968771 wrote: How safe or dangerous would it be to stop and restart the
Linux Bluetooth service itself ?
It should not affect the running of the Linux system at all. It might leave any connected bluetooth devices "orphaned", I.E. with a connection that the kernel doesn't know about, but I really do not know. You almost certainly can't damage the linux system beyond needing a reboot to get back to where you were, so if I were you I'd try it and see what effect it has. In particular I'd look to see if currently connected devices keep working, and if the stuck process recovers quickly after the restart. I suspect that restarting the service won't affect the stuck hcitool process. It probably has all it needs to do its work, so restarting the bluetooth service won't affect it. You should probably take a look at what hcitool is doing when its stuck - it may be a bug in the process, which you could report to the developer, or it may be due to some bluetooth device not properly implementing the discovery protocols, which leads to problems, or, well, anything!
Keep Calm and Carry On
|
|
|
|
|
All sounds reasonably safe. I am sure you are correct - I should look into how hcitool scan is implemented.
This is something I will never understand - Bluetooth is "implemented " in Linux kernel.
It uses "blueZ" "stack"... "blueZ" source code is "available" in several versions and ALL of them are lacking code comments or function descriptions ... basically a code nobody maintains...
My Linux version runs a "bluetooth manager " and my QT implementation of "blueZ" library interact with this flaky manager - perhaps by using the Linux " blueZ stack "...
That is why I asked "Bluetooth service " ....
BTW
can you tell what the hell is "stack"?
I had some fun in haystack(s) in my youth...
|
|
|
|
|
A "stack" is the set of programs and/or system services needed to supply a given end-user (in this case) service.
As I understand it, for bluez there's
User programs : e.g. hcitool
System software : e.g. whatever system processes are needed to monitor/provide bluetooth services
System libraries : e.g. libbluetooth this provides interfaces for both system and user programs
Kernel module : e.g. bluetooth module, which provides the kernel side implementation details
As you can see, this forms a "stack", with each layer needing services from the layer below it to provide the services it needs to the layer above.
Keep Calm and Carry On
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
