I am trying to migrate my code that is written in C++ syntax to python syntax. Now my issue is, I am not able to find the right library to import in REPL.
I am trying to transmit RC6 data of length 24. In original code, I have include
#include <IRremoteESP8266.h>
#include <IRsend.h>
//some code
const uint16_t kIrLed = 4; // ESP GPIO pin to use. Recommended: 4 (D2).
IRsend irsend(kIrLed); // Set the GPIO to be used to sending the message.
//some more code
ir.**sendRC6**([code] ,[length]);
Please suggest which library to import, such that I can send the hex data on GPIO D2.
Thanks and Regards,
Shariq
Related
I found some answers that didn't solve my issue for STM32F302.
I configured the debug run as follows, to printf() in the SWV ITM Data Console:
IMG-Debug_Config
I implemented the _write function as follows:
int _write(int file, char *ptr, int len)
{
int DataIdx;
for (DataIdx = 0; DataIdx < len; DataIdx++)
{
ITM_SendChar((*ptr++));
}
return len;
}
And tried to setup the sys clock for "Asynchronous Trace" and "Serial Wire", none worked and I keep getting the same output (SWV Graph does not work either):
IMG-SWV_Output
Any suggestion about this issue? I just want to debug the variable to make sure I'm getting the correct measurement.
PS. Just a brief of my project: An ADC for a light sensor. I need to generate a graph from a laser sample measurement. Make this measurement with the STM32 and a photodiode, finish the measurement and send the .csv or .txt from USB to a computer to analyse the data.
I found what my problem was:
My "Core Clock (MHz)", in the debug settings, was wrong and that's why my SWV was not working properly
If no SWV data - you need to connect the SWO pin to ST-LINKV2. The SWV data transmission is on the SWO pin. On my STM32F3DISCOVERY, the SB10 was not soldered, SB10 connecting the PB3 SWO pin to the T_SWO debugger net. After soldering SB10 SWV work perfectly.
Hi I would like to configure a custom GPIO pin as output to control a motor on a STM32 H743Zi board running Zephyr RTOS.
The dts file of the board can be found in the folder or a separate file nucleo h743zi.dts code.
I would like to us the arduino pin mapping provided by the board ardunio r3 connector.dtsi code
The overlay file that I've developed so far is as follows code. I would like to configure the D0 pin (as per the arduino connector dtsi file) as a GPIO pin to control the motors.
However, I've not been able to configure the pin and I don't receive a high signal if the pin is turned on.
Any help to resolve this issue is appreciated.
You can refer to the answer in this link:
https://github.com/zephyrproject-rtos/zephyr/discussions/35932
In my case, I use Thunderboard Sensor 2 and my solution as below:
Move to the <board.dsti> in folder /zephyr/dts/arm/silabs/efr32mg.dtsi
insert your define GPIO to use:
...
/ {
zephyr,user {
signal-gpios = <&gpioa 8 GPIO_ACTIVE_HIGH>;
};
...
Here, I use my board portA and pin 8 as schematic
After you save the file, open the main file of your project and insert something as below:
#define ZEPHYR_USER_NODE DT_PATH(zephyr_user)
...
void main(void)
{
const struct gpio_dt_spec signal =
GPIO_DT_SPEC_GET(ZEPHYR_USER_NODE, signal_gpios);
/* Configure the pin */
gpio_pin_configure_dt(&signal, GPIO_OUTPUT_INACTIVE);
...
while(1){
/* Toggle the pin PA8*/
gpio_pin_toggle(signal.port, signal.pin);
k_msleep(SLEEP_TIME_MS);
}
...
Write the code using MPLABX IDE ( Can just write the main c code) as i am not understanding the syntax to be used while writing and available functions
Apologies for such a generic title but couldn't think of any better.
I am trying to understand where in drivers/i2c/ is the protocol sequence of sending START, ADDR, DATA, STOP bit sequence implemented, as per the protocol. I want to verify the protocol for send/receive in the driver code, that's all the objective here.
I am using Hikey 620 as a reference which has DesignWare's I2C controller. Below is the registration code I can see (elixir):
static const struct i2c_algorithm i2c_dw_algo = {
.master_xfer = i2c_dw_xfer,
.functionality = i2c_dw_func,
};
If I trace the i2c_dw_xfer function recursively, the last call I could see are readl_relaxed, writel_relaxed in i2c_dw_xfer_init() (elixir).
Beyond this is all assembly. Are these readl/writel the actual sequence of start/data/stop byte sequences? Or am I understanding it totally wrong?
In that case, please help and point me to the correct flow. If what I got is correct, is there some simpler controller code which has a cleaner implementation and can be used as reference.
The protocol itself is not part of the driver code. What the dw_{readl/writel} functions do by calling readl/writel is write to the registers of the I2C peripheral of the concerned SoC. It is the job of the I2C controller on the SoC to then generate the correct I2C signalling. You can see by going through the datasheet that something like DW_IC_CON is a register offset in the I2C peripheral memory map.
I am a beginner in AT Mega-1284P Xplained.
I want to turn an LED on and then off (say, LED0) after some specified time in AT Mega 1284P Xplained board from ATMEL. To my surprise, I found no official documentation for this rudimentary task but several different function calls - all of which failed compilation - searching on the web.
Please mention the API call as well as the header file that needs to be included for this. I am using AVR Studio 6.
I will assume a led is connected to pin 0 at port b on the AtMega1284P. The following program should make the led blink.
#include <util/delay.h>
#include <avr/io.h>
int main() {
// Set the pin 0 at port B as output
DDRB |= (1<<PB0);
while(1) {
// Turn led on by setting corresponding bit high in the PORTB register.
PORTB |= (1<<PB0);
_delay_ms(500);
// Turn led off by setting corresponding bit low in the PORTB register.
PORTB &= ~(1<<PB0);
_delay_ms(500);
}
}
Answering my own question: I found Atmel had an example code that covered a bunch of sensors and other peripheral components including LEDs for Mega-1284P. The links are link and link. Besides, very hard to find locations (they did not show up on web searches), the websites are _very_slow. Atmel, are you listening?