Execute command for Nextion with M118 gcode - g-code

I am trying to control Nextion device with Skr Pro v1.2 But I couldn't find a way.
I enabled #define NEXTION_TFT nextion module and connected to TFT port. I used many versions of M118 codes but it didn't work.
Fo ex: M118 P2 page page2 or M118 A1 P2 page page2 or M118 P2 page page2 M118 P2 0xFF 0xFF 0xFF or whatever else....
These are serial settings.
#define SERIAL_PORT -1
#define BAUDRATE 250000
#define SERIAL_PORT_2 1
#define BAUDRATE_2 9600 // Enable to override BAUDRATE
With this way, i can control SKr Pro with the Nextion device. For ex : print "M104 S210 T0" it is working properly.
Now I need a hand to control pages or values on Nextion device with M118 command or another way.
Thank you from now

Related

How do I change the SD card controller that's used by U-boot for the Raspberry Pi 3 Model B+?

The Raspberry Pi 3 Model B+ has two SD card controllers.
There is custom controller called sdhost as shown by the device tree node:
/* SDHOST is used to drive the SD card */
&sdhost {
pinctrl-names = "default";
pinctrl-0 = <&sdhost_gpio48>;
status = "okay";
bus-width = <4>;
};
And an SDHCI-compliant controller as shown by the following device tree node:
/* SDHCI is used to control the SDIO for wireless */
&sdhci {
#address-cells = <1>;
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&emmc_gpio34>;
status = "okay";
bus-width = <4>;
non-removable;
mmc-pwrseq = <&wifi_pwrseq>;
brcmf: wifi#1 {
reg = <1>;
compatible = "brcm,bcm4329-fmac";
};
};
As referenced by the U-boot comments, U-boot is using SDHOST as the SD card controller and SDHCI as the WiFi controller.
/* SDHOST is used to drive the SD card */
...
/* SDHCI is used to control the SDIO for wireless */
The problem I'm facing is that I'm unable to run this SD card driver (source code here) via U-boot, which uses the Pi's SDHCI controller to interact with SD cards.
The SD card driver runs successfully bare-metal via the Pi's existing bootloader as shown by the output below:
EMMC: GPIO set up
EMMC: reset OK
sd_clk divisor 00000068, shift 00000006
EMMC: Sending command 00000000 arg 00000000
EMMC: Sending command 08020000 arg 000001AA
EMMC: Sending command 37000000 arg 00000000
EMMC: Sending command 29020000 arg 51FF8000
EMMC: CMD_SEND_OP_COND returned VOLTAGE CCS 0000000040F98000
...
However, when I try to run the binary via U-Boot using the go command, the code is stuck during the initialisation phase of the SDHCI controller (exact line in source code here) as shown below:
EMMC: GPIO set up
EMMC: reset OK
sd_clk divisor 00000068, shift 00000006
EMMC: Sending command 00000000 arg 00000000
EMMC: Sending command 08020000 arg 000001AA
ERROR: failed to send EMMC command
My suspicion is that since U-boot has configured the SDHCI controller for Wifi (and not for SD cards), I can no longer use it as an SD card controller. However, I want to use the SDHCI controller as the SD Card controller.
What is the best way to get my SD card binary running via U-boot?
Is the only option to configure/recompile U-boot to use the SDHCI controller as the main SD card controller (and forget about WiFi)?
If so, some pointers on how to go about this would be much appreciated.
Alternatively, is there a U-boot shell command (like some sort of reset command) that give binaries a runtime environment similar to a bare-metal environment that has been un-modified by U-boot?
Edit:
Here is my progress so far. I've figured out how to exclude the custom SDHOST driver from being initialised via two methods:
Modifying the DTS file by replacing status = "okay" with status = "disabled" for the custom SDHOST driver.
Adding CONFIG_MMC_BCM2835=n to U-Boot's configs/rpi_3_b_plus_defconfig file.
When I launch U-boot, and run mmc list, I see only the SDHCI controller, which is great:
U-Boot> mmc list
mmc#7e300000: 0
I know the above is the SDHCI controller because its device registers are mapped to the physical address of 7e300000 as shown in arch/arm/dts/bcm283x.dtsi below:
sdhci: mmc#7e300000 {
compatible = "brcm,bcm2835-sdhci";
reg = <0x7e300000 0x100>;
interrupts = <2 30>;
clocks = <&clocks BCM2835_CLOCK_EMMC>;
status = "disabled";
};
However, as shown in the following boot logs, U-boot is still not happy to use this controller as the SD card controller:
MMC: mmc#7e300000: 0
Loading Environment from FAT... Card did not respond to voltage select! : -110
** Bad device specification mmc 0 **
Below is the entire boot log:
U-Boot 2023.01-00790-g8c80619653-dirty (Feb 11 2023 - 10:04:49 +1100)
DRAM: 948 MiB
RPI 3 Model B+ (0xa020d3)
Core: 63 devices, 14 uclasses, devicetree: embed
MMC: mmc#7e300000: 0
Loading Environment from FAT... Card did not respond to voltage select! : -110
** Bad device specification mmc 0 **
In: serial
Out: vidconsole
Err: vidconsole
Net: No ethernet found.
starting USB...
Bus usb#7e980000: USB DWC2
scanning bus usb#7e980000 for devices... 4 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
U-Boot> mmc list
mmc#7e300000: 0
My suspicion is that the SDHCI controller is still being treated by U-Boot as a WiFi controller (I can't tell for sure). What are some troubleshooting steps I can take to figure out what is going on?
My solution is to change the following line in the sdhci node of the DT located at arch/arm/dts/bcm2837-rpi-3-b-plus.dts from
pinctrl-0 = <&emmc_gpio34>;
to
pinctrl-0 = <&sdhost_gpio48>;
Then I recompile U-boot and use the resultant U-boot binary as the Pi’s bootloader.
The final and desired result is that:
U-boot can still use the sdhost driver and controller to access the SD card when it is running (which is U-boot’s default preference).
The binary run by U-boot (via the go command) can also manipulate the sdhci controller’s device registers to interact with the SD card.
For additional context around the solution, the sdhost_gpio48 reference above is located in this DTSI file located at arch/arm/dts/bcm283x.dtsi:
sdhost_gpio48: sdhost_gpio48 {
brcm,pins = <48 49 50 51 52 53>;
brcm,function = <BCM2835_FSEL_ALT0>;
};
The pinctrl-0 parameter we have changed refers to “Pin Control” and detailed documentation about this parameter can be found here.
From my understanding, our change specifies the same GPIO pins that are being used for the SDHOST controller for the SDHCI controller, which enables us to use the SDHCI controller as an SD card controller.

LCD shows random characters (MPLAB)

I'm trying to connect my LCD screen (16x02 QAPASS) to my PIC16F1937 on MPLAB, but it displays random characters (in this case Chinese characters, question marks and slash) instead of alphanumeric. However, all PIN connections have been declared in the library and correctly connected to the PIC. I use an XC8 compiler.
Here are the connections:
VSS --> GND
VDD --> 5V
VO --> 680Ω resistance
EN --> RD1
RW --> RD6
RS --> RD0
LCD_D4 --> RD2
LCD_D5 --> RD3
LCD_D6 --> RD4
LCD_D7 --> RD5
Anode --> 5V
Cathode --> GND
The global project is a sensor that detects the distance of an object and displays this same distance on the LCD. The fact that the LCD does not display the character compromises the rest of the project because I cannot set up the mathematical calculations if the LCD fails.
1) Library Code : lcd.h (Header Files) This is the code provided by Microchip for the LCD library and I added the PIN-LCD connections:
// single bit for selecting command register or data register
#define instr 0 #define data 1
// These #defines create the pin connections to the LCD in case they
are changed on a future demo board
#define LCD_PORT PORTD
#define LCD_PWR PORTDbits.RD7 // LCD power pin
#define LCD_EN PORTDbits.RD1 // LCD enable
#define LCD_RW PORTDbits.RD6 // LCD read/write line
#define LCD_RS PORTDbits.RD0
#define LCD_D4 PORTDbits.RD2
#define LCD_D5 PORTDbits.RD3
#define LCD_D6 PORTDbits.RD4
#define LCD_D7 PORTDbits.RD5
// LCD register select line
#define NB_LINES 2 // Number of display lines
#define NB_COL 16 // Number of
characters per line
2) Library Code 2 : lcd.c (Source Files) Contains the commands related to the LCD
3) Main Code : main.c (Source Files)
#include "mcc_generated_files/mcc.h"
#include "lcd.h"
#define _XTAL_FREQ 4000000
void main(void)
{
// initialize the device
SYSTEM_Initialize();
// initialize LCD
LCD_Initialize();
LCDGoto(4, 1); // go to column 4, row 1
LCDPutChar("test1");
LCDGoto(3, 2); // go to column 3, row 2
LCDPutStr("test2");
while (1)
{
}
}
#AfricaOMM,
It would appear that your code may be based on code from this link.
Because you posted only fragments it is impossible to determine just how bad the code you are trying to work from is.
The code at link I found has a Microchip copyright but it is of poor quality with bugs that will cause you several problems.
You would benefit in the long run by sorting out this mess on your own.
My best advise is to put LEDs on the signal lines that connect to your LCD module and verify that your PIC16F1937 sets each line to the correct state when the initialization code runs.
I suspect you have errors in wiring along with errors in your code.
Problem solved!
The problem was related to the library.
The library that Microchip provides is full of malfunctions, so when executing commands, the PIC do not receive the supposed informations it should receive, that's why the LCD shows random characters.
I suggest you use the library developed by electrosome : I confirm that it is 100% operational, thanks to them!
Another thing: to solve the contrast problem, it will ideally be necessary to connect the VO port of the LCD to a potentiometer.
When we send a msg on LCD it shows funny characters or some weird symbols because the hardware requires some time to get refreshed. You can try to give some sleep time.after this line
LCDPutStr("test2"). Put above sleep time
LCD.sleep(5)
It worked in my case.
When we send a msg on LCD it shows funny characters or some weird symbols because the hardware requires some time to get refreshed. You can try to give some sleep time.after this line
LCDPutStr("test2"). Put above sleep time
LCD.sleep(5)
It worked in my case. It worked in my case.

