I have a problem using Raspbery Pi hardware and Simulink, shown by the pictures below.
I'm tring to control an LED and GPIO pin on the Raspberry Pi.
I click Build, Deploy & Start. It works.
But then I click Monitor & Tune for monitoring signals.
It produces an error which I cannot find a solution for.
I tried different versions of Matlab but got the same error.
My hardware settings are just like in this link: https://www.mathworks.com/help/supportpkg/raspberrypi/examples/communicating-with-raspberry-pi-hardware.html
In addition I tried to click connect on external mode panel and the result is the same, the error is same.
Do you have any suggestions?
[Cross posted from Matlab Answers].
Check your matlab search path. You have the support package 2019a and 2019b on your search path. Add only the one matching your matlab version.
Related
I since a few months, I have been using a Hyperpixel 4.0 Touchscreen with my Raspberry 3B+ without any problems. Since a few weeks i use my touchscreen with the Raspberry Pi 4 Compute module and mounted both on my own designed PCB. Unfortunately, I’m facing some difficulties with the Touch function of my Hyperpixel 4.0. I have no clue how to solve these problems because the circumstances, which cause the fault don’t make sense to me.
Which System do I use?
Hyperpixel 4.0 in combination with Raspberry ComputeModule 4 with 2GB RAM and 8GB onBoard eMMC. Both is mounted on my custom PCB, which is supplied with 24V, stepped down by an «APP63300WU-7» Step down converter, which provides 3A # 5.1V continuous output. The measured Voltage over 2 Days of measurement is a maximum of 5.2V and a minimum of 5.05V. The software ist the latest Raspbian.
What error is caused?
I have been running a GUI on my Raspberry Pi. I have one Page on which i have three sliders for changing brightness of my room light, colortemperature and one slide is to regulate the speed of some fans. Everything works fine in darkmode, but if I change to lightmode and touch the screen for about 1.5 seconds, the touch- function hangs up. My GUI doesn’t move anymore and I have a still image. I know that it’s only the touch function beacause if I plug in a keyboard and mouse, I can open for example chromium or other stuff without problems. With «i2cdetect »-command I can detect the Goodix GT911 driver on Address 0x14. Even if the touch has hung up, i can detect the Goodix GT911. I know that the address should probably be 0x5D but I thought it isn’t necessary to care about this problem as long as it works. After a reboot, the touchscreen works fine again until i use the lightmode of my GUI. Interesting to mention is, that i can click a thousand times for around 0,25seconds and no problems occur. But if I touch the screen permanently for around 1,5seconds, I instantly get my above described problems. Generally considered, this problems seems very strange to me and it doesn’t behave like any physical law i know…
On the first view, the error seems like a software issue ? Hear this!
If i use the official «Compute Module 4 IO-Board » to mount my Compute Module and Touchscreen, I don’t get the issue at all… My actual designed PCB ist the 2nd version. On the 1st version It also worked fine without any problems. The only differnce between version 1 and 2 is the wiring, which I tried to improve on the 2nd version and viewer parts which I only put on my 1st version to evaluate some functionalities like ethernet or 2nd I2C-Bus, which I’m not using on my 2nd version. The wiring did not change between these two versions, i only tried to increase the distance between the GPIO-traces to improve signal integrity.
So it seems like a hardware problem? But why does the GUI work fine in darkmode? I don’t have any explanation to that.
What did I do to narrow down the error?
I flashed a new image on my Compute Module and also used another Compute Module, Custom PCB and touchscreen as well, but without any success. As far as I experienced, the issue is only caused on my GUI and not on any other websites or images, etc. An interesting thing was the interrupt line, which is typically only drawn to 0Volts if the touchscreen gets touched. After the touchscreen hung up, I measured 0,084V on that line and as long as I touched the screen, this voltage rised to about 0,2V, which for me seems also like a strange behaviour. I also checked the «dmseg» file and got some entries for failed i2c tests of the GoodixGT911. I also tried the github fix for the swapped i2c address, but without success. I used the command «git clone GitHub - pimoroni/hyperpixel4: Driver for the Pimoroni HyperPixel 4.0" Touchscreen Display -b pi4-i2c-fix » for that.
What do I try next?
I dont have any clue what to do next. My only solution in mind, is to undo the «improved» wiring of my 2nd PCB to get as close as possible my first PCB version.
Conclusion :
I really need help and hope, someone can do me this favour. I’ve never found my described error behaviour in any forum. Are there any other usable forums for problems with the Hyperpixel 4.0? Let me please know.
Update:
I tried to reproduce the errors and specify the error source. As above mentioned, the touchdriver hangs up on lightmode (nearly every pixel on rgb(255,255,255)). If i change the color in lightmode to around rgb(245,245,245) the error does not occur. I also noticed that there are two flatband cables on the Hyperpixel 4.0: One for displaying the image and another for the whole I2C-Communication to the touch driver. I plugged out the one for displaying the image and got no problems at all. Even if was theoretically in lightmode(if display would have been on). The touchscreen worked fine and transmitted everyting flawless:
Conclusion on my Update: It seems as the rgb(666) datalines for displaying the image on the screen cause some problems on the I2C bus. I also checked the bus and the power supply with an oscilloscope but I haven't seen any unusual behaviour in any case. Voltage ripple was around 200mV Peak to Peak and the I2C-Datalines rised and fell really sharp
I still need help from you!
Thanks, Manuel
I am trying to set up vs code currently to work with my a-star 3.3V module. I have code already working that I have uploaded successfully on the Arduino IDE, but I run into an error (see below). I have done some googling and wasn’t able to find a solution that worked, as most of them involved ensuring the board and ports were configured correctly, but I have already done that (to the best of my knowledge).
[Error] Uploading sketch ‘tuya-a-star.ino’: Exit with code=1
I have included some of the different things below so you can see what I mean, I am hoping I have missed something small here. The correct board and version is also selected as is the correct port. I have also selected the Arduino type for the C/C++ configuration.
arduino.json file
{
“configuration”: “version=8mhz”,
“board”: “pololu-a-star:avr:a-star328PB”,
“output”: “…/ArduinoOutput”,
“programmer”: “pololu-a-star:stk500for328PB”,
“sketch”: “tuya-a-star.ino”,
“port”: “COM4”
}
I'm running Quartus Prime Lite 16.1 on Ubuntu 16.04 and I want to start using Models-Altera, but when I click on "Tools"->"Run simulation tool"->"RTL simulation" it shows me a pop up window saying that I need to point to my license (please see the picture attached), but before running the Quartus setup installation I specifically selected the Models free version.
I had a similar problem with Signal Tap Analyzer, also requesting pointing to a licence or some similar wording. Maybe the solution applies also for the RTL simulation.
The solution that worked for me was to go to the Tools->Options->internet connectivity and enable “talkback options”.
I had found the solution here: https://mil.ufl.edu/4712/docs/SignalTap_Tutorial.pdf
I'm tasked with upgrading a lot of legacy models and scripts made in an older version of Matlab/Simulink and have it running smoothly in R2018b. Among other requirements I'm not allowed to have any warnings issued upon execution of .m scripts or Simulink models. This is generally tedious but straightforward to comply.
However, there is a specific warning that Matlab does not give me hints on possible sources:
Warning: MATLAB has disabled some advanced graphics rendering features by switching to software OpenGL. For more information click here.
The link opens the Matlab Help page titled Resolving Low-Level Graphics Issues, which describes issues I'm not finding (or at least not noticing)
I do note that many scripts I run create and close figures, but this is done procedurally. I haven't been able to associate this warning with some specific function or feature. I'm working on a Windows Server machine.
Does anyone have an idea of how to narrow down which kind of function os Simulink block could cause this warning?
As datenwolf and Ander point out, the first thing to try is to update your drivers. If this doesn't work, and your only problem is that you're getting the warning but your graphics still render fine, then you have two other options to try.
First, you can simply modify your OpenGL rendering preferences using opengl. The following will set your preference to 'software' and save that setting for future sessions:
opengl('save', 'software');
Alternatively, you can just try to suppress that particular warning message. After you get the warning, issue this call to the warning function:
w = warning('query', 'last');
The w.identifier field will give you the ID for the warning message, which I believe will be 'MATLAB:hg:AutoSoftwareOpenGL' in this case. You can then add the following line to your startup.m file so that this warning is suppressed every time MATLAB is opened:
warning('off', 'MATLAB:hg:AutoSoftwareOpenGL');
Install the original vendor drivers for your GPU. The drivers that are installed by Windows by default lack full OpenGL support. Download the driver package directly from the website of Intel, AMD or NVidia, depending on what GPU you have.
If you don't have GPU, for example when running in a Virtual Machine, then you can not avoid that warning, because then Matlab has no other choice than falling back on the software OpenGL implementation that it ships with.
There's nothing you can do about that, other than making sure, that the system you're running Matlab on, does have proper OpenGL support!
It took me a long time to get it, so I'll put you here in case it helps how I managed to activate openGL in Linux:
If you haven't already (it's common for other problems), rename libstdc++ library from MATLAB:
mv _YOUR_MATLAB_ROOT_FOLDER_/sys/os/glnxa64/libstdc++.so.6 _YOUR_MATLAB_ROOT_FOLDER_/sys/os/glnxa64/libstdc++.so.6.bak
Create this link: sudo ln -s /usr/lib/x86_64-linux-gnu/dri/ /usr/lib/
Run export MESA_LOADER_DRIVER_OVERRIDE=YOUR_DRI_DRIVER;matlab -desktop -nosoftwareopeng
Your DRI Driver will be a file from /usr/lib/dri, removing "_dri" (in my case was the "radeons" driver for an AMD Vega graphic card.
Run MATLAB from a terminal using: export MESA_LOADER_DRIVER_OVERRIDE=_YOUR_DRIVER_HERE_;matlab -desktop -nosoftwareopengl. YOUR_DRIVER_HERE should be your driver, radeonsi in my case.
Check openGL with info = rendererinfo
If something went wrong, you will be able to see in the terminal which library was responsible. Executing 4) and 5) I was discovering what I had to correct, you can do the same if you have another problem that has not appeared to me.
So that it always runs correctly I put export MESA_LOADER_DRIVER_OVERRIDE=YOUR_DRI_DRIVER at the beginning of the script that runs matlab (_YOUR_MATLAB_FOLDER/bin/matlab), although I suppose it can also be set as an environment variable.
I hope this has been useful to you.
I'm currently developing a mex-file with CUDA functionality to be used in MATLAB. When I'm doing something wrong (e.g. wrong pointers or something like that), MATLAB always crashes (windows prompts me to end, send the report for mathworks or attempt to continue). Is there a way to prevent this from happening? It's really annoying to develop like that but as you probably know yourself: Hardly anybody can write perfect code without 'trial and error'...
Thanks so far!
As far as I know, there is no way to prevent Matlab from crashing on a mex bug. But you may be able to attach a debugger to the Matlab process and step through the code.
I know for a fact that this works if your code is in an external dll that you load into Matlab. I am not sure if this works with mex files.
From the Matlab MEX file page,
mex -g yourmexfile.c
if you're not doing this already.
You can debug Matlab mexfiles including CUDA codes using Visual Studio and NVIDIA Nsight for Visual Studio by the following procedure.
Define the system environmental variable NSIGHT_CUDA_DEBUGGER and set it to 1.
Launch Matlab.
Launch NVIDIA Nsight. Right click on the Nsight Monitor icon on the taskbar and select Options. Select the CUDA tab. For the option Use this Monitor for CUDA attach, click the drop-down menu and select True.
Open your project in Visual Studio, set the breakpoints and compile it.
Go to Tools -> Attach to Process.
Click the drop-down menu next to the Transport field, and choose Nsight GPU Debugger.
Ensure that your host machine name is listed in the Qualifier field.
Note that this field is blank by default; you will have to manually select your machine name the first time this dialog is opened.
When you enter your computer's hostname in the Qualifier field, a list of available processes will appear in the dialog box. Processes that may be attached with CUDA usage will appear with CUDA listed in the Type column. If a process is grayed out and CUDA is listed in the Type column, it is already being debugged, so it is not attachable. Processes that are grayed out without CUDA in the Type column indicates that it has no CUDA usage in the process to be debugged. Processes that may be attached will appear normally, and the Attach button will be enabled.
Ensure that Matlab has CUDA in the Type column and select it.
From the Matlab command line, invoke the function defined in the CUDA mexfile. The execution will then stop at the first breakpoint and debugging could start.