Ср янв 05, 2022 20:56:29
главный колбасист писал(а):...ldi r30,0xdf
ld r20,r30
Ср янв 05, 2022 23:46:33
Чт янв 06, 2022 00:39:48
ld r16,z
#define pointer_2 z
#define tmp0 r16
ld tmp0,pointer_2
; ***** CPU REGISTER DEFINITIONS *****************************************
.def XH = r27
.def XL = r26
.def YH = r29
.def YL = r28
.def ZH = r31
.def ZL = r30
#define ptrd_h XH
#define ptrd_l XL
Чт янв 06, 2022 01:54:45
Чт янв 06, 2022 10:01:46
Чт янв 06, 2022 19:16:40
ld r20,Z
Где Вы откопали
ld r20,r30
???
Чт янв 06, 2022 20:07:27
Чт янв 06, 2022 20:08:38
Чт янв 06, 2022 20:18:43
Ничего не понял. Вы что-то не так делаете.
Чт янв 06, 2022 20:22:30
Чт янв 06, 2022 20:57:33
Чт янв 06, 2022 21:05:23
1. Настройка i2c
2. i = 0
3. IIC_START i2c
4. IIC_SEND (3231_ADDR+i)
5. if (i = 0)
then begin
6. IIC_SEND 0x00 ;адрес, с которого мы будем читать данные из 3231
7. goto 16
end
else begin
8. j = 7 ; число байт, которые надо прочитать
9. Z = (адрес области памяти для чтения из 3231)
10. j = j - 1
11. if (j > 0) then IIC_READ_ASK
else IIC_READ_NASK
12. save DATA -> Z
13. Z = Z + 1
14. if (j > 0) then goto 10
15. end ; конец блока else для if (i=0)
16. i = i + 1
17. if ( i < 2 ) then goto 3
18. IIC_STOP
;----------
; I2C Code
;----------
; по мотивам DiHalt'a
;----------
; Работа с IIC передатчиком. Предупреждаю -- это быдлокод!
; Несмотря на то, что так делают почти все :)
; Но это медленно и тормозно, особенно в свете использования
; RTOS. Почему? Да потому что использует глухое
; ожидание флага готовности IIC. Вместо того, чтобы отдать
; управление диспетчеру задач. Также нет обработоки ошибок
; и какой либо оценки прошла команда или нет. Просто пример!
;----------
; IIS_START — устраивает на шине Start состояние
; IIC_SEND — посылает байт, просто байт. Не важно что это — адрес, данные…
; IIC_READ_ASK — команда противополжная предыдущей — принимает байт в конце дает ACK
; IIC_READ_NASK — тоже принимает байт, но в конце дает NACK, используется для приема последнего байта,
; чтобы дать понять Slave устройству что мы в его услугах больше не нуждаемся.
; IIS_STOP — устраивает на шине Stop состояниеи освобождает линию
;----------
; Последовательность инициализации TWI (i2c)-интерфейса
; Рассматривается только Master-режим
; В регистр TWBR, а так же в биты 0,1 (TWPS0:1) регистра TWSR записываются константы для определения скорости шины.
; (констатны можно рассчитать на AVRCalc)
;----------
; Последовательность чтения для IIC, на примере обычной EEPROM типа АТ24Схх обычно такая:
; Старт
; Адрес дейвайса[write]
; Адрес ячейки откуда будем читать
; Повторный Старт,
; Адрес девайса [read],
; Байт из адресованой ячейки,
; Байт из адресованой ячейки+1,
; Байт из адресованой ячейки+2
; ….
; Cтоп
;
; Последовательность записи для IIC обычно такая:
; Старт
; Адрес девайса [write]
; Адрес ячейки куда будем писать
; Данные раз
; Данные два
; Данные три
; …..
; Стоп
; [write] & [read] - младший бит адреса. =0 - запись, =1 - чтение
;
;----------
; примеры для работы с часами - см. http://easyelectronics.ru/chasy-realnogo-vremeni-pcf8583.html
;----------;
; Даем старт на линию I2C
; Портит R16,SREG
IIC_START:
LDI R16,1<<TWINT|1<<TWSTA|1<<TWEN|0<<TWIE
OUT TWCR,R16
IIC_S:
IN R16,TWCR
ANDI R16,1<<TWINT
BREQ IIC_S ; Ждем пока передатчик IIC выполнит старт
RET
;----------
;Посылаем байт (R16) по IIC
; Портит R16,SREG
IIC_SEND:
OUT TWDR,R16
LDI R16,1<<TWINT|1<<TWEN|0<<TWIE
OUT TWCR,R16
IIC_B:
IN R16,TWCR
ANDI R16,1<<TWINT ; Ждем пока передатчик пошлет байт
BREQ IIC_B
RET
;----------
; Принять байт.
; Принятый байт в R16
; Портит SREG
IIC_READ_ASK:
LDI R16,1<<TWINT|1<<TWEN|1<<TWEA|0<<TWIE
OUT TWCR,R16
IIC_R:
IN R16,TWCR
ANDI R16,1<<TWINT
BREQ IIC_R ; Ждем пока байт будет принят
IN R16,TWDR
RET
;----------
; Принять последний байт. Помните я писал о разнице между просто байтом и последним
; байтом? В последнем байте не генерируется ACK!!!
; Принятый байт в R16
; Портит SREG
IIC_RREAD_NACK:
LDI R16,1<<TWINT|1<<TWEN|0<<TWEA|0<<TWIE
OUT TWCR,R16
IIC_R2:
IN R16,TWCR
ANDI R16,1<<TWINT ; Ждем пока байт будет принят
BREQ IIC_R2
IN R16,TWDR
RET
;----------
; Сгенерировать STOP
; Портит R16,SREG
IIC_STOP:
LDI R16,1<<TWINT|1<<TWSTO|1<<TWEN|0<<TWIE
OUT TWCR,R16
IIC_ST:
IN R16,TWCR
ANDI R16,1<<TWSTO
BREQ IIC_ST ; Ждем пока не будет готов стоп.
RET
Пт янв 07, 2022 00:12:07
Работа с IIC передатчиком. Предупреждаю -- это быдлокод!
Несмотря на то, что так делают почти все
Но это медленно и тормозно, особенно в свете использования
RTOS. Почему? Да потому что использует глухое
ожидание флага готовности IIC.
Пт янв 07, 2022 01:36:49
Пт янв 07, 2022 11:05:36
Пт янв 07, 2022 11:13:27
абсолютно верно! ни коллизий, ни потерь битов в правильно сконструированном девайсе на шине I2C быть не может! и нужды в анализе этих битов нет никакой. от слова совсем.GoldenAndy писал(а):Обычно i2c-устройства - это не plug'n'play, а запаянные на плату конкретные устройства. И при исправности всех устройств обмен по шине не должен выдавать ошибки.
как я неоднократно утверждал в разных других темах, реальная необходимость действительно параллельно что-то делать в любительских проектах возникает крайне-крайне-крайне редко. более того, после реализации этой "истинной" параллельности обычно оказывается, что никакого выигрыша нет вообще, только напрасно потраченное время. но это моё мнение, оно может не совпадать с мнением редакцииGoldenAndy писал(а):Если уже параллельно процессу обмена нужно что то выполнять
и тут согласен на все 100%.GoldenAndy писал(а):проще всего эти задержки делать на тупых циклах
Пт янв 07, 2022 12:49:46
Ну, тут нужно заложить какой то гипотетический случай на выход из строя i2c-ведомого устройства.... Но с этим прекрасно справится таймаут ожидания - делается на одном регистре и трех ассемблерных командах (пишу по памяти, но могу и криво написать, на асме очень давно не писал, в основном голый Си)ARV писал(а):ни коллизий, ни потерь битов в правильно сконструированном девайсе на шине I2C быть не может!
У меня такое было всего один раз. Когда приходилось читать по i2c из INA219 1000 раз в сек попеременно значения тока и напряжения, класть их в буфер и обрабатывать. И это была основная задача - там действительно пришлось использовать прерывание и конечный автомат. Таймер дергал старт обмена, а конечник в прерывании i2c обрабатывал всю лог.цепочку. При этом в прерывании таймера обрабатывались значения тока и напряжения из предыдущего цикла. И это была основная задача МК. А оставшееся от всей этой кухни время - это формирование изображения для дисплея, вывод его по SPI через DMA. По второму i2c был обмен с EEPROMкой внешней, но он редкий, там настройки живут и калибровочные константы. Тут уже былл обмен на ожиданиях, ибо основная задача работает реалтаймово на прерываниях.ARV писал(а):реальная необходимость действительно параллельно что-то делать в любительских проектах возникает крайне-крайне-крайне редко
Пт янв 07, 2022 13:03:52
Пт янв 07, 2022 13:34:32
Пт янв 07, 2022 14:01:48