In ADB Shell, PIO is not picking up I2C device

ADB PIO is not picking up an I2C device (HMC5883L Magnetometer).
I have the magnetometer connected correctly to VCC, GND, SDA & SCL. Then within adb shell I use pio i2c I2C1 0x3D read-raw 1 and it's giving me [WARNING:client_errors.cc(35)] error 6: No such device or address
I am wondering what I'm missing, any help would be appreciated!
Stats:
Android-Things
NXP i.MX7d on PICO-Pi
HMC5883L 3 Axis Magnetometer on I2C
Android Studio - Command Line ADB
I have the magnetometer connected correctly to VCC, GND, SDA & SCL. Then within adb shell I use pio i2c I2C1 0x3D read-raw 1 and it's giving me [WARNING:client_errors.cc(35)] error 6: No such device or address
There are potentially a couple things wrong with this command, according to the HMC5883L datasheet:
The device uses register-based access which means a raw read is likely to fail. You should be using a command like read-reg-byte to test communication with the device.
The I2C device address is 0x1E. The datasheet gives you the completed 8-bit format of the address in a full byte (which is 0x3D and 0x3C, depending on the R/W bit), which is a bit confusing.
So a better command for you to send and test your device would be this one, which should report the value of the STATUS register:
$ pio i2c I2C1 0x1E read-reg-byte 0x09
If you still receive the same error with the above command, check the pinout diagram to verify you are connected to the right I2C port (I2C1 vs. I2C2).

