Looks good. I don’t see too much impact on available RAM for my configurations. It will go to EDGE tonight, so we’ll get some more varied testing then. Regards, Mark.
On 23 Jul 2018, at 4:30 AM, Michael Balzer <dexter@expeedo.de> wrote:
I've pushed my latest changes to optimize CAN throughput & latency, which had problems before and have become worse with aggressive SPIRAM usage.
There especially were too many RX overflows and TX delays now. The Twizy module needs to respond to some frames as fast as possible, and the delays added up to over 120 ms in some circumstances.
I first moved the esp32can ISR and instance into internal RAM, then applied that change to all peripheral objects. To allocate objects of some class in internal RAM, simply add the super class InternalRamAllocated to it (counterpart to ExternalRamAllocated), i.e. class SevconClient : public InternalRamAllocated This eliminated RX overflows (except some on init when starting the module/bus with running transmissions on the bus -- don't know yet if we can avoid them), and helped a bit with TX delays. Moving the vehicle instance into internal RAM also helped a bit with TX latency, but together only reduced it by about 10%. So I also added a synchronous callback mechanism to the CAN system to be able to run a CAN responder directly within the CAN rxtask context.
See the Twizy CanResponder() in module rt_can for an example: void OvmsVehicleRenaultTwizy::CanResponder(const CAN_frame_t* p_frame); MyCan.RegisterCallback(TAG, std::bind(&OvmsVehicleRenaultTwizy::CanResponder, this, _1)); This reduced TX delays to zero most of the time. From time to time some delays still occurred, not continously but in chunks and only every few minutes. I think they were caused by the Wifi stack, because they seem to have disappeared after rearranging the CAN rxtask to be running at priority 23 and reducing the Wifi task priority to 22, but I need to collect some more data on this.
The new build is in my "edge" directory.
Placing the peripherals in internal RAM potentially solves other issues as well -- it's certainly not good if a peripheral component has to wait for an SPIRAM page-in operation. But I've had no reproducable issues before I could test now. We need to test this in the field.
Regarding the issues with can2 & can3: I don't think they are related to this, but it's worth a try. The mcp2515 instances are in internal RAM now as well.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev