7i76E hm2 driver
27 Apr 2023 09:27 #270048
by 5G-antry
Replied by 5G-antry on topic 7i76E hm2 driver
I thought I did it, but it seems I had not.
I Changed this number and it works now. Thank you!!
However, I changed different other things.
I will give an update if it also works when just this line is adapted.
I Changed this number and it works now. Thank you!!
However, I changed different other things.
I will give an update if it also works when just this line is adapted.
Please Log in or Create an account to join the conversation.
07 Jun 2023 17:57 - 12 Jun 2023 21:38 #273099
by 5G-antry
Replied by 5G-antry on topic 7i76E hm2 driver
Sorry for the late reply, but better late than never.
Everything works as expected
Everything works as expected
Last edit: 12 Jun 2023 21:38 by 5G-antry.
Please Log in or Create an account to join the conversation.
12 Jun 2023 08:42 #273376
by ChrisD
Replied by ChrisD on topic 7i76E hm2 driver
I am a colleague of 5G-antry, and would like to follow up on this matter.
We have now, as indicated above, everything running with a network emulator, which also emulates a 1Gbit/s PHY.
We transitioned from this network emulator to a special wireless connection that has similar characteristics over-the-air as the network emulator. Yet, there is one noticeable difference: there is an additional microcontroller involved that transfers data from ETH to the wireless device. Unfortunately, this device only has a very limited number of ETH buffers - fewer than a 100MBit/s ETH would normally require.
When we boot the system, it starts to initialize itself and everything runs (almost) as expected up to a certain point (in the GUI it is indicated as the third boot phase with something like "fvs_spin"), where >20 packets are generated within a couple of microseconds. This unfortunately overwhelms the microcontroller, leading to packet loss, leading to an abort.
Is there a way to slow down this packet generation a bit to not cause a buffer depletion at this microcontroller?
We traced both scenarios. Find attached two wireshark packet dump screenshots one of the critical section: one for the smooth bootup when using only ETH, and one with the hickup when inserting the device with the slightly limited mikrocontroller.
We have now, as indicated above, everything running with a network emulator, which also emulates a 1Gbit/s PHY.
We transitioned from this network emulator to a special wireless connection that has similar characteristics over-the-air as the network emulator. Yet, there is one noticeable difference: there is an additional microcontroller involved that transfers data from ETH to the wireless device. Unfortunately, this device only has a very limited number of ETH buffers - fewer than a 100MBit/s ETH would normally require.
When we boot the system, it starts to initialize itself and everything runs (almost) as expected up to a certain point (in the GUI it is indicated as the third boot phase with something like "fvs_spin"), where >20 packets are generated within a couple of microseconds. This unfortunately overwhelms the microcontroller, leading to packet loss, leading to an abort.
Is there a way to slow down this packet generation a bit to not cause a buffer depletion at this microcontroller?
We traced both scenarios. Find attached two wireshark packet dump screenshots one of the critical section: one for the smooth bootup when using only ETH, and one with the hickup when inserting the device with the slightly limited mikrocontroller.
Please Log in or Create an account to join the conversation.
Time to create page: 0.132 seconds