Hardware different on non-BT model CC-RT-N-EQ3

[ceekay1]

Hi there. I've managed to get the build environment running. Then I flashed the firmware built from the unchanged code to the device. As you mentioned in a video, the display driver settings may vary between the BT and non-BT models. For me it looks like this is the case. I made a time lapse gif:

Every change takes about 15 seconds in real time. This tells me the firmware is somehow working right. Assuming an identic micro controller and display type, there may be just a shift in registers between the two models. What do you think?

As you went through this process already, what would be a good starting point to change things?

Regards Christian

[UltraFX]

Hey Christian,

a few other people already mailed me and confirmed that the pinout of the non-BT version and the display are different. I bought a non-BT one as well to check this issue.
We're working on this and will commit it here as soon as we got it working.

Regards
Nico

[ceekay1]

Nice to read that! While playing around with the STVD I made this pixel-to-address reference for the non-BT model.

[ceekay1]

I finished the address picking and got a nice clean display now. Problem with the bar graph was the PM2 (0x5406) which was set to 0x03 on the BT version and has to be set to 0x7f for this (main.c:99). I think this could be a base for some sort of update.

[UltraFX]

Hey that's awesome dude! Good work! If you can put this into a file like the one for the other display, we can merge that into here ^^

[ceekay1]

Sure, glad I can help. ^^ The segments for the pixels at 10:80, 10:10, 10:02 and 0f:40 are separate and had to be added to display numbers and letters with the "-" element right. At that point I also added the vertical center line and the "R" slash, so now I have segments A-J. One last open change is the "void Disp_Bargraph(uint32_t dwNumber)" block. When I have that finished, I'll upload it here.
Should I reverse any changes like the added segments or maybe merge the "-" segments?

[ceekay1]

ModelN_Display_Driver_noBT.zip

[ceekay1]

Is it possible that the other pins are different, too? My measures gave me for (resistors ignored):

Button1: PA3 (MP1)
Button2: PA2 (MP2)
Button3: PA0
Rot-Enc1: PC0 (MP4)
Rot-Enc2: PC1 (MP5)
TempSens1: PF0 (MP3)
TempSens2: PD4
Crystal_in: PC5
Crystal_out: PC6
Motor1: PE7
Motor2: PE6
Motor3: PC4
Motor4: PC7
Motor_ADC: PC3

Could you please check this with yours?

Best Regards
Christian

Edit: button3, rotary encoder and crystal are the same, as I can see from your cube file on youtube.

The buttons 1 and 2 are on the pins that you use for USART1_TX/RX ... is that a problem for serial communication?
The UART_INT is also used by the motor now ... how to handle that?

The ADC for the motor and temperature_in have switched positions.
The 4 motor control pins are different.
I'm going to adjust the values in "main.c" and "ModelN_Control.c" for the motor adc and control.

[UltraFX]

Hi,

yeah the layouts of the BT and non-BT version are completely different.

To use the UART, you'll need to reroute the buttons to other pins of the STM8L. For the interrupt as well, because the device supports pin-interrupts only on specific pins afaik.

Looks like the firmware needs to be completely redone for the non-BT version. Oh lord -.-

[ceekay1]

Here is mine:

