Adds HardwareSerial::setRxTimeout() #6397

gonzabrusco · 2022-03-08T20:46:03Z

Summary

Adds onReceiveTimeout() to HardwareSerial. Default value of the timeout is 10 symbols. This method allows the user to change the timeout on which the onReceive callback is called.
Before this change, the callback was called on 120 bytes always and then on timeout (when receiving more than 120 bytes). Now the callback gets called ONLY on timeout.

Impact

No impact. Everything should work as always.

Related links

No issue related. I did this modifications myself because on my modbus library I was seeing that on long messages (more than 120 bytes), the callbacks was getting called twice. Now it only calls for timeouts (of no receiving data).

gonzabrusco · 2022-03-09T14:58:11Z

More information about this.

I've tested this timeout on the oscilloscope and it's working as expected! 🎉🎉🎉

One consideration. If an overflow occurs, and then you don't process the data on the buffer with onReceiveError callback, then onReceive will never get called again. Maybe I should add a warning on the comments.

SuGlider · 2022-03-10T22:20:29Z

Thanks @gonzabrusco !
I'll review it soon.

TS6000 · 2022-03-12T16:53:02Z

Hello
I have big problems on UART2.
Since the change from 1.xx to 2.02 data is lost.
I work with Arduino Studio.

I use UART2 with the pins (GPIO) 12 and 13

Torsten

gonzabrusco · 2022-03-13T17:21:27Z

Hello I have big problems on UART2. Since the change from 1.xx to 2.02 data is lost. I work with Arduino Studio.

I use UART2 with the pins (GPIO) 12 and 13

Torsten

Hello @TS6000 . This is a Pull Request. Please create a new issue if you have one. But before creating one, take note that the UART code have changed a lot in the latest master. So please try again using master or wait for 2.0.3 version.

me-no-dev · 2022-03-14T10:54:25Z

cores/esp32/HardwareSerial.cpp

                        break;
                    case UART_FIFO_OVF:
                        log_w("UART%d FIFO Overflow. Consider adding Hardware Flow Control to your Application.", uart->_uart_nr);
                        if(uart->_onReceiveErrorCB) uart->_onReceiveErrorCB(UART_FIFO_OVF_ERROR);
+                        xQueueReset(uartEventQueue);


why lose all previous data?

I did this because it was like this on the previous UART task (before latest SuGlider commit). But maybe this could be ommited. The reason is that when you have a big overflow (overflowing multiple times the FIFO) the event queue gets filled with one UART_BUFFER_FULL and multiple UART_FIFO_OVF. I though it was redundant to be called multiple times for the same event.

This is what I was talking about:

arduino-esp32/cores/esp32/esp32-hal-uart.c

Line 117 in c014eaf

xQueueReset(uart->uart_event_queue);

arduino-esp32/cores/esp32/esp32-hal-uart.c

Line 123 in c014eaf

xQueueReset(uart->uart_event_queue);

If you think this should be deleted, I have no opposition.

I would rather discuss it, than just delete it :) @SuGlider want to pitch in an idea too?

Well, I guess this is a bit relative. It could happen that you have a very fast overflow and you will be called multiple times with the UART_FIFO_OVF event. But thinking about this more thoroughly, maybe that is not a "normal" or "frequent" situation. I added it back because I saw it on the original esp32-hal-uart code and when I was testing the overflow with the serial monitor, I noticed that behaviour. But as I said, probably is not a frequent situation and you could eventually lose something important on the event queue? (maybe an UART_DATA event after an overflow event?). Probably this should be deleted. But I will let @SuGlider give this opinion about this. I would love to have this on 2.0.3 because I will be using that version as the new core for my project (2.0.2 has many bugs with UART).

@gonzabrusco - about your consideration:

One consideration. If an overflow occurs, and then you don't process the data on the buffer with onReceiveError callback, then onReceive will never get called again.

It is a real problem for most Arduino users.
onReceive Callback should be called also when RX FIFO is full and UART driver copies that data to the RX ringbuffer.
I think it should pass a parameter to the call back function informing if there was a Timeout instead of forcing only calling it when timeout occurs. This way the user can decide what to do in the callback and it is more flexible.

Regarding xQueueReset(uart->uart_event_queue); , it shall be removed from the task.
I suggest that it may become a new function such as eventQueueReset() in HardwareSerial API.
This way users can decide when to reset the queue instead of forcing it in the task loop.

