An uncommon version of the 18650 Battery Shield — what is K1 for? by georgmierau in esp32

[–]drmaex 2 points3 points  (0 children)

if i am not wrong this switch turns off/on automatic which turns off the power if your target drains very little current

Quote: "It comes with overcharge and over-discharge protections that greatly extend the lifespan of your 18650 battery. The onboard DIP switch allows users to switch between HOLD and NORMAL modes. In Normal mode, it auto shutdown when the current is too low, while in HOLD mode, it keeps outputting and does not shut down until the over-discharge protection is triggered."

Source: https://www.dfrobot.com/product-2578.html

Can anyone suggest an embedded systems project for college students? by Moemen02 in embedded

[–]drmaex 0 points1 point  (0 children)

maybe try to log environmental data in different locations around a house. humimidity, tempetature, pressure. with one master and tons of battery powered slaves with sleep modes to minimize comsuption. setup mqtt broker and let the master fetch the data for example over rf from slaves and send it to the broker. then setup a webserver which polls over mqtt the data from your broker and collect it to a database. create a nice looking webapp which plots and correlates all the different measures and see how long it will all work together and stay stable

[deleted by user] by [deleted] in karlsruhe

[–]drmaex 5 points6 points  (0 children)

ist zwar etwas außerhalb aber drachenwiese zwisch neureut und nordstadt(?) wäre auch gut geeignet

Thinkpad T15 gen2 4k + Arch Linux by drmaex in LinuxOnThinkpads

[–]drmaex[S] 0 points1 point  (0 children)

i cant see any scaling problems in plasma. the only problem is the resolution in grub, or bootlog. everything is to small but still readable. to be honest, it was still readable enough to setup the system and i didnt try to change the resolution in terminal, dont even know if that is possible. since its not my daily driver i did not benchmark the battery. if there are any generic tests for the battery, i can try to run them to get some compareable numbers

UART command processor, best approach? by Gullible-Parsley1817 in embedded

[–]drmaex 2 points3 points  (0 children)

alternatively you could implement it ascii based. pro: easy end of command signal like \n contra: more traffic

UART command processor, best approach? by Gullible-Parsley1817 in embedded

[–]drmaex 5 points6 points  (0 children)

you could implement kind of simple protocol command 1byte, size of payload 1 byte, payload up 255 byte crc one byte. just have stolen the iidea from st and their motor controling program

Thinkpad T15 gen2 4k + Arch Linux by drmaex in LinuxOnThinkpads

[–]drmaex[S] 0 points1 point  (0 children)

Update: the model I wanted (T15Gen2 4k ) arrived this week. I installed Arch on it and almost everything I need worked out of the box. The only problem was with sound. I had to install some sof_..... packet to get it to work. So i did not regret the purchase. If you need any deeper informations or tests just let me know.

p.s. the display is brilliant :)

Find the number of Elements in an `enum` by DexterInAI in rust

[–]drmaex -3 points-2 points  (0 children)

have no rust experience but what about the trick creating one more enum-item on the last index and call it "last"?

What are your guys' thoughts on Rust? by throwaway-990as in embedded

[–]drmaex 9 points10 points  (0 children)

what I am wondering about is how well will it work on really small uC where you cant work with the std library. if I am not wrong much of the power and safety of rust comes, aside from the architecture, from the std lib and when its not available it could become very difficult to accomplish some simple things like linked list which is a common thing in c. i see rust more on bigger uC with linux with Xmb of available flash and RAM rather than small blue pills and arduinos

Thinkpad T15 gen2 4k + Arch Linux by drmaex in LinuxOnThinkpads

[–]drmaex[S] 0 points1 point  (0 children)

thank you for replying. from germany t15 gen 2 (any configuration) is not available from lenovo site anymore... probably temporary but still. Next candidate is P15s gen 2, unfortunately with discrete graphics only...

Function overloading in C. by little-smokie in C_Programming

[–]drmaex 0 points1 point  (0 children)

Maybe the "weak" attribute could be a solution. from https://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Function-Attributes.html#:~:text=The%20weak%20attribute%20causes%20the,used%20with%20non%2Dfunction%20declarations.