There are no free pins left for serial :( with the original implementation:

I think about putting the 4 motor drivers togehter on 2 pins, as two of them are always switched sync. Does that make sense? Then I could use the free pins for the buttons 1 & 2.
All green pins including NRST/PA1 have ext.interrupt capability, so maybe the motor ADC could be used for this while not driving the motor.

Looks like the firmware needs to be completely redone for the non-BT version. Oh lord -.-

Yes, thats what I thought, too.

[ceekay1]

Hi there. For now I've managed to get the calibration routine working. The ADC treshold of 2025 was too low to be reached. At end position closed it is 2033 and opened it reads 2037. Running is between 2044 closing and 2046 opening. While stopped it reads 19. Values were taken without attaching the device to a heater. I don't know yet if this is another circuit difference, but anyway this issue is way more complicated than just the display.

My next steps are to figure out if the motor can be driven by two instead of four gpio pins. If this works, I'll put the two buttons on the free pins and re-enable the serial on the old button pins. Final problem then will then be the interrupt. Hopefully the motor ADC can somehow be pulled below the 19 to fire that. Any thoughts on this?

Considering the necessary adaptions this is really far from beeing compatible. For me this is now some "proof of concept" thing. I'll keep you updated here if you like. If not, feel free to close this issue as "wontfix", I won't mind.

Regards

[ceekay1]

The motor can be driven by two gpio pins, here is how I did it:

I cut the traces from PE6 (T2/R11), PE7 (T1/R7) and PC4 (T3/R6). Then I made a connection from the PC4 side to the T2 and T1 traces. Next the T3/R6 end was bridged to the T4/R12 trace.

The code was adapted to use only the PC4 and PC7 gpio pins. It works exactly like before the mod, the ADC values are the same, too.

I moved on to rewire the buttons 1/MP1 to PE6 and 2/MP2 to PE7, freeing the PA2 and PA3 gpio pins for serial. Then I re-enabled the serial interface, which I commented out before.

So far so good. Maybe the image helps to understand the mod.

[ceekay1]

The serial is connected to PA2 > TX and PA3 > RX (plus a gnd wire) and for now is confirmed working for TX. The RX is only triggered by an ext.int in the code and I still lack one gpio for this, so I can't test this right now. Considering the process made I expect this to work as well.

To get this working I think about changing the separate ext.int to something else. In one of my arduino ESP-01 projects I talk serial to an external module. The RX is pulled low while communicating, so maybe a function for recieving serial data could be triggered from this. I use such a function to recieve bytes until a number of bytes or e.g. a '\n' char is received as part of the protocol. Then a crc check is performed and if successful, the received data gets processed. If the crc check fails or a timeout occurs, the reception has failed and nothing happens. As long as nothing is received, no cycles are required.

Could this be a way to implentment it in your project?

[ceekay1]

One last problem from the beginning of this project also remained. The buttons 1 and 2 don't work. Even after changing the connection and code the problem persists. It looks like I miss some configuration spot for this, could you please help me out here?

I've changed:
in file user_interface.c
in fx UI_Buttons_Init(void)

	GPIO_Init(GPIOE, GPIO_Pin_6, GPIO_Mode_In_PU_IT);  //***2wire-hw-mod_buttons
	GPIO_Init(GPIOE, GPIO_Pin_7, GPIO_Mode_In_PU_IT);  //***2wire-hw-mod_buttons
	GPIO_Init(GPIOA, GPIO_Pin_0, GPIO_Mode_In_PU_IT);

	EXTI_SetPinSensitivity((EXTI_Pin_TypeDef)GPIO_Pin_6, EXTI_Trigger_Falling);  //***2wire-hw-mod_buttons
	EXTI_SetPinSensitivity((EXTI_Pin_TypeDef)GPIO_Pin_7, EXTI_Trigger_Falling);  //***2wire-hw-mod_buttons
	EXTI_SetPinSensitivity((EXTI_Pin_TypeDef)GPIO_Pin_0, EXTI_Trigger_Falling);

I've tried to switch the order of the second block to match the first, but nothing changed.

in fx UI_Buttons_Read(void)

	byVal = ((~GPIO_ReadInputDataBit(GPIOE, GPIO_Pin_6) & GPIO_Pin_6));  //***2wire-hw-mod_buttons
	byVal |= ((~GPIO_ReadInputDataBit(GPIOE, GPIO_Pin_7) & GPIO_Pin_7));  //***2wire-hw-mod_buttons
	byVal |= ((~GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) & GPIO_Pin_0));

in file user_interface.h I found this block, which I don't undesrstand yet:

#define BUTTON0	1
#define BUTTON1	4
#define BUTTON2	8

[UltraFX]

Hey man,

sorry for my late delay, I'm not really in the mood for my smart home stuff currently ^^"

I'm very impressed about your progress on the non-bt version! Looks like you figured a lot of stuff out already!

But lemme tell you about my honest thoughts about this:

The bt and non-bt version seem to have huge differences. There are a lot of hardware modifications necessary to make the non-bt one work with a co-processor. I think the modification in the bt-version (3 wires) is already challenging for a lot of people and the price difference of ~5$ isn't worth the effort to modify it as hard as you describe.
And the differences also mean a lot of modification in the code to make them both compatible.

So I think I wanna leave my code to work with the bt-version only. You can make your own repository and you can use and modify my code to match the non-bt one. I can link your repo into the README of my project and vice versa if you like.

The button-defines you mention are just bitcoded aliases I used as parameters for my UI_Buttons_Get() function. I could've also used an enum for that.
The pin-configuration looks right to me. Have you also put the UI_Int_Handler()-Function in the right interrupt handlers in the stm8l15x_it.c ?

[ceekay1]

Hi there,

first of all, you've made a real nice job with this device so far, and I'm confident it's gonna be way better than the factory version when you're done with it! I highly appreciate your work because based on it I was able to get things working for me. Big thanks!

Yes, it was a quite tough piece of work to sort the pieces for the no-BT version. o.o'
The hardware modification part is not too difficult. It just needs some soldering skills plus steady hand and a magnifier ^^. The real hard part is the software. There are many differences in ports, adresses, etc. and unfortunately there is nothing like a single HAL file where things could easily be adapted. If one specific device should work with the code there is no need for a 'single place of config', and that is totally the case here.

In the meantime you've taken a way (thread) that I can't follow atm, reason is just the lack of hardware ^^. At the current point of development the device stays on "Init" and doesn't move anywhere, waiting for some thread stuff to happen.

I've thougt about your idea to make a seperate repository for the no-BT version, but for now decided to go another way. I want the thermostat device to be less advanced and complex. Just some "actor" device with a direct human interface and an ESP-01 in the back, which handles the communication via wifi or esp-direct. A repository for a real sophisticated firmware has to be groomed and kept up-to-date to be useful, and I don't think I can handle that for now.

To get more into the mcu development I'm giving a try to a start from scratch, using the StdPeriph_Driver lib and the display driver you prepared. If this leads somewhere, I'm gonne make a repo for it.

Until then I'll keep an eye on your project and hope I can contribute some useful stuff one day :)

Regards
Christian

[dhuizinga]

@ceekay1 Seeing I have a bunch of these non-bt units lyin' around I am really curious about any progress you've made on your project. Cannot see any public gits from you, so I took the liberty of using this topic to inquire about it :)

[rossbeazley]

I am also interested in your code @ceekay1

I plan to abandon two of the buttons in favour of a serial port, the only controls I need are rotary for temp settings and push button for a boost.

I think my mods would simpler perhaps