Last suggestion is about changing the name of the function void HardwareSerial::onReceiveTimeout(uint8_t symbols_timeout) to void HardwareSerial::setOnReceiveTimeout(uint8_t symbols_timeout) or some name like setRxTimeout().

Timeout mode shall not be forced in the code... it shall be an option. check

// from void HardwareSerial::onReceiveTimeout(uint8_t symbols_timeout) ::: if(symbols_timeout == 0) { _onReceiveTimeout = 1; // Never disable timeout }

// from void HardwareSerial::begin(...) ::: // Set UART RX timeout if (_uart != NULL && _onReceiveCB != NULL) { uart_set_rx_timeout(_uart_nr, _onReceiveTimeout); }

// from void HardwareSerial::_uartEventTask(void *args)) ::: "&& event.timeout_flag" case UART_DATA: if(uart->_onReceiveCB && uart->available() > 0 && event.timeout_flag) uart->_onReceiveCB(); break;

me-no-dev · 2022-03-14T10:54:39Z

cores/esp32/HardwareSerial.cpp

                        break;
                    case UART_BUFFER_FULL:
                        log_w("UART%d Buffer Full. Consider encreasing your buffer size of your Application.", uart->_uart_nr);
                        if(uart->_onReceiveErrorCB) uart->_onReceiveErrorCB(UART_BUFFER_FULL_ERROR);
+                        xQueueReset(uartEventQueue);


same question as above.

Same answer.

xQueueReset(uartEventQueue); could go on a API function just for that, such as void HardwareSerial::eventQueueReset().

This way the sketch can decide when to flush the events.
Please remove it.

SuGlider · 2022-03-20T14:57:45Z

Before this change, the callback was called on 120 bytes always and then on timeout (when receiving more than 120 bytes). Now the callback gets called ONLY on timeout.

Yes, this is correct, onReceive Callback will be called right after 120 bytes or less.
This PR creates an alternative for getting called back after Timeout in Symbol baudrate timing.

I got confused with the Function Name onReceiveTimeout() makes me think about setting a callback function and not a timeout parameter. I think it can be changed to setRxTimeout().

I will review the code and reseach about the implications, given that it may affect basic functions such as read() for instance.
Thus, it may take a bit longer.

gonzabrusco · 2022-03-20T16:29:59Z

Before this change, the callback was called on 120 bytes always and then on timeout (when receiving more than 120 bytes). Now the callback gets called ONLY on timeout.

Yes, this is correct, onReceive Callback will be called right after 120 bytes or less. This PR creates an alternative for getting called back after Timeout in Symbol baudrate timing.

Hi @SuGlider. About this, Now the onReceive Callback gets called on 10 symbol time UART silence by default (because it's IDF default) or 120 bytes received. This callback just allows you to set the callback timeout (because for example modbus has an interframe delay of 3.5 symbols) and disables the redundant call every 120 bytes (is that really needed?). That way you can be called only when all the data was already received (and not in the middle of the reception for messages longer than 120 bytes). A Modbus frame could be as long as 255 bytes for example.

The other alternative is to inform the onReceive callback if the callback was produced because of a timeout or because 120 bytes were received. That way the callback can be able to discern between the two and take different actions.

I got confused with the Function Name onReceiveTimeout() makes me think about setting a callback function and not a timeout parameter. I think it can be changed to setRxTimeout().

I will review the code and reseach about the implications, given that it may affect basic functions such as read() for instance. Thus, it may take a bit longer.

No problem about the name change. I just gave it that name because it was the timeout on which onReceive callback will be called. Take you time if you need to (although I would love this to be available on 2.0.3 which I will use for my project). About the implications on other functions, I'm not so sure if there is any. This just sets the timeout for the event UART_DATA. Not sure how this could affect other functions like read().

SuGlider

Please review all the suggestions. Thanks!

SuGlider · 2022-03-21T14:50:36Z

cores/esp32/HardwareSerial.cpp

+    HSERIAL_MUTEX_UNLOCK();
+}
+
+void HardwareSerial::onReceiveTimeout(uint8_t symbols_timeout)


Suggestion: change name to something like setOnReceiveTimeout() or setRxTimeout()

SuGlider · 2022-03-21T14:51:29Z

cores/esp32/HardwareSerial.cpp

