Background
As you will have noticed, I have made a complete access control and alarm system based on a Raspberry Pi but working over RS485 bus connections to standard Honeywell Galaxy parts like RIO, Max Readers, and Keypads.
As you will have noticed, I have now started making WiFi connected parts for the alarm system based on ESP8266 parts (ESP-01, ESP-12F, ESP-12S). These include a small ESP-01 based board with RS485 driver that fits inside a Galaxy keypad talking RS485 to the keypad.
As you may have noticed, I have NFC readers sorted and working with secure NXP MIFARE DESFire EV1 cards. These are way more secure than poxy proxy cards used by Max Readers.
Challenge
The concern some people have raised is the reliance on WiFi. It will do the job, but it is not that hard to disrupt externally. Now, much like using a screwdriver on a Max Reader, it will set off the alarm to disrupt it, but it is perhaps a tad easier. One has to consider if it is easier than simply forcing the door or breaking a window, which is always the benchmark for any security :-) But it is a concern.
So can I make the door controller, which does the secure cards, look like a Max Reader and do RS485 to a conventional Galaxy system? I think I can...
Approach
Initially, for the keypad system, I used the built in serial drivers on the ESP8266. These are good, interrupt driven, well supported, except...
The code on the ESP8266 using Arduino is the NONOS SDK, and means one thread for all. It can be delayed a bit for all sorts of reasons, even many milliseconds. For serial that is all handled behind the scenes on interrupts this is no problem, until is it RS485!
The problem is that for RS485 you have to enable and disable the line driver around your transmission. Initially I simply set a time to disable after poking the message in the Tx queue. But that could be delayed and mean after transmitting we held the line driven for too long.
The solution was to wait in the main loop task until sent, and then disable the driver. This is not nice, as any other operations of the device are delayed, but for the keypad driver application there is nothing else. So it works well.
This will not work for the card reader as it has to, well, talk to the card reader, and inputs, and outputs for the door control, and so on. Also, if I am a slave device (unlike the keypad where I am master) I am expected to answer polls promptly and not hang around for 10ms randomly.
My plan - interrupts! Make a soft serial RS485 UART on an ESP8266 to do the grunt in the background.
UARTs
A UART (Universal Asynchronous Receive/Transmit) is a device to send and receive old fashioned serial byte / character data. The concept dates back to what? the 50s or 60s. It is simple...
Each byte, or character, to be sent is coded as a series of 1 or 0 on a bus. What 1 and 0 mean in terms of current or voltage depends on the flavour of system (RS232, RS485, RS422, etc). Each bit time (1/Baud rate) the line has a 0 or a 1. The line is idle (1) and then the byte/character starts with a start bit (0), bits in the byte (low bit first), then any parity bit, and then stop bit (or bits) which are 1.
Obviously both ends have to agree the rate (Baud rate) for bits, and byte size, and parity present and if even or odd, and even number of stop bits.
The Galaxy uses 9600 Baud (so a bit every 104⅙µs), 8 bit data, no parity and one stop bit. Simples!
Sending is easy, you need some sort of timer, and you set 1 or 0 on the output to do the start bit, data bits, and stop bit. The Arduino ESP8266 SoftwareSerial sends in real time from the command using careful timers, it seems. I plan to use interrupts.
Receiving is a tad harder. You have to find the start bit for each byte, and then sample each bit, ideally in the middle. But once you have the bits you shift in the data bits and check the stop bit is 1 (else an error). Not that hard?
Edge interrupt on rx?
Interestingly the SoftwareSerial code simply interrupts on each edge and looks at time from last edge to work out the received data (I think). That is one approach but I decided to clock in bits on interrupt - I just need to sample mid bit somehow.
My initial approach was to set an interrupt on the falling edge of the data line to set the recurring timer half a bit later. However, this has all sorts of challenges, no least of which is race conditions on a regular per-bit interrupt and the edge interrupt. I did work, but not 100%. I am sure I could have solved the race conditions, but actually there is a good reason to stick to simple regular interrupts.
So the approach I took was just a regular interrupt, and this was 3 times per bit. This means ⅔ of the interrupts just count a sub bit and return in most cases, so very light weight in terms of time. But what it does mean is that I could in fact have multiple instances of RS485 busses running on this one interrupt if all the same Baud rate. I have not yet coded that though. It is, however, nice and simple and working for one instance well.
Why 3?
The 3 times per bit is simple. For Tx it makes no odds, skip 2 out of 3 interrupts and set the line to 1 or 0 for the next bit to send. For Rx, it is the same for sampling, except when waiting for start bit. If waiting for the start bit you check for the line going 0 every interrupt, and if it does set the sub bit counter to sample one interrupt later and then every 3 interrupts.
This is not as clean as an edge interrupt adjusting the timing to the microsecond, but it does mean that we can have sampling of the centre of the bit, ±⅙ of a bit which is more than adequate. Doing 2 times bit rate is no good as you could be sampling in the middle or right at the end. Hardware UARTs usually do 16x bit rates, but 3x is fine in my opinion.
This is how I have coded soft UARTs for over 20 years dating back to PIC16C84s, realy!
Messages
The way the RS485 bus works on Galaxy systems is that messages are sent as a sequence of bytes with no gaps, and then a gap - no length indicator in the message (but there is a checksum). So I coded the system to handle this, and even, if we are a slave, auto respond with current status response.
This allows the application to work on a message level, and if it is slow, we answer polls promptly anyway with current status. The driver also does the checksum.
Interrupts on ESP8266
Now the challenge is making it work on an ESP8266. They are rather special. They are a weird mix of old and new. The ESP-12S has 4M of flash! As an embedded controller that is huge! But it has around 80k of RAM (yes, k) and I had a BBC micro with more in the 80s (32k main and 64k second processor). The fact it does TCP at all is mental, but it does, and it does WiFi too.
The usual pressures on coding are complex - embedded systems have pressures on code space, RAM, execution time, power, all sorts.
In this case interrupts are special. The processor has a cache for the code, but this cannot be used by an ISR (presumably some interrupt process handles cache fails). This means the ISR has to be in RAM.
The trick is marking the code you use for the ISR with ICACHE_RAM_ATTR attribute. The RAM used is small, so not only does the ISR have to be fast it has to be small in code space too.
Thankfully a UART is simple code in terms of space and time. Small TARDIS code, even?
This worked, well, sort of, it worked mostly if started after about a second after boot. It turns out that using digitalRead, digitalWrite and pinMode is bad as these Arduino functions are not marked ICACHE_RAM_ATTR. Instead you need to find the underlying GPIO_REG_WRITE and GPIO_REG_READ functions. That then works reliably. The GPIO access is also faster, which is good, but very processor specific.
The result is working RS485, on interrupt, on an ESP8266!
I even added a clock track (blue on that trace) for debug - toggling an output for tx and rx clocking per bit.
It works!
It is also quite important as I am using the hardware serial at 115200 Baud to talk to the PN532 NFC card reader!
P.S. I have tested now as both master talking to Keypad, and as slave, pretending to be a Max Reader.
Seems overkill if you have the source for the normal serial library. (I assume it's available as most Arduino stuff is open).
ReplyDeleteInterrupts for 8250 type UARTs tend to be on the transmit holding register being empty, not the transmit buffer being empty. Add an extra dummy byte to the end of the message to be sent. If the THRE ISR finds that there is nothing left to send then the dummy byte is about to be sent. Drop RTS or whatever line is controlling your RS485 transceiver at this point and the dummy byte then never makes it onto the line, but you get the timing you want.
To make it neater, add an RS485 mode to the library and move adding the extra byte, and asserting/clearing the direction line, down into the library.
Sadly not. For a start, we are using the serial for the PN532 NFC reader, so can't use for this as well. Also, even when using the serial, we don't get an "event" of any sort at end of sending, so cannot use that (even if doing with dummy byte, etc) to trigger disabling the driver. We either wait in main app (and the Serial.flush() does seem to wait until all sent), or we could be late disabling the driver.
DeleteReminds me of a 1980s era micro-computer called a Microbee from Australia. It was Z80 based, but to save money they didn't bother with a DART (Dual Asynchronous Receive Transmit) chip and instead drove the serial line directly with the Z80.
ReplyDeleteWhen it was receiving a Prestel page (1200 bps) it had to work so hard handling the serial data, the display flickered wildly, and it couldn't spare the time to put the newly received data into the screen RAM. Then once the serial data stopped, the display update got much faster, but only once all the display update was done did it stop flickering.
Those were the days!
Have you had a look at the ESP32? Three on-board UARTS and, I understand, hardware support for RS485. The two cores could come in handy too.
ReplyDeleteYou might like to take a look at micropython, if you haven't already. I come from an embedded C background -- and have been frustrated with ESP dev. from the point of view of the painful flash/test/rinse/repeat upload times & the lack of an emulator.
ReplyDeleteMicropython solves all of that and you can still mix in C (and arduino libs) as required.