Writing to E-Ink display over UART

Hardware
1

I have a particle argon with grove shield.
On Grove Shield UART port I connected a E-Ink display(https://wiki.seeedstudio.com/Grove-Triple_Color_E-Ink_Display_2_13/)

Does anyone have any experience with writing to Uart devices?

I’ve tried this but no luck.
Serial1.begin(115200);
delay(500);
char str = ‘a’;
Serial1.write(str);

Not expecting much from the ‘a’, but it’s not updating the display at all.

Thanks in advance

2

Have you tried their demo code for that display?

3

Yes, but that was written for Arduino. I can’t set the Serial they way they do, right?
void setup() {
SERIAL.begin(230400);

Particle only supports up to 115200?

4

Also not all libraries are available on Particle Libraries: #include <avr/pgmspace.h>

5

You cannot arbitrarily change the baudrate on one side and expect the other side to still understand the communication.
However, you can also use 230400 the devices should support it.

In case you really have a device that does not support a particular baudrate you’d need to inform the other side of the fact. I don’t know that particular display but other devices usually have a way to set their default baudrate - either via jumpers/solder briges or in software.

The pgmspace.h include can be dropped without replacement.

1 Like
6

Tried the Git code sample, it compiles, but it just bricks the Argon. I think the .Available() just keeps waiting.

7

You can add SYSTEM_THREAD(ENABLED) to keep the cloud connection going even when the application code blocks.

8

Where do you place this line? In Setup()?

Either way, it gets stuck on

    while (1) {
        if (SERIAL.available() > 0) {
9

You would place it as shown here


image
image996×599 49.5 KB

BTW, have you defined SERIAL as Serial1 - if not I’m not surprised the code gets stuck waiting for data to be sent via USB Serial.

1 Like
10

This is my current code

image
image567×1206 45.3 KB

11

@tobiasv, take a look here on how to share your application correctly:

2 Likes
12
13

@tobiasv, it compiles under DeviceOS 2.0.0-rc.2 for an Argon but what does do when you run it?

14

Doesn’t even trigger the publish line in the setup code.
Are you sure this is correct?

 #define SERIAL Serial1
15

@tobiasv, the line is correct. The Publish() won’t fire until the Argon connects to the Particle Cloud. Is the LED on the Argon getting to a breathing cyan state?

16

I have put in safe mode (breathing cyan), flash the code

image

And after a while it goes into red LED SOS blinking state.

17

Hi,
could you try with this:


Regarding to this article there were some issue with

pgm_read_byte();

18

In the Particle ecosystem PROGMEM and pgm_read_byte() and the likes are null-instructions.

See here https://github.com/particle-iot/device-os/blob/develop/wiring/inc/spark_wiring_arduino.h

Instead of trying to fix something that’s not necessary in the first place I’d rather remove it entirely.

const unsigned char IMAGE_BLACK[] = { /* 0X00,0X01,0XC8,0X00,0XC8,0X00, */
    0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF,
...
    0XFF, 0XFF, 0XFF, 0XFF,
};

const unsigned char IMAGE_RED[] = { /* 0X00,0X01,0XC8,0X00,0XC8,0X00, */
    0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF,
...
    0XFF, 0XFF, 0XFF, 0XFF,
};
...
//Send data to e-link board.
void serial_send_data(const uint8_t* data, uint32_t data_len) {
    for (int i = 0; i < data_len; i++) {
        Serial1.write(data[i]);
    }
}

If the code is blocking in the while(1) loops (well before the first instance of using pgm_read_byte()) it’s probably a good idea to add some sort of timeout.

It may also be a good idea to check whether the signals from and to the display are actually finding their correct way - e.g. via logic analyzer or oscilloscope

1 Like
19

I tried that code, but it still goes to SOS mode. :frowning:

20

I tried without the pgm & PROGMEM.

I doesn't go into SOS but doesn't publish the messages in the Setup(), no change to display.

Don't know how to do this:

It may also be a good idea to check whether the signals from and to the display are actually finding their correct way - e.g. via logic analyzer or oscilloscope