Comments 15

Я конечно не работал с HX711, но мне кажется ее интерфейс проще подключить к SPI.
Тогда вся статья свелась бы к


nrf_drv_spi_config_t spi_config = NRF_DRV_SPI_DEFAULT_CONFIG(SPI_INSTANCE);
spi_config.frequency = SPI_FREQUENCY_FREQUENCY_K500;
spi_config.mode = NRF_DRV_SPI_MODE_1;
spi_config.miso_pin = SPI_MISO_PIN;
spi_config.mosi_pin = SPI_MOSI_PIN;
spi_config.sck_pin = SPI_CLK_PIN;
APP_ERROR_CHECK(nrf_drv_spi_init(&spi, &spi_config, 0));

и последующим вызовом


nrf_drv_spi_transfer(&spi, tx_data, 1, rx_data_, 1);

Там на той же линии (DOUT) готовность еще идет. Если завести ее на отдельную ногу и там считывать ее состояние и запускать передачу, когда она упадет, то по идее можно. И еще, вроде как надо считывать данные по заднему фронту… В документации на АЦП вроде как при переходе с 1 в 0 попадаем на данные, но автор почему то считывает данные по переходу из 0 в 1.

В настройках SPI микроконтроллеров же обычно можно указать, по какому фронту читать-посылать данные?
А в NRF можно повесить прерывание на ногу MISO? Если да, то вроде и дополнительную ногу можно не использовать.

В настройках SPI микроконтроллеров же обычно можно указать, по какому фронту читать-посылать данные?

Обычно в микроконтроллерах есть конечно, наверное в этом тоже, я не знаю, я с ним не работал… Просто в примера выше, такой настройки не производится вроде, не знаю что означает spi_config.mode = NRF_DRV_SPI_MODE_1;, может это как раз?


А в NRF можно повесить прерывание на ногу MISO?

Я так понимаю, он по прерыванию будет работать, но по SPI прерыванию — уходу/приходу байта, или просто в режиме опроса флага, пока байт не уйдет/придет. Но даже если он по опросу будет делать, нога в этот момент используется как spi MISO и не может одновременно использоваться как прерывание от порта и как аппаратный MISO spi.

Но даже если он по опросу будет делать, нога в этот момент используется как spi MISO и не может одновременно использоваться как прерывание от порта и как аппаратный MISO spi.


Не совсем так. На самом деле можно так делать. Только лучше использовать не прерывание, а событие.
У нордиков очень своеобразная периферия, по меркам ST даже бедновато. НО, при правильном подходе к ней она дает огромное преимущество.

Например, можно сделать более красиво и изящно, периферия это позволяет. Опишу немного абстрактно как это можно сделать:

0. Заводиться группа PPI. В нее добавляем один канал, который будет по-сути DREADY сигналом. Группа нужно из-за одной замечательной фукнции, ее можно включать\выключать через PPI.

1. Канал PPI настраиваем на старт чтения через SPI и отключение группы. Это нужно, чтобы не реагировать на каждый перепад фронта во время чтения;

2. второй канал PPI нужен для обратного включения группы после окончания чтения SPI.

дополнительно можно ещё и на счетчик это дело бросить, тогда ядрышко проснется только после получения, скажем 10, отсчетов.

если сильно интересно, могу поделиться своим опытом с nrf52840. Я на нем как раз с++ осваиваю)
Вы правельно подметили, там действительно опечатка.
nrf_drv_gpiote_in_config_t gpiote_config = GPIOTE_CONFIG_IN_SENSE_HITOLO(true). Спасибо!!!
Я думаю что вы правы, я увлекся китайским даташитом )). Будет время проверю.
nRF Connect for Desktop не пробывали? В комплекте идёт Toolchain Manager, через который устанавливается nRF Connect SDK (на данный момент актуальная версия 1.3.1)
оно по другую тему. nRF Connect SDK — эта штука заточена больше по работу с операционкой зефир. Отсюда тенятся необходимость доустановки средств сборки зефира и проектов на нем. Не сложно, но долго.
Да и задача тут такая, что в обычном NRF5_SDK она решается проще.
У нордика самый ублюдочный SDK с высоченным пирогом абстракций, в котором слои легаси идут вперемешку с обновлённым кодом. И документация такая же.
Не соглашусь насчет документации, она более приятная чем у тех же ST или TI.

Это вы еще не пробовали вести свои проекты в этом SDK… у них на форуме про SDK мелькает фраза иногда «welcome to SDK pain!»
Это вы еще не пробовали вести свои проекты в этом SDK…

Я как раз не только пробовал, а три проекта сдал на этом куске дерьма.
Длительность в 10мкс на импульс это примерно в 10 раз больше значения из даташита,, а минимальное и вовсе 0.2мкс. Учитывая что надо сделать 25 импульсов, с периодом 20 мкс, процесс считывания можно радикально сократить, что может быть полезно в энергосберегающем режиме при работе от батареек.
Да вы абсолютно правы по даташиту типичная длительность импульса 1мкс, макс. 50мкс. Это был тестовый вариант проекта только, чтоб подтвердить его работоспособность. Спасибо.
Only those users with full accounts are able to leave comments. Log in, please.