Rpi wheezy duplicate capture on usb & dummy cards

I am trying to create an application that will stream audio with Darkice as well as provide a LED VU meter indication of the audio stream.
I have created a virtual card with . This card is recognized by alsamixer, aplay, and arecord but I can not transfer the line-in signal from the usb card (hw:0,0) to the dummy card (hw:2,0).
I have tried several .asoundrc scripts that I found both in your Q&A as well as Google using alsa dmix, dsnoop, and multi but nothing has worked so far.
I am presently using one python program (LED_VU.py) that autostarts in one terminal, and the second python program containing Darkice (streamer.diDual.py) in a second terminal. The configuration portion of the LED program is:
### LED VU Meter on RPI ###
#!/usr/bin/env python
import alsaaudio as AA
import audioop
from time import sleep
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BOARD)
GPIO.setwarnings(False)
#Define physical header pin numbers for 10 LEDs
RPiPins=[11,12,13,15,16,18,22,7,3,5]
#set all pins as output
for pin in RPiPins:
GPIO.setup(pin, GPIO.OUT)
#Set up audio
card = 'hw:0,0'
The configuation portion of darkiceDual.cfg is:
# Darkice Configuration File - Generated by Streamer
[general]
duration = 0 # duration of encoding, in seconds. 0 means forever
bufferSecs = 5 # size of internal slip buffer in seconds
reconnect = yes # reconnect to server if disconnected
[input]
device = hw:2,0 # alsa usb soundcard device for audio input
sampleRate = 44100 # sample rate in Hz
bitsPerSample = 16 # bits per sample
channel = 2 # channels. 1 = mono, 2 = stereo
My .asoundrc file is:
pcm.!default {
type plug
slave.pcm "mdev"
route_policy "duplicate"
}
pcm.mdev {
type multi
slaves.a.pcm "hw:0,0"
slaves.a.channels 2
slaves.b.pcm "dmixer"
slaves.b.channels 2
bindings.0.slave a
bindings.0.channel 0
bindings.1.slave a
bindings.1.channel 1
bindings.2.slave b
bindings.2.channel 0
bindings.3.slave b
bindings.3.channel 1
}
pcm.dmixer {
type dmix
ipc_key 1024
slave {
pcm "hw:2,0"
period_time 0
period_size 1024
buffer_size 4096
rate 44100
channels 2
format S16_LE
}
}
What am I doing wrong?
The streamer will have no audio if I use hw:2,0 and have the 'Can not connect' error if I use hw:0,0 (LED_VU.py is using this). If I change the card setting of the LED program to hw:2,0 the LEDs will lockup with all of them lit.
Any help is appreciated!
Thank you for the help. The two programs both use the usb line-in as expected.
I am not able to use alsamixer or amixer now. Pulseaudio is causing the problem now. If it is installed, the LED_VU.py program will not run. When it is uninstalled, the python programs will run but not alsamixer.
Apparently, you want to run the VU meter and DarkIce from the same audio data, i.e., you need to allow two programs to share one recording device.
This can be done with the dsnoop plugin. Which is enabled by default for USB devices.
Tell both programs to record from the device default. If that was redefined, try dsnoop:0 instead.