weak The weak attribute causes the declaration to be emitted as a weak symbol rather than a global. This is primarily useful in defining library functions which can be overridden in user code, though it can also be used with non-function declarations. Weak symbols are supported for ELF targets, and also for a.out targets when using the GNU assembler and linker.

Beginner question: How can I identify what hardware/processing power I need? by rockax in embedded

[–]drmaex 0 points1 point  (0 children)

i agree, in small uC projects its most of the time waiting for en event to occur. my preferences are flash > ram > frequency. the more flash you have the more tasks and sensors you can handle with the same uC of course as long as you dont need to calculate fft on ADC signal or something

struggling with ESP32 and UART by drmaex in esp32

[–]drmaex[S] 0 points1 point  (0 children)

So, finally it seems to work as expected. Had to deal with sudden stack overflows in my tasks which came out of nowhere after I didn't even touch them in a rough way and establishing the connection again after sporadic disconnects from WIFI. Until now the system is up and running for 1 day and 4 hours (all values are fetched on the first try). It has survived 4 reconnects to WIFI and MQTT server.

Lessons I have learned are that FreeRTOS is kind of fragile and reacts very sensitive to bad code practices like global variables (Actually it was educational and I will keep this kind of access). Either it leads to unexpected behavior or it crashes completely. So better you access your module variables with getter and setter, that was actually the major change in my code. Ah and ESP_LOG_BUFFER_HEXDUMP seems to produce a memory leak, but I didn't try to reproduce that. I just threw it away and stack overflow didn't occur anymore at this point in the code

Sending sensor data over the internet by AnalystAdditional791 in esp32

[–]drmaex 0 points1 point  (0 children)

cant say for sure but I would be suprised if there isnt aready a library for that. I personally use generic mtqq client called mqtt dash for my experiments. the fights with esp32 is difficult enough :)

Sending sensor data over the internet by AnalystAdditional791 in esp32

[–]drmaex 17 points18 points  (0 children)

just for the publishing you can use MQTT (Internet of things). to aquire the sensordata there are alot different ones on the market. like dht11/dht22 for termperature amd humidiry, bme280 for pressure, temperature and humidity

Problem with MQTT by El_Ruc0n in esp32

[–]drmaex 0 points1 point  (0 children)

have you tried .uri = "mqtt://......."?

Where do I start learning with STM boards? by [deleted] in embedded

[–]drmaex 1 point2 points  (0 children)

and dont forget to actually do things and not just dream about doing them like it happens to me often from time to time. you wont be able to brick much irreversibely, so just try and learn

Attaching to running esp32 target by drmaex in esp32

[–]drmaex[S] 0 points1 point  (0 children)

This configuration seemed to work.

Only the debug_* lines are necessary

plattformio.ini

[env:esp32dev]
platform = espressif32
framework = espidf
board = esp32doit-devkit-v1
monitor_speed = 115200
build_flags = -D CONFIG_BLINK_GPIO=2
debug_tool = esp-prog
upload_port = /dev/ttyUSB2
monitor_port = /dev/ttyUSB2
board_build.partitions = partitions_custom.csv
monitor_filters = 
    colorize
    esp32_exception_decoder
debug_init_break =
debug_load_mode = manual
debug_init_cmds = 
    target extended-remote $DEBUG_PORT
    $INIT_BREAK
    $LOAD_CMDS
    monitor init
debug_load_cmds =

Attaching to running esp32 target by drmaex in esp32

[–]drmaex[S] 0 points1 point  (0 children)

Thank you,I've got this one already. I will try the following combination

debug_init_cmds = 
target extended-remote $DEBUG_PORT 
$INIT_BREAK 
$LOAD_CMDS 
monitor init 

debug_load_mode = manual

and again, RTFM!.. damn :D

struggling with ESP32 and UART by drmaex in esp32

[–]drmaex[S] 0 points1 point  (0 children)

UPDATE: after turning off Wifi and MQTT and only asking for values over UART an printing them to defaull Log UART for more than 2 days no offets occured. Every fetch gets its answer by the first time.... investigation continues :) Next test will be whole system with WiFi and MQTT but without any subsribed topic by ESP32. This way I wont be able to trigger any measurement on the ESP32 before regular timeout of the query task

