Блин ошибка смешная вышла и не могу понять в чём дело

Код СИ





counter.crc_row_total - щёлкает от 0 до 9

Мне надо в цикле сделать исключающее или для каждого из 10 битов. И результат этой операции присвоить этому же биту. А выдаётся ошибка
lvalue required as left operand of assignment

Это сообщение отредактировал(а) supercelt - 4.10.2015, 15:38

В том, что результат выполнения операцыи var & N -- это некоторое значение, т.е. число. И попытка присвоить этому числу что-нибудь столь жэ безсмысленна, как попытка присвоить что-нибудь какому-нибудь другому числу, например 4.

Т.е. компилятор офигевает примерно такжэ, как если бы Вы написали 4 = 2;

или

???

а почему не просто

?

Сделал как-то так. Появилась другая проблема.  Вот этот кусок

В дебаггере дохожу до того что бы buffer.CRC_column юыл равен 1. Он равен 1 в инспекторе переменных видно. Потом дебаггер попадает сюда
buffer.CRC_columns_check |= (1 << counter.crc); Проходит эту строчку и buffer.CRC_columns_check не меняется никак вообще. В этот момент counter.crc = 2.

UPD Причём я заметил если строчку

вынести перед первым циклом фор, ну так просто для проверки, то бит установится.

Это сообщение отредактировал(а) supercelt - 4.10.2015, 21:16

Наверное, просто захотелось повыпендриваться(((



Есть у меня сильное подозрение, что где-то в коде & заменилось на ^. Но все равно многое остается непонятным. Например, алгоритм совершаемых действий. Если здесь понятно, что требуется:

Как совершенно справедливо заметил volatile, это решается просто:без заморочек. И я приношу свои извинения за свой несовершенный код, отголоски которого видны в Вашем коде.


Что подразумевается вот здесь:


А что должно здесь проверяться:


Может, второй бит у buffer.CRC_columns_check уже выставлен? Не могли бы Вы описать словами, что Вы хотите сделать с buffer.CRC_columns_check.



Очень подозрительно выглядит и такой код:Если counter.crc не равен нулю, то значение CRC_columns_check никак не учитывается. А старое значение buffer.CRC_column пропадает.

Алгоритм такой. Нужно высчитать CRC по строкам и столбам. Строки работают. А вот со столбами загвоздка.


Это означает следующее. Есть буфер которй хранит вычисленый CRC по столбам. Солбов 4 значит 4 битная переменная. 0 бит - это срс 1 столба, 1-2, 2-3,3-4
По мере прохождения массива я постоянно высчитываю срс и меняю его в этой переменной. так вот пояснение означает что изначально срс = 0. Потом допустим поступила
1 и высчитывем срс, оно будет =1, так как пока мы встретили всего одну 1, значит срс - нечётно. Потом мы принимаем следующую единицу (в этом же столбе) и делаем ^ c предыдущим
высчитанным срс именно для этого столба разумеется.


Это для срс по стркам. В цикле перебираются все 8 бит байта и нужно после каждого полубайта (4 бит) сделать расчёт срс. По рисунку вначале понятно.
Эта строчка всё равно что 

Может, второй бит у buffer.CRC_columns_check уже выставлен? Не могли бы Вы описать словами, что Вы хотите сделать с buffer.CRC_columns_check.

Операции &, |, ^ работают сразу с несколькими битами - не нужно разделять на отдельные биты, а потом собирать.
Паковать в битовые структуры лучше только тогда, когда нужно экономить память. Они работают медленнее, чем обычные.

P0, P1, P2, ... P9 - считаются с помощью таблицы:

я бы вообще все это вычисление сделал так


Это сообщение отредактировал(а) volatile - 5.10.2015, 16:51

Сорри. не заметил. На рисунке биты перевернуты, там сначала идут младшие биты, потом старшие.


Если это действительно так, то надо будет еще перевернуть тетраду.



Это сообщение отредактировал(а) volatile - 5.10.2015, 17:39

Я вот и делаю битовые структуры потому что хочу сэкономить память. 
Не могли бы вы пояснить как работает 

Просто не в первый раз вижу подобное. Например видел что делают так:

Зачем делается сдвиг на 4 и тут же И с 0x0f?

UPD Не могу понять как применяются эти таблицы. Вы извините, если что, я ещё просто учусь и многого не знаю. Почему в таблице 16 элементов и именно такой порядок нулей и единиц? 

Это сообщение отредактировал(а) supercelt - 5.10.2015, 20:40

Упаковывать в битовые структуры целесообразно только большие массивы данных, если там есть смысл.
Упаковывать рабочие переменные не только бесполезно (все равно расчет идет в регистрах процессора, которые всегда кратны байту),
но и вредно, так как очень сильно замедляют все операции.

да и что вы там сэкономите? пару байтов?


старшая тетрада, сдвигается на младшую, и очищаются все остальные биты.
т.е. если в байте было например 0x8f, то после сдвига *in >> 4 там будет будет 0x08
(старшая тетрада (8), сдвинулась на место младшей тетрады)
& 0xf - очищает все остальные биты, кроме младших четырех битов. (конкретно, в данном случае это необязательно, так как они и так обнулены, но для успокоения совести, не помешает   )


это просто предвычесленные значения четности для тетрады
В тетраде может быть только 16 вариантов, вот для всех вариантов там и вычислено уже значение паритета.
(это сделано чисто для ускорения)
все эти значения, можно вывести с помощью например такой программки:

http://codepad.org/oRBlo3yM

Значит вы не советовали бы собирать 5 байт из полубайтов, а делать массив[10] в каждом элементе которого размещались бы полубайты?

supercelt, зависит от того сколько таких значений в вашей программе.
Если их мульон, то вероятно стоит упаковать.
Если 1, 2.., 10 - то смысла нет.

Нет, их всего и есть 5 байт. Ну изначально в программу передаётся 64 бита кода следуя из картинки и вот с ними и происходят все действия. Тогда понятно, что лучше не упаковывать, спасибо!