Pin.value change is slow

[tadam]

Hello there,
I am currently tring to mimic Dali commands. My poc looks like that.
I loop throw on an array and set a the dout accordingly. My issue is that the code is really slow.
Attached a picture of the output. Is there a way to make it run faster?

command2 = [1, 0, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 1, 0, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1]

led_pin.value(1)
time.sleep_us(3000)
for a in command2:
    led_pin.value(a)
    time.sleep_us(420)

also I did tried basic dout changes without anything. that wasn’t fast either.

led_pin.value(1)
led_pin.value(0)
led_pin.value(1)

Also tried sdout based on this github issue but I found a lot of unwanted traffic, I can’t adjust a the speed using that protocol, and the output didn’t really made much sense to me.
This was my code:

write_data(b"1001010101010101100101010101010101")
time.sleep_us(3000)
write_data(b"1001010101010101101001100101010101")
time.sleep(2)

and this was my output in a broader view first and last spike is unwanted traffic:

and a closer view of the first message:

Thanks in advance,

[mvut]

What baud rate do you have the module set to? I am referring to the BD command?

[tadam]

it is set to 115200 [7]

[mvut]

I would recommend looking at your time.sleep functions.

[tadam]

When I did the simple pin low-high-low test without sleep, it also took 1.6 ms. (second pic)

[mvut]

So if I understand, what you are trying to do is what would be bit banging. Is that correct?

[tadam]

Yes, exatly. My goal is to mimic dali commands. which has a baudrate of 2400.

[mvut]

As far as I am aware, the modules are not able to perform that kind of function. At least not as of right now. Instead you would want to use the secondary COM port on the modules that support it.

[tadam]

Can you elaborate a little bit? What is the secondary COM port? Is there a sample code for it? Thank you!
Keep in mind I am using an Xbee3

[mvut]

The XBee 3 Cellular modules offer two com ports. The Primary and a secondary COM port. The Primary is for the Python interface and the direct access COM port. The secondary COM port is for interfacing with the Python interface from or for an external device.

[tadam]

Well we use XB3-24Z8RM-J non cellular, because it will be a node in a mesh network. Puting cellular in every node will increase a the maintanence cost drasticly.
Are you sure that is no way to send out dali command from our board?
Thank you,

[mvut]

You would need to use the Primary UART and a Print function.

[tadam]

Okay, but as I wrote above the primary uart has a lot of unvanted traffic, and also I am not sure how can I send bit array-s on to the primary uart. Maybe my syntax is wrong?

print(0b1001010101010101101001100101010101)

If I do this, beside the unwanted traffic, the output doesn’t have the desired outcome.

[mvut]

I would suggest looking at the Examples.

[tadam]

Sorry for the late reply, eventually we decided to add an additional mcu to handle dali communication.
xbee and this mcu is connected via uart.

[timjohnson2584]

Blockquote
If you are experiencing slow response or delays when changing the value of a Pin object, there are a few potential causes and solutions you can consider:

1. Code Optimization: Review your code to ensure that there are no unnecessary operations or inefficient algorithms causing delays. Optimize your code logic and remove any unnecessary computations or loops that may be slowing down the execution.
2. Hardware Limitations: If you are working with physical hardware that interfaces with the Pin object, the delay might be due to hardware limitations or communication protocols. Ensure that the hardware is properly connected, and consider checking the hardware documentation or consulting with the hardware manufacturer for any specific considerations.
3. Performance of the Microcontroller: If you are working with a microcontroller-based system, the delay could be caused by the processing power or speed of the microcontroller itself. In such cases, consider using a microcontroller with a higher clock speed or more powerful capabilities to improve the response time.
4. Other Concurrent Operations: Check if there are other operations or tasks running simultaneously that might be consuming system resources and affecting the speed of the Pin.value change. Consider optimizing or prioritizing tasks to allocate resources appropriately.
5. Interrupts or Event-Based Handling: Depending on the platform or framework you are using, consider utilizing interrupt-based or event-driven mechanisms to handle the Pin.value change. This can help improve responsiveness by triggering the necessary actions immediately when the value changes, instead of relying on continuous polling or updates.
6. External Libraries or Dependencies: If you are using external libraries or dependencies, ensure that they are up to date and optimized for performance. Outdated or poorly optimized libraries can introduce delays in the execution of Pin.value changes.
7. Hardware Connections: Double-check the physical connections between the pin and any external components or circuits. Loose or faulty connections can cause delays or inconsistent behavior when changing the pin value.

By reviewing these potential causes and applying the corresponding solutions, you can help identify and resolve the slow response or delays when changing the value of a Pin object.

[tadam]

Hello there,

The limitation was in the xbee3 for sure. I used a same POC code, in an esp32 and xbee3. The code did nothing just one dali command, implemented with bit banging.
That code working fine on an esp32 but it was slow on xbee3.
Eventually we added a coprocessor,which handles the dali commincation, and receive commands in uart from xbee3.