Basic password checker with uart

RE: Basic password checker with uart

Sigurd Hellesvik — Mon, 27 Nov 2023 14:24:09 GMT

[quote user="Dzolo2k1"]with all the respects I dont know a bit of whats goin on in this +1k lines of code.[/quote]

Yea, it is unfortunate that samples go like this. Alas, with Bluetooth we need a lot of lines to show off the things.

[quote user="Dzolo2k1"] guess its time to move on and leave this exercise. There are too many connections with lines of code i dont get. [/quote]

Fair enough. For a last tip, in case you return to this, I can point you to the lines I refer to:

https://github.com/nrfconnect/sdk-nrf/blob/8f28ba57da4c922ca36af81d0c2b27e18264d2ee/samples/bluetooth/peripheral_uart/src/main.c#L129-L187

RE: Basic password checker with uart

Dzolo2k1 — Sun, 26 Nov 2023 18:40:55 GMT

with all the respects I dont know a bit of whats goin on in this +1k lines of code. I guess its time to move on and leave this exercise. There are too many connections with lines of code i dont get.

RE: Basic password checker with uart

Dzolo2k1 — Fri, 24 Nov 2023 21:24:00 GMT

Oh cuz u have to use other terminal i use the one from nrf toolchain

RE: Basic password checker with uart

Sigurd Hellesvik — Fri, 24 Nov 2023 14:02:53 GMT

I see that the BLE peripheral uart sample uses a fifo buffer to contain the data between the callbacks. Have a look at its receiving function in general, does it look similar to yours?

[quote user="Dzolo2k1"]https://github.com/Dzolowski/ZephyrNRFBasics/tree/main/SecondEx [/quote]

Is this up to date? When I try it, it will detect every single keypress I do, which seems odd.

RE: Basic password checker with uart

Dzolo2k1 — Wed, 22 Nov 2023 14:05:47 GMT

So i know about DevAcademy, and this code was based on this sample, I just wanted to expand this exercise to my own idea- changing blinking diodes based on offset to password checking. I know that the problem might be my skill issue with C - im self taught, and i might not have knowledge about buffers in advanced/semi-advanced using them. So in this moment I just want to know why it doesnt work for future projects.

Because lets look at this step by step:
-allocating memory so it is on heap not in the array on stack(that was my previous code and it wasnt working too)
-checking if there is \n \r anywhere in my buffer if there is do not procced it into received_password.
- null termination
- clearing memory and index.

I have no clue why it doesnt work and why there is still overflow if the buff size is dunno 100 and my allocated memory is len+1

Everytime i debug it some letters just stay in the register and I can clearly see this in my terminal answers like dmin etc.

Fun fact nr2- my string even when im doing free(allocatedmemory) is still untouched according to what i see in debugger variables.

RE: Basic password checker with uart

Sigurd Hellesvik — Wed, 22 Nov 2023 11:39:01 GMT

We have a good exercise on UART over at DevAcademy. I suggest that you check that out:

https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-4-serial-communication-uart/

After going through that, let me know if you still have the same questions, and I will have a look to see if I can figure out how to do it.

By the way, we have several samples for UART. One of the ones which may be relevant for you, even though it may not seem so, is the Bluetooth: Peripheral UART sample. This one sends strings on enter I believe, so you can have a look at how it does stuff.

RE: Basic password checker with uart

Dzolo2k1 — Tue, 21 Nov 2023 23:15:29 GMT

+ funfact, when im trying to type password too fast in terminal program stops working

RE: Basic password checker with uart

Dzolo2k1 — Tue, 21 Nov 2023 22:52:41 GMT

