Yes,
I confirm, the provided cable is flat, which means the pins are connected 1-1
I crimped a cable according to the pinout described in the documentation, and I can confirm the I2C and the touch controller now are working!
Thanks & BR,
Michele
Yes,
I confirm, the provided cable is flat, which means the pins are connected 1-1
I crimped a cable according to the pinout described in the documentation, and I can confirm the I2C and the touch controller now are working!
Thanks & BR,
Michele
Hi,
Hi everyone.
On an armstonea9r2 I'm unable to let the Resistive touch kit 2 (SINTF-ADP-RTI2C) works: just wondering if I'm missing something.
I've connected the 6 pole hirose connector to the board.
I've enabled the SX8655 touchscreen controller, uncommenting the following line in the armstonea9r2dl.dts device tree source script:
define CONFIG_ARMSTONEA9R2_4WTOUCH_SX8655
I've successfully rebuilt the device tree and deployed it on the board, but the controller doesn't works.
dmesg displays the following error:
I've decoded the actual devicetree binary file generated in the output/images folder (with the dtc -I dtb armstonea9r2dl.dtb command and the following fragment is generated, that seems correct to me:
If I try to probe the i2c-1 bus (that I've checked being effectively mapped to i2c@021a4000) through the i2cdetect 1, the controller address won't shows up (should be 0x48):
I've checked that 3.3V is delivered to the touch board (pin 1 & 6).
I've also tested the i2c port by connecting a different controller (STMPE 610), and through the i2cdetect and i2cdump / i2cget I'm able to get data from the bus, so I assume that from the armstone side, the i2c is working (same interrupts, but different i2c address, namely 0x41)
Am I missing something? Is there something else I can try?
Looking forward for your kind reply,
BR
Michele Bucceri
Hi,
I tried with different sample rates and setting also the environment variable, as suggested by the above post, but the applications still hangs when opening the audio stream within the PortAudio library.
Also tested with the test programs provided with PortAudio and the behavior is the same.
The only way to make it working with PortAudio is to change the streaming mode, switching from the unblocking mode to the blocking mode; it seems there is some problem in the thread management within the PortAudio library, but I admit I have not enough knowledge to fully understand what's going on.
Now I'll try to update our app and feed the audio stream using the blocking methods...
Michele
Great,
now it works!!!
From aplay -L the device is not listed, but specifying the BT MAC address of the device aplay stream on the headphones.
Moreover, adding the .asoundrc configuration file in the home directory, the device -if connected- became the default device.
Last thing to do is to have our application working: it gets stuck immediately after connecting to the device; we use the portaudio library to interface with the sound bus.
The following error is thrown:
ALSA lib bluealsa-pcm.c:714:(_snd_pcm_bluealsa_open) Couldn't get BlueALSA transport: No such device or address
Just digging some more...
Michele
Yes and it didn't work:
even specifying other parameters such as HCI=hci0, PROFILE=a2dp
And this is compatible with the following:
the command bluealsa-aplay -L won't work as it seems there is no option -L
Thanks!
Indeed, yes, finally I got bluetoothd (I think I simply made a wrong lookup: it was there since yesterday!).
Some progress:
The last step missing is that in the alsa backend the bluetooth device is still missing (aplay -L won't show any other device than the imxsgtl5000 and imxhdmisoc), so is still impossible to stream to the headphones...
Michele
Hi everyone.
On an armstonea9r2board, I'm trying to pair a bluetooth headphones.
On buildroot, I've enabled the following packages:
compilation and deployment on the board is successful.
I can successfully raise the hci0interface (hciconfig hci0 up) and scan for devices (hcitool scan); I can also read both the name of the device and the device info through the commands: hcitool name <device address> and hcitool info <device address>, but seems I cannot pair the headphones (hcitool cc <device addr>), as -even if the command doesn't return any error, any next command requiring an active connection raises an error (such as hcitool rssi).
Moreover, when I try to test the headphone through bluealsa-aplay the following error is raised:
bluealsa-aplay: BlueALSA connection failed: No such file or directory
and this confirm the missing connection.
When launching bluealsa (which is the bluetooth daemon, right?), the following error is raised:
bluealsa: Couldn't get managed objects: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.bluez was not provided by any .service files
Looking into the /etc/dbus-1/system.d path, I can see a bluetooth.conf file allowing for the security policies of the bluetooth daemon, but Googling the above message I've found nothing applicable for an embedded system (many user reported the needs to add users into specific groups, and so on...)
Trying to tackle the problem with a completely different approach, I saw in many posts the usage of the bluetoothctl command to pair devices, which in my case opens successfully a prompt interface, but doesn't allow to enter any command.
On forums this behavior is reported to be connected with the bluetooth daemon not started (specifically bluetoothd), that effectively is missing from the active processes and can't also be found on the executable deployed on the board (which is bluealsa according to the first approach).
I've searched a way to get bluetoothd deployed on the board through buildroot, but I can't find any way.
I'm a newbie on this topic: I admit I don't have a full understanding on what is happening and surely I'm missing some steps...
Do you have any hints on how to pair a headphone and stream some audio through bluez-alsa (or other framework?)
Thanks and BR,
Michele Bucceri
Which is the best strategy to enable PWM on boot?
My aims is to enable & set the pwm to a preconfigured duty cycle as soon as possible during the boot process.
I'v digged into buildroot but can't figure out how to do that.
Currently I'm building using an out-of-tree project structure, so that any project specific configuration would be isolated from the F&S's provided buildroot tree.
Thanks,
Michele
Can you help to figure-out which is the best strategy to enable PWM on boot?
My aims is to enable & set the pwm to a preconfigured duty cycle as soon as possible during the boot process.
I'v digged into buildroot but can't figure out how to do that.
Currently I'm building using an out-of-tree project structure, so that any project specific configuration would be isolated from the F&S's provided buildroot tree.
Thanks,
Michele
Hi,
I've seen the new Virtual box is based on Fedora 27, while the document "Advices for Linux on PC" states to install a Fedora 23 distribution.
Developing on a native linux workstation (with buildroot), which is the suggested Fedora version? 23 or 27?
Thanks & BR!
Michele Bucceri
Thanks a lot, it works!
I was wrong because I issued the export command using the gpio#: that's why it didn't worked...
Just a note: I found the following mapping:
PWM_A on pwmchip3
PWM_B on pwmchip0
PWM_C on pwmchip1
BR,
Michele Bucceri
Hi,
I wish to control PWM_A, PWM_B and PWM_C on an armStoneA9r2, that, according to the GPIO reference card, are associated with /sys/class/gpio# 42, 125, 126 mapped on feature pins 28, 30, 32.
On general linux forums, I've seen it should be possible to control PWM outputs by setting values on sysfs parameters such as duty_cycle, polarity, enable.
But I can't find any of them on the sysfs treee on the pwm subfolder.
On my board (among the others) the most likely entries I have are:
/sys/class/pwm/pwmchip0/device/power/
autosuspend_delay_ms
control
runtime_active_time
runtime_status
runtime_suspended_time
But can't set any of those values, as I catch errors. (Permission denied).
Looking in other paths under /sys/class/pwm/pwmchip# I've not found any suitable file I can set.
am I missing something?
Thanks and BR,
Michele Bucceri
Yes, you are right, it works!
I initially tested the plain configuration (without qt) and then switched to the qt_defconfig.
Make distclean fixed the things, and now it works flawlessy!
Thanks a lot!
Michele
To what I remember, fsimx6_qt5_defconfig, but I can't remember exactly. Is there any log where I can check?
Which is the correct one for the dual-lite?
Thanks!
Hi,
I'm testing an armStoneA9r2 board, and I tried to write a Qt5 demo application carefully following the tutorial you provided, but the application fails to launch, with the following message :
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
qt.qpa.egldeviceintegration: EGL device integration plugin keys: ("eglfs_emu", "eglfs_kms_egldevice", "eglfs_x11")
qt.qpa.egldeviceintegration: EGL device integration plugin keys (sorted): ("eglfs_viv", "eglfs_x11", "eglfs_emu", "eglfs_kms_egldevice")
qt.qpa.egldeviceintegration: Trying to load device EGL integration "eglfs_viv"
qt.qpa.egldeviceintegration: Failed to load EGL device integration "eglfs_viv"
qt.qpa.egldeviceintegration: Trying to load device EGL integration "eglfs_x11"
qt.qpa.egldeviceintegration: Using EGL device integration "eglfs_x11"
Could not open display
Aborted
The only way to start the application is launching through xinit:
xinit ./testApp
if I unset the DISPLAY environment variable, the log turns into:
qt.qpa.egldeviceintegration: EGL device integration plugin keys: ("eglfs_emu", "eglfs_kms_egldevice", "eglfs_x11")
qt.qpa.egldeviceintegration: EGL device integration plugin keys (sorted): ("eglfs_viv", "eglfs_emu", "eglfs_kms_egldevice", "eglfs_x11")
qt.qpa.egldeviceintegration: Trying to load device EGL integration "eglfs_viv"
qt.qpa.egldeviceintegration: Failed to load EGL device integration "eglfs_viv"
qt.qpa.egldeviceintegration: Trying to load device EGL integration "eglfs_emu"
qt.qpa.egldeviceintegration: Using EGL device integration "eglfs_emu"
Could not open egl display
Aborted
The Qt config.summary log shows:
....
QPA backends:
DirectFB ............................... no
EGLFS .................................. yes
EGLFS details:
EGLFS OpenWFD ........................ no
EGLFS i.Mx6 .......................... no
EGLFS i.Mx6 Wayland .................. no
EGLFS RCAR ........................... no
EGLFS EGLDevice ...................... yes
EGLFS GBM ............................ no
EGLFS VSP2 ........................... no
EGLFS Mali ........................... no
EGLFS Raspberry Pi ................... no
EGLFS X11 ............................ yes
LinuxFB ................................ no
VNC .................................... yes
Mir client ............................. no
So from this log it appears the EGLFS is supported only through X11 and EGLDevice.
Target packages
+ --> Graphic libraries and applications (graphic/text)
+--> Qt5
+--> eglfs support
+--> Default Graphical platform --> eglfs
Digging into the buildroot config, I see that the eglfs_viv should be enabled, since the following parameters are enabeled:
BR2_PACKAGE_FREESCALE_IMX_HAS_VIV_GPU [=y]
BR2_PACKAGE_GPU_VIV_BIN_MX6Q [=n] (--> Ok, the CPU is a DualLite)
BR2_PACKAGE_IMX_GPU_VIV [=y]
BR2_PACKAGE_KERNEL_MODULE_IMX_GPU_VIV [=y]
I assume the reason EGLFS is supported only through the X11 backend is due to the missing "EGLFS i.Mx6" option in Qt.
Is that true? Am I missing something? Is it possible to start the application not using the X11 backend and using directly Vivante ?
Thanks in advance!
Michele Bucceri