compile error

[wettermann32]

line 579 in ehal_hp.cpp portYIELD_FROM_ISR(higherPriorityTaskWoken); takes 0 arguments. can i just delete the argument?

Thanks for your help, Best

[rbroker]

Hi,

I'm not sure why your FreeRTOS version doesn't include the parameter, this pattern of code is implemented as advised in the FreeRTOS docs here: https://www.freertos.org/vTaskNotifyGiveFromISR.html

I don't know if things will work properly if the parameter is simply deleted, sorry!

[wettermann32]

I am using the board M5stamp-C3. wifi/mqtt/config seems to work, heatpump does not connect (FTC6). But my electrical connection was not perfect this time (no 10kOhms to 5V on serial pins). That is what the serial dump shows:

[13:19:39] CMD { .Hdr { fc, 5a, 2, 7a, 2 } .Payload { ca, 1, 5d, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } .Chk { 0 } } [13:19:49] CMD { .Hdr { fc, 5a, 2, 7a, 2 } .Payload { ca, 1, 5d, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } .Chk { 0 } } [13:19:59] CMD { .Hdr { fc, 5a, 2, 7a, 2 } .Payload { ca, 1, 5d, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } .Chk { 0 } } [13:20:09] CMD { .Hdr { fc, 5a, 2, 7a, 2 } .Payload { ca, 1, 5d, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } .Chk { 0 } }

I also did a fresh install of arduino, but the compile error ist still there. Can i choose any other libs for freetos or is this connected to the used board?

Best Michi

[wettermann32]

tried again with electric correct seetings (10k pull up). No change. So it seems it was not the best idea to delete the parameter...

[rbroker]

Hi,

I had a quick look at the headers for that board, and it does seem like it's using a very different implementation for that macro.

It's possible that the ISR for receiving serial data needs to be implemented differently for C3 boards, but I don't currently have one to test with. I'll look at getting hold of one, but it may take me some time.

Thanks, Richard

[wettermann32]

This is the full error message:

ehal_hp.cpp:531:51: error: macro "portYIELD_FROM_ISR" passed 1 arguments, but takes just 0 portYIELD_FROM_ISR(higherPriorityTaskWoken); ^ /home/haus/ecodan-ha-local/ecodan-ha-local/ehal_hp.cpp: In function 'void ehal::hp::serial_rx_isr()': ehal_hp.cpp:531:9: error: 'portYIELD_FROM_ISR' was not declared in this scope portYIELD_FROM_ISR(higherPriorityTaskWoken); ^~~~~~

[wettermann32]

This is what my header says: /home/haus/.arduino15/packages/m5stack/hardware/esp32/2.1.0/tools/sdk/esp32c3/include/freertos/port/riscv/include/freertos/portmacro.h

`#define portYIELD() vPortYield()

define portYIELD_FROM_ISR() vPortYieldFromISR()

define portEND_SWITCHING_ISR(xSwitchRequired) if(xSwitchRequired) vPortYield()

/ Yielding within an API call (when interrupts are off), means the yield should be delayed until interrupts are re-enabled. To do this, we use the "cross-core" interrupt as a trigger to yield on this core when interrupts are re-enabled.This is the same interrupt & code path which is used to trigger a yield between CPUs, although in this case the yield is happening on the same CPU. /`

[wettermann32]

broke my M5STamp hardware by disorder the pinning on cn105 :-).... So I am now ordered Wroom esp32. Everything is working now. Thanks! One more question: THW10 (mixing tank temperature seems not to be transmitted. Can you add this?

[rbroker]

THW10 (mixing tank temperature seems not to be transmitted. Can you add this?

I don't think my system configuration is using this thermistor, so I would need to check if someone else has managed to decode it and figure out the commands required to read it back from the FTC - it may be a bit difficult!

[wettermann32]

my hope was that on of the temperatures on 0xe-command would fit. Have you ever checked if these are valid? My gateway is offline in the moemnt, doing some hardware improvements. but next week i could try to read them. Have you any advice how to read them? Just go through the files and try to make verything similiar to the 0xd command? or can i see something in the debug log and issues a 0xe-command easily?

[rbroker]

Yes, based on what's listed on https://github.com/m000c400/Mitsubishi-CN105-Protocol-Decode there seem to be some temperature values stored in the 0xe command, you could try dispatching it to your device and see if any of the values reported match up with THW10 or not. I'm curious to hear the result!

[rbroker]

Hi,

I guess it's a bit late for your needs, but I made a change in c8490ae which should help ESP32C3 boards work as expected.

If you do find out how to retrieve the values for THR10 feel free to raise an issue or PR to discuss that (if you have any diagnostic logs with the 0xE message from your system, I'm happy to take a look and see if anything matches a THW10 temperature value your system is showing).

Thanks, Richard