Ср янв 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
Пт янв 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