Способ преобразовать поток байтов в поток пакетов в C89 на встроенном [закрытом] устройстве
Правила для того, что запросы данных видят в материализованном представлении, идентичны правилам, которые применяются к тому, что запросы данных видят в таблице, которая подвергается изменениям. Эти правила обобщены в документации под согласованность многоверсионного чтения .
Я предполагаю, что вы делаете атомное обновление материализованного представления. Вы могли бы сделать неатомарное обновление, которое бы урезало материализованное представление перед обновлением, но это почти наверняка не то, что вы хотели бы в этом случае.
- Запросы будут видеть данные в том виде, в каком они существовали, когда начался запрос (или когда транзакция началась, если сеанс находится на уровне изоляции сериализуемой транзакции). Таким образом, перед началом обновления будет отображаться согласованная картина данных.
- Считыватели не блокируют записи, так что это не повлияет на запись в базовую таблицу.
- Так же, как 1, запрос будет видеть непротиворечивую картину данных в том виде, в каком они существовали, когда запрос начал выполняться (или когда транзакция началась). Обновление будет выполняться одновременно только в отдельной области транзакции. Единственное влияние состоит в том, что запрос потенциально может быть немного медленнее, поскольку, вероятно, потребуется применить некоторое количество UNDO к текущим кэшированным блокам, чтобы вернуть данные в том виде, в каком они существовали на момент начала запроса.
3 ответа
See this answer I gave to a very similar question regarding details of a simple protocol.
To respond to your specific points:
- "Magic" bytes at the end of packets don't do any harm, but they're redundant if you already know how long the packet is supposed to be, and have a CRC.
- It can be sensible to specifiy timeout times, so if there's too big a gap between bytes within one packet, then an error is flagged. Having used Modbus, I'm not convinced of the value of using time-based delimiters elsewhere.
- Do you mean, "how do you find the beginning of packets in a stream of binary data"? If so, maybe specify a minimum gap between packets, and/or require the recipient to acknolwedge after every packet.
- Makes it easier for debugging, and doesn't require any special software on the PC, but not very efficient. Of course, if usability is more important than efficiency, than a text-based system is entirely appropriate.
Для чего-то подобного к тому времени, когда вы получите существующее решение для работы на вашем устройстве, было бы проще просто заново изобрести колесо.
void buffer_packet(unsigned char rx_byte)
{
static unsigned char byte_count = 0;
static unsigned char packet[8];
packet[byte_count++] = rx_byte;
if (byte_count == 8)
{
unsigned char crc = calculate_crc(packet, 8);
write_uart(0x55);
write_uart(8);
while (byte_count--)
{
write_uart(packet[7 - byte_count]);
}
write_uart(crc);
}
}
Или, возможно, я недооцениваю вашу проблему. Если вы ищете, как генерировать биты RS232, обратитесь к таблице данных вашего микроконтроллера.
Единственное, что там, кроме ваших примитивов ввода / вывода, это вычисление CRC. Здесь есть отличная статья с кодом .