ejhones
September 20, 2024, 10:41am
1
Catalystv2_klipper.log (66.9 KB)
Hello, thank you… S2
After turning off the display section of lcd_type: sh1106 in i2c_bus: i2c1a the consumption is low.
PB9 / SPI2_NSS/I2S2_WS / I2C1_SDA / TIM4_CH4 / TIM11_CH1 / SDIO_D5
#i2c_bus: i2c1a
#i2c_mcu: mcu
#i2c_speed: 400000
i2c_software_scl_pin: PB8
i2c_software_sda_pin: PB9
When configuring in i2c_software, consumption is higher
What’s strange to me is that the consumption in KP3sProv2, spi_software_lcd_type:uc1701 is low
The big question is, is this right?
# the SH1106 is SSD1306 compatible with up to 132 columns class SH1106(SSD1306):
opened 03:32PM - 05 Jun 19 UTC
closed 03:03PM - 10 Jul 19 UTC
Hello all,
on my 3D DIY printer I installed an SSD1306 OLED display.
It's wo… rking fine, but I got lot of load (nearly 200% on Raspi 3B) on MCU compared to my solution before without any display (load max. 35%).
Also when I use another display (RepRapDiscount 128x64 Full Graphic Smart Controller) i got only max. 40% load. Unfortunatelly the RepRap 128x64 display is to big and will not fit in my design of my (small) printer, so the SSD1306 display is perfect in this case.
Is this a know issue and could this be optimized to reduce the load?
in the performance graph you can see it. Until 1:05 it's with the SSD1306, after that with RepRap display.
Thank you for your help.
Thank you very much, take care of the planet, and live long and prosper.
Sineos
September 20, 2024, 3:12pm
2
Seems strange. Probably can be ignored as long as no negative effects pop up. LCD updates have a low priority in the Klipper code and should not cause an issue.
ejhones
September 20, 2024, 3:26pm
3
I think it’s not a good idea to see mcu at 51%.
As said before, this is not an issue by itself.
I even did something like this:
Klipper3d:master ← nefelim4ag:i2c-async
opened 07:32PM - 30 Aug 24 UTC
I'm not a hardcore embedded guy - I can have wrong assumptions or understanding … here.
If I understood correctly.
For now, SPI/I2C is working in synchronous mode, which may shift other events in the scheduler queue.
I2C is slower in general because it is used with speeds: of 100kHz and 400kHz.
According to #6141, we can easily calculate timings, 5us per pulse, 18 pulses per byte + ack.
The average read request looks like 2 bytes write 6 byte read.
1 byte ~ 18 * 5 = 90 us
8 byte ~ 90 * 8 = 720 us
400kHz is 4x faster, so 22.5us and 180us with same load.
SPI is freaking fast, SW works as fast as pins go, HW looks like expected to run at 4Mhz.
So, 10 times faster, 1 pulse per bit ~ 0.25us.
0.25 * 8 = 2 us, scheduling per byte looks not so good here.
The toolhead moved at a speed of 200 mm/s, 40mm rotational distance and 32 micro steps should have 32us between steps: `1 / ((200 / 40) * 200 * 32)) ~ 31.25 us`
Because i2c is blocking it will affect other timings occasionally.
It feels important to me to honor TSTEP timing for TMC because they are used for interpolation/thresholds (stealth/coolstep).
I cannot argue that those timings create interpolation position lag or that is a reason why switching stealth/spread modes is unstable.
Current implementation often blocks and waits for each byte (HW)/bit(SW) just wasting CPU time.
Those graphs when my machine is at a standstill:
Current implementation BME680 on host, SHT3x on mcu. *HW i2c decreased mcu load to ~5.6%
Current implementation with disabled i2c sensors.
Such a difference in load is unexpected for me. I can guess it is calculated from time drift.
Because the actual Awake time difference is in the expected range (less than 1%).
Patched async I2C (MCU software):
mcu hw i2c bus:
Host MCU pthread:
---
Current master SW: `mcu_awake=0.006 mcu_task_avg=0.000013 mcu_task_stddev=0.000114`
Async I2C SW: `mcu: mcu_awake=0.001 mcu_task_avg=0.000001 mcu_task_stddev=0.000001`
---
New I2C SW timings with default 100k.
It looks like 6-7 us per pulse originated to a safe way of switching.
https://github.com/Klipper3d/klipper/pull/6141#discussion_r1201492770
The transition between bytes is a little suboptimal.
---
With bit time correction at 100kHz.
I was able to drive the bus around 500kHz, it looks like there is a limit on the GPIO toggle speed.
---
The main question is it worth it?
I tried different approaches, but for now, this is something more or less simple.
*Current i2c_read/write works as before.
The high-level Idea is to buffer klippy i2c requests and execute them in the background.
There is a new infrastructure defined around it.
Because i2c_read is currently used in different places, there is the possibility of defining a callback for i2c_async.
There is the ability to change ldc1612 and mpu9250, to use it with the nonblocking API.
Correct nonblocking HW i2c is written for stm32f0_i2c.c
Others I didn't touch for now, but I can also rewrite them - the event loop is the same.
Software i2c is tricky, I tried to not overcomplicate things and still emulate the bit-banging approach in tmcuart.c
(I unintentionally reinvented it somehow, with function overrides :D)
For now, the event loop is stored in each HW i2p implementation because it is easier to overcome specific restrictions, like:
- Linux HW i2s can only be made in one ioctl.
- AVR can be slow and such a thing will not work, so there count of jumps can be reduced.
This is not ready for merge.
TODO:
- ~~Make i2c_modify_bits async. There is Write-Read-Modify-Write cycle here.~~ - Done
- Write HW for other MCUs.
- i2c bus is shared, there is the possibility to send 2 async requests to the same bus - it will not work
- If there are decisions to get rid of old synchronous code here. I have a bad understanding of time measurements for i2c bulk data and how it will cooperate with async approach.
- ~~Does it make sense to have io pthread on Host MCU?~~ - that one reduce jitter
- ~~Commit mess should be fixed (I leave it for now as a history of thoughts).~~
---
MCU: Octopus Pro - stm32h723
Host: RPI 5
To fix “graphs”There is no code which does same for stm32f4, because I do not have one to test
But main point here, to be honest, there is nothing to fix.
1 Like
system
November 19, 2024, 5:24pm
5
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
and …