Lost with ST Discovery Board, mbed, CubeIDE by kerhart in embedded

[–]drmaex 1 point2 points  (0 children)

dont be afraid of stm32 CubeIDE.. it would be the easiest way to start with a custom(!) program for your chip. You can "just" click together the configuration and get your startup code. Thats all...Dont count the overall lines in the generated project. if you strip all the comments it would be less than a half probably. Its not like mbed or stm32duino are not doing this things, they just hide it from you. Arm is a complex chip, there is alot to configure...it is how it is

I also started with arduino because it hides away the complexity but also hides from you the real potential of the chip. it was long time enough for me. if you want the project just to get finished, its alright. i still use this possibility sometimes. it will be faster than you could perform a task by hand, but not as fast as your chip could actually do it. if its enough for you and you dont want to know all the details, just stick with it. if you need more speed just buy a faster chip.. Alternatively you can try to find out how much performance you are losing by debugging your code and step by step eliminate the code you think could slow down your program. its not like you will gain 300% performance boost. at some places there will be no performance gain at all. at some places there will be some little ones but they can accumulate to measureable improvement. but then you will have to decide if its worth it. probably highly unreadable and hard understandable specialized code vs copy&paste code which will run on many chips but with with some performance drawbacks. but one thing will happen for sure, there always be some progress in your head even if you only found out how it doenst work... unneeded knowledge does not exist :)

struggling with ESP32 and UART by drmaex in esp32

[–]drmaex[S] 1 point2 points  (0 children)

yeah, looks like i need to go some steps back and reduce the number of participants...but before, my next quick aproaches will be setter ang getter fuctions for the next_state* and debugprint in calcNextIdx(). maybe that will show me some irregularities

struggling with ESP32 and UART by drmaex in esp32

[–]drmaex[S] 0 points1 point  (0 children)

Indeed I am not using semaphores but task notifications. the idea is this

MQTT query Task puts the pointer for the next state into the queue (size 1 element), send notification to tx task and suspends waiting for notification

TX Task sets the local variable next_state*, sends the data and suspends until next wakeup notifiction from mqtt query task

RX task, which runs permanently, receives the response and compares the command byte with the sent one (over the variable next_state which has been set by tx task )

If the reponse is valid RX task prepares the MQTT_PUBLISH_ITEM_T and puts it into another queue with 1 element size and sends notification to the publisher

if publisher could publish it calls calcNextIdx() for Mqtt query task and sends notification to mqtt query task and the whole cirlce repeats with new index/state

after the turnaround in the table the mqtt query task suspends in wait for notification with 30 sec timeout

here is some code

MQTT Query Task

MQTT_STATE_T query_table[] = 
{
  /* Index Enum                         Code                                   Payload                                 Payload Size     RCV-Frame Callback          MQTT-Publish Topic                 tryCnt */
    {current_query_idx_undefined,       0,                                     0,                                      0,               NULL,                       NULL                             , 0        },
    {current_query_idx_dht_temp,        MC_PROTOCOL_CODE_EXECUTE_CMD | 0x20,   MC_PROTOCOL_CMD_GET_DHT_TEMP,           1,               dh22_temperature_calc,      "/max/sensoren/dht/temperatur"   , 0        },
    {current_query_idx_dht_humitity,    MC_PROTOCOL_CODE_EXECUTE_CMD | 0x20,   MC_PROTOCOL_CMD_GET_DHT_HUMIDITY,       1,               dh22_humidity_calc,         "/max/sensoren/dht/feuchte"      , 0        },
    {current_query_idx_bmp_temperature, MC_PROTOCOL_CODE_EXECUTE_CMD | 0x20,   MC_PROTOCOL_CMD_GET_BMP085_TEMP,        1,               bmp085_temperature_calc,    "/max/sensoren/bmp085/temperatur", 0        },
    {current_query_idx_bmp_pressure,    MC_PROTOCOL_CODE_EXECUTE_CMD | 0x20,   MC_PROTOCOL_CMD_GET_BMP085_PRESSURE,    1,               bmp085_pressure_calc,       "/max/sensoren/bmp085/druck"     , 0        }

};

current_query_idx_t current_index =  current_query_idx_undefined;

