Closed davesto closed 5 years ago
I partially agree to your observation. The first one, that you cannot init the pins with the uart construtor, is not right. In you example, you assign the pins twice. The fist time in the constructor call to P21, P22, the second time in the uart.init call to the default pins, which is P3 and P4. By the way, the init call is not required. The constructor calls init() itself. The second observation about crash/core dump is right. That should not happen, instead something less dramatic should happen, like an exception being raised.
Doh… Thanks for the clarification - of my incompetence - I shouldn't be 'trying' to code and watch rugby at the same time...
Don't worry. At least you pointed at a real bug. I just made a patch for that.
(sysname='FiPy', nodename='FiPy', release='1.18.1.r7', version='v1.8.6-849-d1c5ea9 on 2018-12-17', machine='FiPy with ESP32', lorawan='1.0.2', sigfox='1.0.1')
FiPy on Expansion3 P21 and P22 connected to provide UART loopback
[1] - uart 'constructor' doesn't accept pins as per online documentation, must use init [2] - use of object after uart.deinit causes divide by zero panic
[1]
[2] read or write after deinit causes catastrophic failure