I am creating a simple car dashboard cluster using a Raspberry Pi 4 with a 7in screen and using an 8 channel ADC hat and the GPIO pins for sensor input.
The GPIO pins will be used to read the state of various switches in the car using a step down converter so that when a switch is on 12v from that switch will be converted to 3.3V and send to a GPIO pin so it will be high.
The ADC will be used to read the values of various 5V sensors in the car like oil pressure, coolant temp etc.
The screen is a basic HDMI 7in screen with the Pi mounted behind it and I plan to 3D print a new gauge cluster bezel to fit everything into the stock location. I have a Mausberry power controller so that the Pi will turn on with key on and turn off again with key off. I have modified the Pi so it boots from SSD and starts up pretty quickly.
I have used simple Python programs to read the data from the ADC over i2c and the GPIO pins and output it, no issues there. I have found a nice Javascript based library called Justgage which looks like a great way to display my data in a simple HTML page and have designed my page layout with the various gauges and lights that will eventually have the data read from the ADC or GPIO pins.
What I need some advice on is how best to architect the overall solution, I have all the various parts but need to integrate them. I want to minimise the amount of software running on the Pi so it boots quickly.
At the moment when the Pi boots it auto loads Chromium and opens my page I have created but I need a method to be able to read the i2c and GPIO data and then refresh the elements in the HTML page. The Justgage library supports refreshing the data so that I don't have to refresh the page and would like a method to read the data every second or so and then call the Justgage refresh function.
All the examples of this sort of model I can see online use a webserver running on the Pi but as the screen is directly connected to the Pi I don't actually need a webserver and would like to minimise the amount of software running for reliability and boot times.
Sorry for the long first post and appreciate any guidance. Happy to post the HTML if that would be of any help.
Cheers
Matt.
I'm trying to get to work a raspberry pi 0 W and a pervasive display eink screen together.
But, every time when the screen refresh, it reboots the pi 0. Software works great on a RPi3 but not on Rpi0w with Raspbian Lite.
Here is the soft : EpaperDisplay
Here is the screen : Screen
There is no log in /var/log/messages, neither in /var/log/syslog. Every time it reboots, it's erasing history, logs ...
If this was a software issue, you would probably see something in the logs (or you'd at least see a kernel panic message on the console in the HDMI output if you have a screen connected there).
If you have nothing in the HDMI screen when the pi crashes, I'd suspect that the display is using more power than your power supply can provide. Try with a PSU with a higher ampere rating.
If a better power supply does not help, it can be that the display sucks too much 3.3v from the raspberry pi than the zero can provide. In that case you should try feeding the display via a separate 3.3v regulator.
I have a raspberry pi 3.
Whenever I want to shutdown, I always execute this command:
sudo shutdown -h now
And I will wait until only the red light is lighting. (And I always remove the power until only the red light is lighting)
But the problem is : every time I shutdown, I can't boot it again. I need to install the OS into the SD card again every time after I shutdown.
If anyone has the same problem ? Please help me. Thanks a lot.
I encountered this after my comment. As I mentioned, I perform the same steps to safely shutdown, unplug, and store.
Based on this page, you might be getting a corrupt SD card. Not sure if any of these apply.
https://www.raspberrypi.org/documentation/installation/sd-cards.md
If you are having trouble with corruption of your SD cards, make sure you follow these steps:
Make sure you are using a genuine SD card. There are many cheap SD cards available which are actually smaller than advertised or which will not last very long.
Make sure you are using a good quality power supply. You can check your power supply by measuring the voltage between TP1 and TP2 on the Raspberry Pi; if this drops below 4.75V when doing complex tasks then it is most likely unsuitable.
Make sure you are using a good quality USB cable for the power supply. When using a high quality power supply, the TP1->TP2 voltage can drop below 4.75V. This is generally due to the resistance of the wires in the USB power cable; to save money, USB cables have as little copper in them as possible, and as much as 1V (or 1W) can be lost over the length of the cable.
Make sure you are shutting your Raspberry Pi down properly before powering it off. Type sudo halt and wait for the Pi to signal it is ready to be powered off by flashing the activity LED.
Finally, corruption has been observed if you are overclocking the Pi. This problem has been fixed previously, although the workaround used may mean that it can still happen. If after checking the steps above you are still having problems with corruption, please let us know.
Hope that helps.
Cheers.
Ian
My question is, if I manage to develop some kind of bootloader and flash it (is it called that when you put a bootloader on an MCU?), and it works horribly, can it brick the MCU entirely, making it completely unusable, permanently?
The reason I'm asking is that I've been tasked to develop a bootloader for the STM32F407. Problem is, I don't know anything about bootloaders or anything of the sort, which means that I have a lot to learn.
I appreciate any answers, thank you!
In short no you cannot brick a microcontroller with a bootloader.
In the end bootloader is just a firmware and can be erased away using the programmer via SWD
Erase the flash and your controller is as good as new
In general, absolutely, I have a collection of bricked microcontrollers, every so often I get lazy and there goes another.
It is very specific to your microcontroller and family. For example, pin count is very important, as much bang for your buck as you can get, if your microcontroller relies on certain pins for in circuit (or even in a programming fixture) and those pins can be repurposed by software. For example jtag pins that can also be gpio pins. And your code for some reason uses them as gpio pins, AND the design of the chip is such that they cannot use the jtag interface when the chip is in reset, then you can get bricked.
Another very easy one is the pll or clocks in general. If/as you develop code to initialize the clock system (assuming you choose to do that, even if you use chip vendor supplied code) and you have a bug that switches the chip over to a clock that you have not properly initialized or isnt there, it might brick.
Now some chip designs, many, help you out in various ways. The AVR family in general there is a programming mode that happens while the chip is in reset or is related to reset such that whatever code is in flash cannot affect its functionality, you can have a bad board design, sure, but your code cannot prevent it from working. Another method is a "strap" a pin (or pins) that is dedicated to a boot function, set one way normal boot, tie it the other and it goes into an alternate bootloader. This is what you have on the stm32 boot0 and sometimes boot1 depending. that is your get out of jail free card for that chip family, if you brick your chip (pll/clock or mess up the SWD pins by using them as gpio), you "simply" change boot0 and it boots into an internal bootloader (which AFAIK you cant mess up) which is known to work. From that bootloader you can use SWD (chips not bricked now) or the bootloader itself (always serial, sometimes usb or other is supported). NXP similar deal. Atmel ARMs used to have (do have) SAM-BA now they really only support SWD, you can get some samba code and try to lock it into the flash, but way too easy to unlock and or trash that flash, so that is a fail on their part.
As part of your system design if you dont have one of these built into save you from bricking features (like boot0 on an STM32), then I recommend you add one. Very early code initializes a dedicated gpio pin as a strap into your software, if that gpio pin is pulled one way do a normal boot, if pulled the other then spin in an infinite loop or jump to some other guaranteed to not be buggy code. Not a complete guarantee that you wont build the project wrong and trash this code, but it at least allows you to develop your bootloader/project and not brick a tray full of parts/boards as you work through the peripherals that can brick it.
Note letting smoke out of the part is another way to brick it as well, and that can/does happen from time to time as well.
Lots of examples on how to boot an STM32, plus various code from ST that you can use as a starting point as well. (all of which is of various quality, you get what you pay for). Their docs are good, better than some of the competition, not difficult at all to boot and configure their peripherals, sometimes easier than trying to use a canned library. YMMV, you should try various solutions. But if you are new to this, bricking is highly likely, fortunately you have a chip that you cant brick so long as your board design breaks out the boot0 pin. For a prototype board for an STM32 I prefer to have a boot0 button and a reset button, just reset resets the chip and runs, hold boot0 and press reset and it goes into the bootloader. both have to be wired in properly with the right pull up or down as needed for this task. or a jumper works tie boot0 directly high or low then pop reset, costs you more time, but works.
Yes You can brick the Micro controller to never recovered state. I did this and i did it in STM32F427.
Bootloader is all about carefully selecting Clocks, Peripharals and Interrupts priority. if you do this, there are less chances to brick the controller. Also test everything before release your code as some companies wants to save proprietary information to be saved so they blow up the JTAG lines, the only way to program is via Bootloader and if it is not perfect, voila, you just bricked the controller.
I'm trying to run javafx8 application on raspberry pi model B. but keyboard input & mouse motions are seems bit slow. as a example I did it with one textfield on raspberry pi. when I typing to textfeild there is a delay. tableview also same. when I click on a raw. there is a delay between mouse click and selection. I read some blogs on internet that oraclejvm's performances are great on raspberry pi. Is it possible to run javafx controls without delay on raspberry pi? I done couple of optimization on raspberry pi. is it problem with javafx8 or raspberry pi performance?
As you are probably aware the pi does not like graphics very much. I have had the same problems (with swing rather than javafx). This can happen for multiple reasons. First check your OS version. I assume that your using raspbian which had a soft float version for a while. The armel version is way slower particularly in these areas. I would run apt-get upgrade and update first and if the problem persisted, download the latest version of the OS. You are correct that oracle jvm performance is quite good on the pi so the issue is likely to do with your particular setup.