+    HSERIAL_MUTEX_LOCK();
+
+    if(symbols_timeout == 0) {
+        _onReceiveTimeout = 1; // Never disable timeout


I think timeout shall not be enforced. Let the user decide to disable it by setting it to 0.

SuGlider · 2022-03-21T14:54:26Z

cores/esp32/HardwareSerial.cpp

@@ -128,7 +128,8 @@ HardwareSerial::HardwareSerial(int uart_nr) :
 _uart_nr(uart_nr), 
 _uart(NULL), 
 _rxBufferSize(256), 
-_onReceiveCB(NULL), 
+_onReceiveCB(NULL),
+_onReceiveTimeout(10),


I think it shall have as default value ZERO. Disabled. This way it may be enabled using the API.
This will force other changes in the code, mainly because of issues with RX Overflow.
When RX overflow happens, IDF driver disables RX Timeout interrupt flag!
Thus, onReceive will never be called again and the queue will continue full.

This is the only thing I disagree. By default now (as before my pull request), onReceive callback is being called by timeout (10 symbos by default) or by rx fifo full (120 bytes). That is the standard behaviour by IDF. I don't think that Arduino core should use another default. I would prefer to let the timeout on because if you receive 119 bytes, you will never get called (unless you receive on more byte that will trigger UART_INTR_RXFIFO_FULL interrupt)

SuGlider · 2022-03-21T14:56:50Z

cores/esp32/HardwareSerial.cpp

@@ -210,15 +228,17 @@ void HardwareSerial::_uartEventTask(void *args)
            if(xQueueReceive(uartEventQueue, (void * )&event, (portTickType)portMAX_DELAY)) {
                switch(event.type) {
                    case UART_DATA:
-                        if(uart->_onReceiveCB && uart->available() > 0) uart->_onReceiveCB();
+                        if(uart->_onReceiveCB && uart->available() > 0  && event.timeout_flag) uart->_onReceiveCB();


I think it shall not force testing timeout_flag in order to activate the callback.
Set it as a parameter to the callback function and let the application decide what to do with this informtation.
It also create issues when the IDF ringbuffer is full!

Ok. I will pass the timeout flag as a parameter to the callback.

SuGlider · 2022-03-21T14:58:41Z

cores/esp32/HardwareSerial.cpp

+    if (_uart != NULL && _onReceiveCB != NULL) {
+        uart_set_rx_timeout(_uart_nr, _onReceiveTimeout);
+    }
+


This shall not be here. It shall be only in the setRxTimeout(...) API function.
It is enforcing timeout usage to the sketch. That shall be optional.

As I said before. The timeout behaviour is the default as per IDF (10 symbols defined in UART_TOUT_THRESH_DEFAULT). I think this is needed because the user could call setRxTimeout before or after the begin() . This is the same principle as you took with onReceive(). This is because uart_set_rx_timeout should be called once the uart is initialized.

OK. I agree. Let's set the default always.

cores/esp32/HardwareSerial.h

SuGlider · 2022-03-21T15:01:18Z

cores/esp32/HardwareSerial.h

@@ -138,6 +150,7 @@ class HardwareSerial: public Stream
    uart_t* _uart;
    size_t _rxBufferSize;
    OnReceiveCb _onReceiveCB;
+    uint8_t _onReceiveTimeout;


this may not be necessary to exist anymore as per the suggestions already made here.

I will stress my previous comments here. Because you need to call uart_set_rx_timeout after the uart initialization, then I need a local variable to store my timeout config in case setRxTimeout was called before begin().

gonzabrusco · 2022-03-21T20:08:41Z

I commited the requested changes but I'm still testing it. Please wait before reviewing again. @SuGlider

gonzabrusco · 2022-03-22T12:03:20Z

This is ready for review again. I'm not sure if I should mark "Resolved" all previous conversations. @SuGlider

Here´s a simple sketch to test this.

#include <Arduino.h>

void receiveFnc(bool timeout) {
    if(timeout) {
        Serial.printf("Received Data UART RX TIMEOUT. Available For Reading = %u\n", Serial.available());
    }
    else {
        Serial.printf("Received Data UART RX FIFO FULL. Available For Reading = %u\n", Serial.available());
    }
    while(Serial.available()) Serial.read(); // Discard received data.
}

void receiveErrorFnc(hardwareSerial_error_t error){
    Serial.print("UART Reception Error: ");
    switch(error) {
        case UART_BREAK_ERROR:
            Serial.println("UART_BREAK_ERROR");
            break;
        case UART_BUFFER_FULL_ERROR:
            Serial.println("UART_BUFFER_FULL_ERROR");
            break;
        case UART_FIFO_OVF_ERROR:
            Serial.println("UART_FIFO_OVF_ERROR");
            break;
        case UART_FRAME_ERROR:
            Serial.println("UART_FRAME_ERROR");
            break;
        case UART_PARITY_ERROR:
            Serial.println("UART_PARITY_ERROR");
            break;
    }
}

void setup() {
    // Setting UART Ring Buffer to 512 bytes
    Serial.setRxBufferSize(512);

    // Define UART Reception Callback
    Serial.onReceive(receiveFnc);
    
    // Define UART Error Callback
    Serial.onReceiveError(receiveErrorFnc);
    
    // Set RX Timeout. 
    // If set to 0, onReceive callback will only be called every 120 bytes.
    // If set to more then 0, onReceive callback will be called every 120 bytes or timeout (with less than 120 bytes)
    Serial.setRxTimeout(5);
    
    // Serial speed 9600 symbos per second
    Serial.begin(9600);
}

void loop() {
    // Nothing to do
}

check if _uart is not NULL before using it.

SuGlider

Thanks @gonzabrusco !
~~I just added a NULL test to eventQueueReset(), in case it is called before Serial.begin(), which can reset the board.~~
(No need for it - reverted)

gonzabrusco · 2022-03-22T18:35:46Z

Thanks @gonzabrusco ! I just added a NULL test to eventQueueReset(), in case it is called before Serial.begin(), which can reset the board.

Nice catch!

What is the etiquete here in Espressif repositories about "conversations"? Should I mark them resolved or wait for @me-no-dev or you to resolve them? Don't want to make a mess...

reverting last change made - it is not necessary.

SuGlider · 2022-03-22T18:51:20Z

Thanks @gonzabrusco ! I just added a NULL test to eventQueueReset(), in case it is called before Serial.begin(), which can reset the board.

Nice catch!

Actually, that change was not necessary because the function to get the queue already tests it. So I reverted the commit.

What is the etiquete here in Espressif repositories about "conversations"? Should I mark them resolved or wait for @me-no-dev or you to resolve them? Don't want to make a mess...

I'll run a final testing sequence here and then I'll post a message to me-no-dev asking for his final review.

Thanks for the PR!

In order to allow the user to choose if onReceive() call back will be called only when UART Rx timeout happens or also when UART FIFO gets 120 bytes, a new parameter has been added to onReceive() with the default behavior based on timeout. void onReceive(OnReceiveCb function, bool onlyOnTimeout = true); onReceive will setup a callback that will be called whenever an UART interruption occurs (UART_INTR_RXFIFO_FULL or UART_INTR_RXFIFO_TOUT) UART_INTR_RXFIFO_FULL interrupt triggers at UART_FULL_THRESH_DEFAULT bytes received (defined as 120 bytes by default in IDF) UART_INTR_RXFIFO_TOUT interrupt triggers at UART_TOUT_THRESH_DEFAULT symbols passed without any reception (defined as 10 symbos by default in IDF) onlyOnTimeout parameter will define how onReceive will behave: Default: true -- The callback will only be called when RX Timeout happens. Whole stream of bytes will be ready for being read on the callback function at once. This option may lead to Rx Overflow depending on the Rx Buffer Size and number of bytes received in the streaming false -- The callback will be called when FIFO reaches 120 bytes and also on RX Timeout. The stream of incommig bytes will be "split" into blocks of 120 bytes on each callback. This option avoid any sort of Rx Overflow, but leaves the UART packet reassembling work to the Application.

SuGlider · 2022-03-24T22:55:20Z

@gonzabrusco

I have tested this PR and also the last PR #6364
I see no difference now...

Running the example sketch, but removing the bool timeout from void receiveFnc(bool timeout) and also removing the new function Serial.setRxTimeout(5);, I got exactly the same results, but it just can't know if the data came because of timeout or FIFO Full.

I think that your intention was to only get called back when timeout happens, right?
This way the RingBuffer can hold all data at once and the callback can process it on a single call.

I have changed this PR to reflect this intention, which in fact is better for the user, as you have suggested.

New way of doing it:

#include <Arduino.h>

void receiveFnc() {
    Serial.printf("Received UART Data. Available For Reading = %u\n", Serial.available());
    while(Serial.available()) Serial.read(); // Discard received data.
}

void receiveErrorFnc(hardwareSerial_error_t error){
    Serial.print("UART Reception Error: ");
    switch(error) {
        case UART_BREAK_ERROR:
            Serial.println("UART_BREAK_ERROR");
            break;
        case UART_BUFFER_FULL_ERROR:
            Serial.println("UART_BUFFER_FULL_ERROR");
            break;
        case UART_FIFO_OVF_ERROR:
            Serial.println("UART_FIFO_OVF_ERROR");
            break;
        case UART_FRAME_ERROR:
            Serial.println("UART_FRAME_ERROR");
            break;
        case UART_PARITY_ERROR:
            Serial.println("UART_PARITY_ERROR");
            break;
    }
}

void setup() {
    // Setting UART Ring Buffer to 512 bytes
    Serial.setRxBufferSize(512);

    // Define UART Reception Callback
    Serial.onReceive(receiveFnc);   // default is being called on UART RX timeout
    // in order to be called when RX FIFO reaches 120 bytes or when RX timeout(with less than 120 bytes), 
    // set the callback in this way:
    // Serial.onReceive(receiveFnc, false); 
    
    // Define UART Error Callback
    Serial.onReceiveError(receiveErrorFnc);
    
    // Serial speed 9600 symbos per second
    Serial.begin(9600);
}

void loop() {
    // Nothing to do
}

Please let me know if you agree to these changes I have commited to your PR.
Thanks again!

SuGlider · 2022-03-24T23:11:27Z

@gonzabrusco
I think that removing most funtion and only adding a parameter to tell to onReceive() if it should consider only timeout or the combinations of timeout and FIFO with 120 bytes gets back to what was the initial intention of this PR.

No need to setRxTimeout because it already works as intended. This may be confusing for the regular Arduino user.

eventQueueReset() may be useful, so let's keep it.

Testing the example I have added here above, the user can decide in an easy way if the callback shall work only on timeout or when blocks of 120 bytes or timeout happens. It is flexible and simple.

Please let me know your thoughts.

gonzabrusco · 2022-03-25T06:10:21Z

Hi @SuGlider . Thanks for the changes in the PR but unfortunately I have to disagree on the decision to remove setRXTimeout which was the primary goal of this PR.

The reason I needed this method is to be able to set correctly the timeout (in symbols) in which my callback was going to be called. This is CRITICAL on modbus over RS485 because you HAVE TO process any message in the bus in exactly 3.5 symbols time. If you process the buffer in 10 symbols time (like IDF default), you are arriving too late and you could end up seeing one master request and one slave response joined as a single message.

You can see that LIBMODBUS on IDF sets this timeout to 3 for example (using the same function I was using on the first place uart_set_rx_timeout).

I agree with your changes but please revert the removal of setRXTimeout. This is needed for Arduino power users!

PD: This is whay I was talking about in libmodbus: https://github.com/espressif/esp-idf/blob/a5227db2a75102ca1a17860188c3c352a529a01b/components/freemodbus/port/portserial_m.c#L244

SuGlider · 2022-03-25T11:54:15Z

@gonzabrusco
I have added setRxTimeout() to the PR as you have suggested and done before.
I just added some checks to keep onReceive() safe and working even when user sets timeout to zero or uses this function when timeout was set to zero, in any order that both are called.

Please let me know if you also agree to this changes in order to start merging process.

gonzabrusco · 2022-03-25T12:05:16Z

@gonzabrusco I have added setRxTimeout() to the PR as you have suggested and done before. I just added some checks to keep onReceive() safe and working even when user sets timeout to zero or uses this function when timeout was set to zero, in any order that both are called.

Please let me know if you also agree to this changes in order to start merging process.

I loved the changes. Thanks!

SuGlider · 2022-03-25T18:35:10Z

@me-no-dev - This PR is ready for merging, just waiting for your final review.

me-no-dev · 2022-03-28T08:38:55Z

@gonzabrusco @SuGlider here seems to be a conflict now. Please fix

SuGlider · 2022-03-28T10:53:50Z

Conflict solved. Thanks.

github-actions · 2022-03-28T10:53:59Z

Unit Test Results

0 files 0 suites 0s ⏱️
0 tests 0 ✔️ 0 💤 0 ❌

Results for commit e67d1d2.

♻️ This comment has been updated with latest results.

Adds HardwareSerial::onReceiveTimeout()

af0dabe

SuGlider self-assigned this Mar 8, 2022

SuGlider self-requested a review March 8, 2022 23:37

Merge branch 'master' into uart_onreceive_timeout

ffe0882

me-no-dev reviewed Mar 14, 2022

View reviewed changes

gonzabrusco and others added 2 commits March 14, 2022 08:34

Fixed typo

fa717e7

Merge branch 'master' into uart_onreceive_timeout

22c5c71

SuGlider added Type: Feature request Feature request for Arduino ESP32 Status: In Progress ⚠️ Issue is in progress Area: Peripherals API Relates to peripheral's APIs. labels Mar 17, 2022

SuGlider requested changes Mar 21, 2022

View reviewed changes

gonzabrusco added 2 commits March 21, 2022 15:26

Merge branch 'espressif:master' into uart_onreceive_timeout

fbc0734

Changes requested

951ad87

gonzabrusco added 3 commits March 21, 2022 17:13

Fix eventQueueReset

8db2400

Changed _onReceiveTimeout to _rxTimeout for consistency

1aff6b1

Uniform uart_set_rx_timeout condition

42fe78f

gonzabrusco requested a review from SuGlider March 22, 2022 14:15

test _uart not NULL in eventQueueReset()

83ff56d

check if _uart is not NULL before using it.

SuGlider approved these changes Mar 22, 2022

View reviewed changes

SuGlider changed the title ~~Adds HardwareSerial::onReceiveTimeout()~~ Adds HardwareSerial::setRxTimeout() Mar 22, 2022

revert last commit - no need for it

be50818

reverting last change made - it is not necessary.

SuGlider added 3 commits March 24, 2022 19:38

Merge branch 'master' into uart_onreceive_timeout

281ae37

Adds onReceive() parameter for timeout only

d5de62c

SuGlider added this to the 2.0.3 milestone Mar 24, 2022

SuGlider added 2 commits March 25, 2022 08:45

Adds back setRxTimeout()

c1b08e8

Adds setRxTimeout()

20ecdae

Merge branch 'master' into uart_onreceive_timeout

5574fc4

CI Syntax error - "," missing

e67d1d2

me-no-dev merged commit c26e3f4 into espressif:master Mar 28, 2022

gonzabrusco deleted the uart_onreceive_timeout branch May 4, 2022 12:43

SuGlider mentioned this pull request May 6, 2022

UART Performance issues with 2.0.2 version #6689

Closed

Adds HardwareSerial::setRxTimeout() #6397

Adds HardwareSerial::setRxTimeout() #6397

Conversation

gonzabrusco commented Mar 8, 2022 • edited Loading

Summary

Impact

Related links

gonzabrusco commented Mar 9, 2022 • edited Loading

SuGlider commented Mar 10, 2022

TS6000 commented Mar 12, 2022

gonzabrusco commented Mar 13, 2022

Choose a reason for hiding this comment

gonzabrusco Mar 14, 2022 • edited Loading

Choose a reason for hiding this comment

gonzabrusco Mar 14, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SuGlider commented Mar 20, 2022 • edited Loading

gonzabrusco commented Mar 20, 2022

SuGlider left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gonzabrusco Mar 21, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gonzabrusco commented Mar 21, 2022

gonzabrusco commented Mar 22, 2022 • edited Loading

SuGlider left a comment • edited Loading

Choose a reason for hiding this comment

gonzabrusco commented Mar 22, 2022

SuGlider commented Mar 22, 2022

SuGlider commented Mar 24, 2022

SuGlider commented Mar 24, 2022

gonzabrusco commented Mar 25, 2022 • edited Loading

SuGlider commented Mar 25, 2022

gonzabrusco commented Mar 25, 2022

SuGlider commented Mar 25, 2022

me-no-dev commented Mar 28, 2022

SuGlider commented Mar 28, 2022

github-actions bot commented Mar 28, 2022 • edited Loading

Unit Test Results

gonzabrusco commented Mar 8, 2022 •

edited

Loading

gonzabrusco commented Mar 9, 2022 •

edited

Loading

gonzabrusco Mar 14, 2022 •

edited

Loading

gonzabrusco Mar 14, 2022 •

edited

Loading

SuGlider commented Mar 20, 2022 •

edited

Loading

gonzabrusco Mar 21, 2022 •

edited

Loading

gonzabrusco commented Mar 22, 2022 •

edited

Loading

SuGlider left a comment •

edited

Loading

gonzabrusco commented Mar 25, 2022 •

edited

Loading

github-actions bot commented Mar 28, 2022 •

edited

Loading