Generation of RTE_Components.h

I'm working with MDK-Pro and the File System library.
In my application, I require an SPI interface to the SD card. I've managed to setup the project properly, except that in the RTE_Components.h file that Keil generates the line #define RTE_Drivers_MCI0 which subsequently triggers a preprocessor error ("SDIO not configured in RTE_Device.h").
Although I can manually comment out this line in RTE_Components.h, every so often Keil updates this file and I get the above problem. Does anyone know what exactly generates this file, and how I can stop it from adding the SDIO-related definitions into the project?
The RTE_Components.h is not supposed to be modified and will always be automatically generated. That the stack tries to connect via MCI interface is related to your configuration made in the "FS_Config_MC_0.h".
// <o>Connect to hardware via Driver_MCI# <0-255>
// <i>Select driver control block for hardware interface
#define MC0_MCI_DRIVER 0
// <o>Connect to hardware via Driver_SPI# <0-255>
// <i>Select driver control block for hardware interface when in SPI mode
#define MC0_SPI_DRIVER 0
// <o>Memory Card Interface Mode <0=>Native <1=>SPI
// <i>Native uses a SD Bus with up to 8 data lines, CLK, and CMD
// <i>SPI uses 2 data lines (MOSI and MISO), SCLK and CS
// <i>When using SPI both Driver_SPI# and Driver_MCI# must be specified
// <i>since the MCI driver provides the control interface lines.
#define MC0_SPI 1

Resources