Fire Safety Curtains.
We were referred to a new client by a PCB designer. The client makes large roller shutter equipment.
These are installed on site at great cost, and deploy and retract either automatically or at user request.
The issue was the curtain would sometimes deploy, but fail to retract.
In the case of the most problematic customer, this meant the customer would be stuck behind the curtain and unable to reach the release button.
Our contact described this problem as “intractable”.
The challenges Bermondsey Electronics solved.
On investigation, we found the application divided into two halves, each running in an 8b CPU. Each runs a timer. Communication is a combination of GPIO pins and CANBus.
Settings are stored in on-chip EEPROM. So far, so straightforward. We considered installing the equipment on site.
This would require a site visit by a specialist engineer. The equipment would need to be transported and installed; typically a 1-day operation.
Alternatively, we could run the motors on weights; sandbags could be used to simulate the weight of the shutter.
Either option would involve some amount of expense and risk. What if there’s a better way?
The code had been supplied as two files, one for each target.While clearly thought and design had gone into the application, at some point either these requirements no longer applied, or another developer had become involved.
Perhaps not coincidentally, this was also identified by the customer as the problematic feature.
Key Steps:
- Considering the two files, the I/O portion of the files is brief. We read and write the GPIO. There is a timer. There are CANBus messages. These can all be mocked out to other files, which we immediately did.
- Now we wrote implementations suitable to be run on the desktop. EEPROM reads and writes we converted into file accesses on disk, so we could write arbitrary configurations and swap them in and out as needed.
- Timers became desktop OS timers. GPIOs we decided to script against the timer, so the test functions would act as test scripts. CANBus messages we replaced with OS message queues.
- Tying it all together, we have both MCU applications now running on the desktop. We can interfere with it however we like, inject any errors we like, and do it all with arbitrary timing. No messing around with physical product needed.
The Solution
Quickly, under this setup, we realised the problem. The original code did not block; the most recent changes introduced a lengthy blocking section.
We realised that instead of polling the signals under an interrupt, the lengthy blocking section prevented updates of a critical release signal. Introducing this lengthy blocking section broke the application’s ability to recover from a brief activation.
Armed with this knowledge, we returned to the original code. We moved the test from the application main loop into an interrupt service routine. Now the signal can be polled on a timed basis, and hey presto, we can recover from a brief activation.
By using our experience and leveraging innovative coding techniques, we were able to drop a requirement for an expensive installation. We were able to diagnose and fix a serious issue with the product in a short time frame.
We were able to do all this without hardware in hand. All it took was the application of modern programming techniques, and keeping within the spirit of the original design guidelines.
Don’t just take our word for it.
Hear from our customers.
Contact Us
If you have questions about how we can help your business please complete the form below and we will be in touch shortly.
Alternatively, please call us on +44 (0)208 0650 162
Email : [email protected]