ViKo

Полностью согласен. Правая часть выражения должна быть приведена к размерности переменной в левой части. Остался маленький вопросик - преобразование беззнакового байта в знаковый - это просто "подмена представления", не вызывающая у компилятора даже варнинга? Все-таки, например, 255 превращается в -1, и ничего страшного?

Да, проходит и такое. А я уж было "изобрел" конструкцию "с двойным преобразованием" :) int32_t KeyCnt = (int32_t)(int8_t)FPI.FP_RBf[1]; А, может, так, как я написал, надежнее, правильнее? Все-таки, конкретное указание...

Ну, эта строка написана "по инерции" за компанию, чтобы не отличалась от следующей. Вот какое решение нашлось, для буфера из uint8_t ;;;305 int8_t temp = FPI.FP_RBf[1]; 0001a4 f9900003 LDRSB r0,[r0,#3]; FPI ;;;306 int32_t KeyCnt = (int32_t)temp; Как видите, нашлось что расширять :)

Имею буфер приема от панели управления (в составе структуры FPI) uint8_t FP_RBf[2]; Хочу прочитать этот буфер и вызвать функцию по значению первого байта, и значение второго байта передать в функцию, как int32_t. uint32_t KeyNum = (uint32_t)FPI.FP_RBf[0]; int32_t KeyCnt = (int32_t) FPI.FP_RBf[1]; FpKey_hand[KeyNum](KeyCnt); Однако заметил, что при считывании RBf[1] компилятор использует команду LDRB, а не LDRSB ;;;295 int32_t KeyCnt = (int32_t) FPI.FP_RBf[1]; 0001a4 78c0 LDRB r0,[r0,#3] ; FPI Т.е. не происходит знакового расширения байта. Как сделать правильно? Заменил тип в буфере на int8_t. Получилось следующее: ;;;294 uint32_t KeyNum = (uint32_t)FPI.FP_RBf[0]; 0001a4 f9901002 LDRSB r1,[r0,#2] ; FPI ;;;295 int32_t KeyCnt = (int32_t)FPI.FP_RBf[1]; 0001a8 f9900003 LDRSB r0,[r0,#3] ; FPI Так оно работает, но непонятки остались... Теперь обе переменные размножили знак.

Из первого сообщения ТС следует, что "пила" наблюдалась, начиная с частоты 20 kHz. Которую должен был бы показать любой осциллограф, а уж С1-65 непременно. Что-то было подцеплено на злополучную ножку. Вопрос в малом - что?

Вот так и оставите загадку неразгаданной? К чему была ножка подключена? Схема-то есть? Или по плате пройдитесь с прозвонкой...

Открываете все темы в данном разделе, и выбираете то, что более привлекает. Мне кажется, здесь в каждой теме еще есть над чем поработать. P.S. В жизни всегда есть место подвигу.

Assigments->Settings->Device->Device and Pin Options->Dual-Purpose Pins->nCEO->(в Value нажать) Use as regular I/O

У меня сложилось мнение, что в самосинхронизирующихся (или как-то еще иначе называющихся) схемах каждому действию нужно подтверждение - "выполнено". После которого можно выполнять следующее действие. Так как это подтверждение само отбирает время от полезной работы, поэтому мне не очень нравится этот принцип. Логичнее было разбить сложные действия на более мелкие и выполнять их в конвейере. Что, собственно и сделано во всех процессорах.

Аналоговый фильтр тоже не обязан "звенеть". Сделайте тот же фильтр Бесселя, или Баттерворта. Скорее всего, дело вообще не в фильтрах - в разводке, в пробниках осциллографов, плохо подключенных, и т.п.

То я делал в MAXPlus+II, там и понятия констрейнов не было, наверное. И сейчас пока "не осилил". Вот-вот приступаю к реальному проекту, тогда и изучу, как следует. :bb-offtopic: Вообще, чем глубже проникаешь в какой-нибудь САПР, тем лучше будет выдаваемый продукт.

Маху дал - надо было в Waveform окне Quartus для отображения переменных задать MSB on Top, LSB on Bottom. А было наоборот (по-умолчанию, похоже). Оттого и рисовалось что-то ужасное. Вот - работающий код. 36 LE для Cyclone III. Может, и не оптимальный, зато простой. module exsZeros ( input wire [7:0] data, output bit [2:0] pos, output bit [3:0] size ); always_comb begin priority casex (data) 8'b00000000: begin pos = 0; size = 8; end 8'b10000000: begin pos = 0; size = 7; end 8'b00000001: begin pos = 1; size = 7; end 8'bx1000000: begin pos = 0; size = 6; end 8'b10000001: begin pos = 1; size = 6; end 8'b0000001x: begin pos = 2; size = 6; end 8'bxx100000: begin pos = 0; size = 5; end 8'bx1000001: begin pos = 1; size = 5; end 8'b1000001x: begin pos = 2; size = 5; end 8'b000001xx: begin pos = 3; size = 5; end 8'bxxx10000: begin pos = 0; size = 4; end 8'bxx100001: begin pos = 1; size = 4; end 8'bx100001x: begin pos = 2; size = 4; end 8'b100001xx: begin pos = 3; size = 4; end 8'b00001xxx: begin pos = 4; size = 4; end 8'bxxxx1000: begin pos = 0; size = 3; end 8'bxxx10001: begin pos = 1; size = 3; end 8'bxx10001x: begin pos = 2; size = 3; end 8'bx10001xx: begin pos = 3; size = 3; end 8'b10001xxx: begin pos = 4; size = 3; end 8'b0001xxxx: begin pos = 5; size = 3; end default: begin pos = 0; size = 0; end endcase end endmodule

мое скромное мнение - Пока мне хватало времени, определяемого тактовой частотой, я делал синхронные схемы в ПЛИС. Проверял в симуляторе и знал, что там все будет работать. Как только в каком-то узле требовалось время более быстрое, чем период тактовой частоты, я делал асинхронную схему. Скажем, работала внешняя память на частоте 100 MHz от ПЛИС, у которой и была частота 100 MHz, вот и приходилось сигналы адреса, данных, управления делать на логических элементах в ПЛИС. Смотреть в симуляторе, корректировать, пытаться добиться удовлетворения временнЫм требованиям для памяти. И надеяться, что все это будет соответствовать реальному железу. А куда деваться...? Кстати, работает, но, настраивая каждую новую партию изделий, я всегда вспоминаю об этих "тонких моментах".

Это называется netlist, и он однозначно описывает схему. Был, как вы понимаете, всегда. При желании, на нем можно описать любую схему. Еще в старом ДОСовском pcad, вместо того чтобы рисовать схему, транслировать и т.п, чтобы получить плату с элементами, можно было создать .alt файл, где все связи были описаны. для purplerain0724 Spice не язык описания схемы, а средство моделирования. Например, он ничего не говорит о корпусах элементов, рассеиваемой мощности и т.д.

EditPlus http://www.editplus.com/

добавил и т.д. и т.п., и все равно абы что :(

Хотел было я "сбацать" код попроще, с помощью case. И получил для Cyclone III те же 29 ЛЭ. Но при симуляции в Quartus получаю бред. Где-то я "накосячил". А где, не пойму. Я уже и порядок строк поменял, и размерности с форматом добавил к выходным данным. Что-то в case не так... module exsZeros ( input wire [7:0] data, output logic [2:0] pos, output logic [3:0] size ); always_comb begin casex (data) 8'b00011111: begin pos = 3'd5; size = 4'd3; end 8'b00001111: begin pos = 3'd4; size = 4'd4; end 8'b10001111: begin pos = 3'd4; size = 4'd3; end 8'b00000111: begin pos = 3'd3; size = 4'd5; end 8'b10000111: begin pos = 3'd3; size = 4'd4; end 8'bx1000111: begin pos = 3'd3; size = 4'd3; end 8'b00000011: begin pos = 3'd2; size = 4'd6; end 8'b10000011: begin pos = 3'd2; size = 4'd5; end 8'bx1000011: begin pos = 3'd2; size = 4'd4; end 8'bxx100011: begin pos = 3'd2; size = 4'd3; end 8'b00000001: begin pos = 3'd1; size = 4'd7; end 8'b10000001: begin pos = 3'd1; size = 4'd6; end 8'bx1000001: begin pos = 3'd1; size = 4'd5; end 8'bxx100001: begin pos = 3'd1; size = 4'd4; end 8'bxxx10001: begin pos = 3'd1; size = 4'd3; end 8'b00000000: begin pos = 3'd0; size = 4'd8; end 8'b10000000: begin pos = 3'd0; size = 4'd7; end 8'bx1000000: begin pos = 3'd0; size = 4'd6; end 8'bxx100000: begin pos = 3'd0; size = 4'd5; end 8'bxxx10000: begin pos = 3'd0; size = 4'd4; end 8'bxxxx1000: begin pos = 3'd0; size = 4'd3; end default: begin pos = 3'd0; size = 4'd0; end endcase end endmodule

Да, вы правы. В вашем методе есть смысл (именно так я писал на ассемблере, но без параметра - приоритета). Только все равно перед вызовом такой функции нужно готовить параметр. И внутри его проверять. Я лучше буду вызывать функции независимо.

Когда я захочу вместо макроса применить функцию, я даже имени такого не оставлю, а изменю, согласно своим "религиозным" убеждениям. Заменить не трудно, при желании, можно даже автоматом. Я стараюсь не плодить лишних сущностей. Об этом написал MrYuran в посте №3

Выберите что-нибудь из этого, или рядом пошарьте. http://www.holtek.com/english/products/compute_5.htm

Предложенную статью не осилил, я формул боюсь. Для восстановления сигнала требуется интерполяция sin(x)/x, которая как бы ни спадала, никогда не превращается в нуль. Требуется учитывать очень далекие отсчеты. А кадр данных имеет всегда конечный размер. И разрядность обработки тоже должна влиять. Поэтому приведенные вами цифры можно воспринимать, как "инженерное" решение, но не "научно обоснованное".

Например, так, без точки с запятой после макрофункции, хватит и ПРОПИСНЫХ_БУКВ_СО_СКОБКАМИ() #define I2C_CLOCK() {NOP(); SCL = 1; NOP(); SCL = 0;} if (...) I2C_CLOCK() else return;

Увы... :crying: Не могли бы вы словами описать, за счет чего будет оптимизация. Пока что вижу разрастание кода... Как будет у меня: int main(void) { ... Control(); Indication(); ... Indication(); } void Control(void) { ... } void Indication(void) { ... } Другой вариант: int main(void) {... Control(); ... Indication(); } void Control(void) { ... Indication(); } void Indication(void) { ... }

Прокомментирую сам. Квалификатор static будет иметь смысл, если я эти функции заброшу в отдельный файл. Таких функций у меня несколько десятков, что ж, мне, столько файлов создавать? Не вижу смысла. P.S. Где-то здесь и зарыта собака "неполной структурированности" языка C. P.P.S. По поводу do {...} while (0) - а чем плохо показанное в той же статье строчкой выше {...} ? Разве кто-то заставляет писать I2C_CLOCK(); с точкой с запятой в конце? Или в дефайне можно было задать #define I2C_CLOCK(); {NOP(); SCL = 1; NOP(); SCL = 0;} Да, это не работает (кажется, в Hi-Tech PICC у меня получалось такое, а в Keil - нет)

Я не борюсь, а интересуюсь. Мне уже очевидно, что сделать нельзя. А вот здесь желательны комментарии. :)