×

Hello and Welcome! If you have a technical question please check out our Forums. If you have an order or shipping question please refer to our Customer Support page. Please see all COVID-19 updates here and thank you for your continued support.

AllenKempe

Member Since: July 24, 2013

Country: United States

  • However, I have resumed trying to get the device working. I did some research and found that there are now new versions of the software including a version of Ubuntu 14.04. I downloaded the version that supports the LCD. https://s3.amazonaws.com/pcduino/Images/v3/ubuntu14/pcDuino3_lvds_100MbpsMAC_1404_20150202.img.zip It is a one-step process that doesn't involve installing the Kernel and OS separately.

    After flashing the new OS and kernel, I finally saw some response from the LCD. It showed the Slpash screen and displayed the text output. But then it hung up. After several reboots, I briefly got a display showing the desktop. But then as before, the device hung up. In none of these cases, was there anything displayed via the HDMI port.

    At this point, I re-flashed the device with the earlier NAND image from 01-07-2015. Now the device displayed via the HDMI port and there were no hangs and also, no display on the LCD. I tried downing the LCD driver but got a message that it was already installed. Checking the logs with dmesg, I see that the same incomplete xfer (0x20) messages were being logged. So it appears that all some software was present that was attempting to access the LCD display.

    At this point, I wondered whether the problems with the pcDuino hanging up were power related.. I was using a 1000ma power supply. I added another power supply to the USB hub and reflashed the LVDS kernel and OS. This time, the device came up OK and appears to work OK.

    I would conclude that you need at least a 2 amp power supply for the PcDuino when running with the LCD screen I guess the backlight used quite a bit of power.

    This then leaves a major question to be answered: is it possible to switch between the LCD display and the HDMI display without reflashing the kernel and OS?

  • What to do if it doesn't work?

    I have the latest Kernel and installed the touch driver but the screen remains dark. dmesg reveals this: ubuntu@pcduino:/etc$ sudo insmod /home/ubuntu/modules/touch/ft5x/ft5x_ts.ko

    ubuntu@pcduino:/etc$ sudo dmesg | tail

    [ 1977.500596] ctp_fetch_sysconfig_para.

    [ 1977.500630] ctp_fetch_sysconfig_para: name gslX680 does not match CTP_NAME.

    [ 1977.500641] ft5x_tsctp_fetch_sysconfig_para: ctp_twi_id is 2.

    [ 1977.500660] ctp_fetch_sysconfig_para: screen_max_x = 1024.

    [ 1977.500672] ctp_fetch_sysconfig_para: screen_max_y = 600.

    [ 1977.500683] ctp_fetch_sysconfig_para: revert_x_flag = 0.

    [ 1977.500694] ctp_fetch_sysconfig_para: revert_y_flag = 0.

    [ 1977.500706] ctp_fetch_sysconfig_para: exchange_x_y_flag = 1.

    [ 1977.500880] i2c-core: driver [ft5x_ts] using legacy suspend method

    [ 1977.500892] i2c-core: driver [ft5x_ts] using legacy resume method

    [ 1977.501116] incomplete xfer (0x20)

    [ 1977.501339] incomplete xfer (0x20)

    [ 1977.501571] incomplete xfer (0x20)

    ubuntu@pcduino:/etc$

  • I may have come up with a solution to the MPL3115A2 pressure reading. Unfortunately the fix is probably curing the symptoms and not the real cause. To get it to work, I had it read an extra byte, i.e. 4 instead of 3 and then discarded the first byte. Now the pressure is calculated properly.

    In addition, the temperature appears to be read correctly if you read 6 bytes and throw away the first 4. The conclusion is that the TwoWIre class is ignoring which byte to read and always starts at byte 0.

  • Weather Shield and pcDuino I have had mixed success using the Weather Shield on a pcDuino 3s. I have loaded the latest kernel (20140721) and the latest lUbuntu (20140430). I also have loaded the pcDuino with Qt version 4.8.6 and Qwt 6.1.0.

    My first attempts to duplicate the output of the Weather_Shield_with_GPS sketch running on an Arduino Uno resulted in many discrepancies. * I could not get the serial output to work. Several web queries leads me to believe that the SoftwareSerial library does not work on the pcDuino. So, I turned the switch on the Weather Shield to route the GPS output to UART2. This did not work at first until I obtained a copy of the setuart2 program that can be used to turn the UART on or off. Now, I was able to receive and process the GPS data.

    • While the HTU21D module's humidity and temperature seem to be working properly, the same could not be said for the MPL3115A2 pressure and temperature. I have not yet determined why this the case. It should be noted that the HTU21D readings returned are skewed by the heat given off by the pcDuino board.

    • The readings returned for battery level and light level were wrong. The light level never seemed to change. I finally determined that there were two problems. First, the value of /proc/adc1 which should be the light level always seems to be 63 no matter how much light is shining on the light sensor. However, I discovered that if the unused AD0 pin is grounded (I don't have the optional wind and rain sensors), then the value of adc1 (/proc/adc1) would change. However, the program still didn't display a good value for light_lvl. This turned out to be because the ad0 and AD01 pins are only 6 bits resolution instead of 12 like the others. So, the value returned has to be shifted: change the get_light_level function line where the light sensor is read from: float light_sensor = analogRead(LIGHT); to float light_sensor = (analogRead(LIGHT)<<6) | 0x37;

    I have developed a Qt graphical application using the Weather Shield and would be glad to share my code. And if anybody knows why the MPL3115A2 doesn't work, I'd appreciate it.

No public wish lists :(