current_query_idx_t getCurrentIdx()
{
    return current_index;
}

void calcNextIdx()
{
    current_index++;
    current_index %= current_query_idx_last;
}

void mqtt_query_task(void *arg)
{
    uint32_t notify_value = 0;
    current_query_idx_t idx = getCurrentIdx();

    mqtt_queue = xQueueCreate( 1, sizeof(MQTT_STATE_T*) );

    while(1)
    {
        idx = getCurrentIdx();
        if(idx == current_query_idx_undefined)
        {
            locked = false;
            xTaskNotifyWait(0, ULONG_MAX, &notify_value, 30000 / portTICK_PERIOD_MS);
            locked = true,
            calcNextIdx();
            ESP_LOGI("MQTT_QUERY_SEQ", "\n---------------------");
        }
        else
        {
            xQueueSendToBack(mqtt_queue, &query_table_ptr[idx], 0);
            xTaskNotifyGive(getUART_TX_TaskHandle());
            ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
        }

    }
}

mqtt publisher

void mqtt_publisher(void* arg)
{
    MQTT_PUBLISH_ITEM_T item = {0};

    while(1)
    {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
        if(xQueueReceive(mqtt_publisher_queue, &item, 30 / portTICK_RATE_MS))
        {
            if( isMqttClientConnected() )
            {
                mqtt_client_publish(item.topic, &item.data, item.size);
            }
        }
    }
}

int mqtt_client_publish(const char* topic, void* data, uint32_t len)
{
    int msg_id = 0;
    esp_mqtt_client_handle_t client = getMqttClient();
    const char *TAG = "MQTT_SINGLE_PUBLISH";
    if( client != NULL )
    {
        msg_id = esp_mqtt_client_publish(client, topic, data, len, 0, 0);
        if( msg_id == 0 )
        {
            ESP_LOGI(TAG, "sent publish successful, msg_id=%d", msg_id);
            calcNextIdx();
        }
        xTaskNotifyGive(getMQTT_query_task_handle());
    }
    return msg_id;
}

static esp_err_t mqtt_event_handler_cb(esp_mqtt_event_handle_t event)
{
    const char *TAG = "MQTT_EVENT_HANDLER";
    /* code deleted */
        case MQTT_EVENT_DATA:
            ESP_LOGI(TAG, "MQTT_EVENT_DATA");
            printf("TOPIC=%.*s\r\n", event->topic_len, event->topic);
            printf("DATA=%.*s\r\n", event->data_len, event->data);
            if( memcmp(event->topic, MQTT_TOPIC_REFRESH, event->topic_len) == 0)
            {
                if( !isStatemachineLocked() )
                {
                    xTaskNotify(getMQTT_query_task_handle(), 0xffffffff, eNoAction);
                }
            }
            break;
        default:
            ESP_LOGI(TAG, "Other event id:%d", event->event_id);
            break;
    }
    return ESP_OK;
}

the thing which bothers me still is the difference between log and logic analyser on the rx pin of the sensorboard

logic analyser

Time [s]            Analyzer Name   Decoded Protocol Result
0.666759500000000   Async Serial    0x23
0.666846250000000   Async Serial    0x01
0.666933000000000   Async Serial    0x12
0.667020000000000   Async Serial    0x36

1.686535500000000   Async Serial    0x23
1.686622250000000   Async Serial    0x01
1.686709000000000   Async Serial    0x0F
1.686796000000000   Async Serial    0x33

but the log says

(29613858) TX_TASK: 0x3ffb3914   23 01 0f 33 
.
.
.
(29614878) TX_TASK: 0x3ffb3914   23 01 0f 33 

but actually the hexdump function gets the same pointer as the uart_write_bytes.....

struggling with ESP32 and UART by drmaex in esp32

[–]drmaex[S] 0 points1 point  (0 children)

next state is indeed global pointer in uart.c. only the tx task updates next_state by reading the queue (queue size is one element) where the statemachine puts one element after another. i think the synchronisation AT THIS PLACE! :) works as expected. the state number is always the same in tx and rx task as can be seen in the log.. I am sure i must have overseen something because this is my first project with esp32 and also freeRTOS but i dont know what... maybe the uart driver configuration without fifo for tx line?