hi
i use FreeRTOS in esp32 framework esp idf c language , i have 8 task to read 8 sensor i2c run at same time with in local value (task variable) so i want to collect those data variabe with one fonction in real time without block any task from them.
Collect sensor data from different task
Collect sensor data from different task
- Attachments
-
- socket.PNG (36.23 KiB) Viewed 6555 times
-
- Capture.PNG (365.38 KiB) Viewed 6569 times
Last edited by mohasrj on Mon Jul 20, 2020 7:19 am, edited 5 times in total.
Re: Collect sensor data from different task
It seems factually incorrect to say:
I would guess that you have one I2C bus and you want to talk to 8 devices. What then is wrong with one task (the sample runner) running a loop on the 8 devices?
Next (& even if you keep to a plush set of 8 tasks) then your requirement fits the producer/consumer pattern which is posh software terminology for; post you're readings to a queue.
Assuming that you're producer (writer) (1) only writes after it has finished sampling and so has stood down until next cycle and (2) reader/consumer simply collects then I think there are no latency issues as the following 7 I2C transactions will take >> longer than the queue read cycle.
EDIT: & even if you have 8 I2C channels then you only have 2 cores! So 6 channels cannot be processed in software at the same time! I am not nit picking, the point now is that you need to be clear about you're throughput & latency needs as you cannot achieve that which you state.
Howvever I do suspect that as I2C is not built for speed and that you will be fine & temperature, humidity etc typically have quite slow transfer functions so again, you should be fine.
You do not have 8 I2C channels & so you cannot receive 8 sensors at the same time!have 8 task to read 8 sensor i2c run at same time
I would guess that you have one I2C bus and you want to talk to 8 devices. What then is wrong with one task (the sample runner) running a loop on the 8 devices?
Next (& even if you keep to a plush set of 8 tasks) then your requirement fits the producer/consumer pattern which is posh software terminology for; post you're readings to a queue.
Assuming that you're producer (writer) (1) only writes after it has finished sampling and so has stood down until next cycle and (2) reader/consumer simply collects then I think there are no latency issues as the following 7 I2C transactions will take >> longer than the queue read cycle.
EDIT: & even if you have 8 I2C channels then you only have 2 cores! So 6 channels cannot be processed in software at the same time! I am not nit picking, the point now is that you need to be clear about you're throughput & latency needs as you cannot achieve that which you state.
Howvever I do suspect that as I2C is not built for speed and that you will be fine & temperature, humidity etc typically have quite slow transfer functions so again, you should be fine.
& I also believe that IDF CAN should be fixed.
-
- Posts: 9739
- Joined: Thu Nov 26, 2015 4:08 am
Re: Collect sensor data from different task
@PeterR: Nothing wrong with the general concept of starting multiple tasks for multiple sensors, even if they're on the same I2C bus, even with only two cores. While it probably does not make much sense from a performance PoV, if that's the way you like to write your code and it fits the performance and memory usage needs, it's a perfectly viable solution.
@morasrj: Simplest solution probably is to use FreeRTOS queues. Either create one for each sensor task, or create only one for all sensor tasks; both solutions work but have their advantages and disadvantages. Create a struct where you can put the variable data into, then on the sensor task side feed that into the queue, then on the side of the receiver get data from that queue, compile it and stash it into the JSON file.
@morasrj: Simplest solution probably is to use FreeRTOS queues. Either create one for each sensor task, or create only one for all sensor tasks; both solutions work but have their advantages and disadvantages. Create a struct where you can put the variable data into, then on the sensor task side feed that into the queue, then on the side of the receiver get data from that queue, compile it and stash it into the JSON file.
Re: Collect sensor data from different task
@peterR hi , thanks for ur replay , so i have really 8 i2c but software iknow with hard we have only 2 so iam using this library https://github.com/UncleRus/esp-idf-lib so no problem,
so i have 8 task with same priority 5 , in each task i have some variable i want collect them with another thask or static struct ...
@ESP_Sprite yes as i sad iam using soft i2c so that work with different bus , please do have exemple for that ? i dont know i think better but with one struct and one queue i dont know i can manag https://freertos.org/FreeRTOS_Support_F ... 74588.html
-how i can know queueSize bcs is depending of number of task run from 1-8 and variable on each task (depend too type of sensor )
-how i can manage type of variable if i have to send int and char and string float .... in the same queque ?
-how i can add a “type” field to the record posted so the receiving task knows what sort of message this is.
so i have 8 task with same priority 5 , in each task i have some variable i want collect them with another thask or static struct ...
@ESP_Sprite yes as i sad iam using soft i2c so that work with different bus , please do have exemple for that ? i dont know i think better but with one struct and one queue i dont know i can manag https://freertos.org/FreeRTOS_Support_F ... 74588.html
-how i can know queueSize bcs is depending of number of task run from 1-8 and variable on each task (depend too type of sensor )
-how i can manage type of variable if i have to send int and char and string float .... in the same queque ?
-how i can add a “type” field to the record posted so the receiving task knows what sort of message this is.
- Attachments
-
- queue.PNG (16.3 KiB) Viewed 6446 times
-
- main.PNG (25.08 KiB) Viewed 6461 times
-
- varsocket.PNG (27.04 KiB) Viewed 6461 times
Re: Collect sensor data from different task
You can use queue to pass struct(pseudocode):
Code: Select all
struct{
uint8_t type; // (enum 1-8 that gives a hint what sensor data it is)
union {
struct sensor1;
struct sensor2;
...
struct sensor8;
} sensor;
}sensors_data_t;
handle = xQueueCreate(n, sizeof(sensors_data_t));
Re: Collect sensor data from different task
Hopefully the producer/consumer (queue) comments are clear.
The OS will produce a tick signal at the tick interval, say 10 mS. If your tasks runs a simple loop, sample and delay then it is quite possible that two or more of your sampling tasks will be ready to run at the same time, certainly unless each sample takes longer than tick interval as each delay is quantised in terms of tick i.e. 10mS.
@ESP_Sprite Will the task run order then depend on creation order or might run order (with two or more equal priority tasks) change? At tick does the scheduler choice the first highest priority ready task & is task order fixed? I do not know the answer to that question & potentially tasks might run out of 'order' depending on scheduler detail.
I think that the original posts shows out of order sampling.
It would also be interesting if the queue reading collection task held a counter for each source and incremented that counter for each sample received. After many hours do all the counters equal +/- 1? In other words could multiple tasks lead to a material difference in sample counts?
I don't suppose the above matters much to most but it is interesting/possible useful to know how the scheduler would handle.
The OS will produce a tick signal at the tick interval, say 10 mS. If your tasks runs a simple loop, sample and delay then it is quite possible that two or more of your sampling tasks will be ready to run at the same time, certainly unless each sample takes longer than tick interval as each delay is quantised in terms of tick i.e. 10mS.
@ESP_Sprite Will the task run order then depend on creation order or might run order (with two or more equal priority tasks) change? At tick does the scheduler choice the first highest priority ready task & is task order fixed? I do not know the answer to that question & potentially tasks might run out of 'order' depending on scheduler detail.
I think that the original posts shows out of order sampling.
It would also be interesting if the queue reading collection task held a counter for each source and incremented that counter for each sample received. After many hours do all the counters equal +/- 1? In other words could multiple tasks lead to a material difference in sample counts?
I don't suppose the above matters much to most but it is interesting/possible useful to know how the scheduler would handle.
& I also believe that IDF CAN should be fixed.
Who is online
Users browsing this forum: No registered users and 107 guests