It still does the same whenever i click enter i get double answer, and still my function shows overflow. God damn it :( Im starting to think that the code is not the problem but UART API is just not for strings.

RE: Basic password checker with uart

hmolesworth — Tue, 21 Nov 2023 16:28:13 GMT

So a classic problem of not completing the buffer by checking for a delimiter before processing. Typical fix would be to simply wait for the last expected character, cr or lf probably, before processing the response buffer.

// Indication that end-of-packet delimiter has been found
static bool mResponsePacketReadyToProcess = false;

    // Copy data into a separate buffer, excluding newline characters
    for (int i = 0; i < evt->data.rx.len; ++i)
    {
        if (evt->data.rx.buf[evt->data.rx.offset + i] != '\r' && evt->data.rx.buf[evt->data.rx.offset + i] != '\n')
        {
            received_line[line_index++] = evt->data.rx.buf[evt->data.rx.offset + i];
        }
        // Check end-of-packet delimiter, assume lf =='/n' for now
        if (evt->data.rx.buf[evt->data.rx.offset + i] == '\n')
        {
            mResponsePacketReadyToProcess = true;
        }
    }

 // Only process the buffer when the entire string has been received
 if (mResponsePacketReadyToProcess)
 {
    mResponsePacketReadyToProcess = false;
    // Null-terminate the string
    received_line[line_index] = '\0';
    printk("Received line: %s\n", received_line);
    // Process the received line as needed

RE: Basic password checker with uart

Dzolo2k1 — Tue, 21 Nov 2023 11:26:08 GMT

https://github.com/Dzolowski/ZephyrNRFBasics/tree/main/SecondEx thats the whole code,

RE: Basic password checker with uart

Dzolo2k1 — Tue, 21 Nov 2023 11:25:17 GMT

Oh its uart api, im still a newbie so i dont get all the questions :D And im using terminal from nrf toolchain cuz vsc sends only 1 char without pressing enter, if thats the case

RE: Basic password checker with uart

hmolesworth — Mon, 20 Nov 2023 20:27:26 GMT

Ah, no I mean where does the data originate? Is that an incoming BLE packet or is the buffer populated by (say) a serial uart? Both can have issues, depending on the originator particularly if that is a person. X-25 protocol, for example, can send bytes as they are typed over BLE (unlikely use case though)

RE: Basic password checker with uart

Dzolo2k1 — Mon, 20 Nov 2023 19:59:45 GMT

I guess its just evt->data.rx.buf[evt->data.rx.offset + i] its from data.rx.buf

RE: Basic password checker with uart

hmolesworth — Mon, 20 Nov 2023 19:09:45 GMT

Maybe a distraction, but where does the query come from? I ask since the nRF52 is effectively expecting a packet of characters, not single periodic characters. Termite on a PC will send "packets" typically when the Enter key is hit, but similar programs on a MAC (for example) will transit each key as it is hit so the stream is 'a' gap 'd' gap instead of "admin" gap.

RE: Basic password checker with uart

Dzolo2k1 — Mon, 20 Nov 2023 19:05:19 GMT

// There is rest of code i didnt send in previous answer
 printk("Received line: %s\n", received_line);

 // Process the received line as needed
 // (e.g., check if it equals "admin" and toggle LEDs)
 if (strcmp(received_line, "admin") == 0)
 {
 gpio_pin_toggle_dt(&led0);
 gpio_pin_toggle_dt(&led1);
 gpio_pin_toggle_dt(&led2);
 k_msleep(SLEEP_TIME_MS);
 
 }
 else
 {
 printk("Wrong input\n");
 }
 line_index = 0;
 free(received_line);
}

RE: Basic password checker with uart

Dzolo2k1 — Mon, 20 Nov 2023 19:04:20 GMT

I've changed my code a bit so it searches for /n /r in for but it still does the same. Len is 7/8 or 3/2 bytes depends :)

char *received_line = malloc(evt->data.rx.len + 1); // +1 na znak null-termination
 printk("Received %d bytes\n", evt->data.rx.len);
// Kopiowanie danych do received_line

// Po przetworzeniu danych

 int line_index = 0;

 // Copy data into a separate buffer, excluding newline characters
 for (int i = 0; i < evt->data.rx.len; ++i)
 {
 if (evt->data.rx.buf[evt->data.rx.offset + i] != '\r' && evt->data.rx.buf[evt->data.rx.offset + i] != '\n')
 {
 received_line[line_index++] = evt->data.rx.buf[evt->data.rx.offset + i];
 }
 }

 // Null-terminate the string
 received_line[line_index] = '\0';

 printk("Received line: %s\n", received_line);

RE: Basic password checker with uart

Sigurd Hellesvik — Mon, 20 Nov 2023 12:38:41 GMT

Hi,

Can you print "evt->data.rx.len"?

Where do your UART code come from? Do you base it on a sample?

Regards,
Sigurd Hellesvik