Hi Martin, Storing the data in a byte array worked perfectly for me. I can always convert it to a string when needed. To be honest, I was trying to avoid that at first, since it would require changing a lot of existing code—but in the end, this approach makes more sense, especially since I’m mostly ...

Hi Martin, After giving it some thought, I realized that many C functions stop processing a string once they encounter a null character. That’s likely the issue when trying to store the data in a string array. I’ll try storing the data in a byte array instead and see how that works out. I really app...

Hi Martin, Sorry can not share the FCFX file, > The additional setup is required to change non-standard baud rates during runtime. > Receiving a single character per interrupt is a good idea, I have not tried that . > For each unit & Brand, the expected byte count is known, but a timeout is also...

Hi mnfisher The ReceiveString function is in a UartRX interrupt Baud is 1200 and is set by the following code // Disable USART transmitter and receiver UCSR1B &= ~((1 << TXEN0) | (1 << RXEN0)); FCV_UART_1_STATUS [0] = 0; //Set Baud XTAL @16Mhz UBRR1H = 0x03; UBRR1L = 0x40; FCV_UART_1_STATUS [1] ...

Hello, I believe there's a bug in the UART receive function on the ATmega128A. It seems that the 0x00 byte is being interpreted as a string terminator, causing the reception to stop prematurely. For example, if I try to receive the following byte stream: 23 1B 44 66 00 21 63 1E Only these bytes are ...

Hi Steve,

Thanks for your reply, I was not able to do that, if you are referring to the customize code option
that is only available to Pro users.

The only method I found is to compile to C, then in the Build menu View Code, search for the C-code Part, copy and paste it in
a new c-block

Hello, I've encountered a bug in the C-code block. If you add a C-code block, delete everything inside, and start writing from the second line, the code appears to save correctly. However, after pressing "OK" and reopening the block, all the code is gone. This issue only occurs when the fi...

Hello again, After further testing, I discovered that the SH1106 I2C display is fully compatible with the SSD1315—no additional code is needed. The display also communicates on address 0x3C. The only difference is that the SH1106 has a reset pin, whereas the SSD1315 does not. However, if the reset p...

Hi medelec35, Problem Description: The display has a 3-pixel offset to the left, leaving a 3-pixel wide uncleared area on the right side. Temporary workaround : I tried this C code that initializes the display with a horizontal offset of 3 pixels to the right. This should have fixed it but when prin...

Hi medelec35, The SSD1315 display also uses I2C address 0x78 and has a resolution of 128x64 just like SSD1306 The display is receiving data and showing Text, but the output isn’t correct. There’s a noticeable offset issue — for example, if I set X = 0, part of the text on the left side gets cut off....