The has successfully run my loopback self-test program for CAN,
which tests transmission, reception, and filtering. The 1M baud rate setting
was also verified on saleae to be accurate.
This brings in the following, and updates us to the 1.0.4 release tag:
Submodule lib/protomatter 2a1ba8fa4..5f07ec618:
> Bumping version for release
> Merge pull request #21 from makermelissa/master
> Merge pull request #20 from makermelissa/master
> Merge pull request #18 from jepler/fix-cpy-3184
> Merge pull request #14 from hierophect/cpy-timer-allocator
We previously had the _changes_ of jepler/fix-cpy-3184 and
hierophect/cpy-timer-allocator but not their merge commits.
The only other changes in protomatter were one formatting change in the
core, plus several Arduino sketches. So this should make no practical
difference for CPy.
This requires recovering the pointer of the allocation, which could be done by adding up neighbor lengths, but the simpler way is to stop NULLing it out in the first place and instead mark an allocation as freed by the client by setting the lowest bit of the length (which is always zero in a valid length).
When allocations were freed in a different order from the reverse of how they were allocated (leaving holes), the heap would get into an inconsistent state, eventually resulting in crashes.
free_memory() relies on having allocations in order, but allocate_memory() did not guarantee that: It reused the first allocation with a NULL ptr without ensuring that it was between low_address and high_address. When it belongs to a hole in the allocated memory, such an allocation is not really free for reuse, because free_memory() still needs its length.
Instead, explicitly mark allocations available for reuse with a special (invalid) value in the length field. Only allocations that lie between low_address and high_address are marked that way.
An RGBMatrix has no bus and no bus_free method. It is always possible
to refresh the display.
This was not a problem before, but the fix I suggested (#3449) added
a call to core_bus_free when a FramebufferDisplay was being refreshed.
This was not caught during testing.
This is a band-aid fix and it brings to light a second problem in which
a SharpDisplay + FrameBuffer will not have a 'bus' object, and yet does
operate using a shared SPI bus. This kind of display will need a
"bus-free" like function to be added, or it can have problems like
#3309.
