roman.com писал(а):а вдруг у нас важные данные на флешке... а флешка сломается/потеряется... и всё...
Это же нужно физическое соединение меги с пк? Не проще тогда флешку в пк вставить, и копируй куда угодно.
roman.com писал(а):берём ДВЕ флешки... подключаем к AVR... нажимаем кнопочку "копировать"...
Бред, полный.
roman.com писал(а):AVR читает сектора... начиная с нулевого и до последнего... ))
roman.com писал(а):затем всё копирует на вторую флешку...
Особенно это. Это нужна точно такая же флешка, да же без битых секторов.
olegue, на текущий момент я не видел нормального драйвера, который в режиме spi при записи не рушил файловую систему на карте, ладно уж не до фатального исхода. olegue, ты можешь это утверждение опровергнуть?
Dimon456 писал(а):Это же нужно физическое соединение меги с пк? Не проще тогда флешку в пк вставить, и копируй куда угодно.
ты форум вообще не читаешь))
[uquote="olegue",url="/forum/viewtopic.php?p=4242807#p4242807"]есть задумка перенести это все на esp8266, там готовый wifi есть[/uquote]
olegue писал(а):привлекает wifi модуль... что бы флэшку не дергать из устройства
[uquote="olegue",url="/forum/viewtopic.php?p=4242778#p4242778"]ПК меня интересует только в контексте передачи готовых файлов по Wifi на ftp сервер. Или через sim800 сразу в WEB...[/uquote]
круто !))
нафиг те флешки))
а давайте писать сразу в ОБЛАКО ))
[uquote="olegue",url="/forum/viewtopic.php?p=4243399#p4243399"]Если я задействую еще один аналоговый вход уже командой AnalogRead(pin4) на собьются ли настройки того первого аналогово входа с которого я пишу звук?[/uquote]
Нет, команда просто выполняет коммутацию каналов и запускает обработку АЦП, судя по исходникам: https://forum.arduino.cc/t/arduino-sour ... c/229752/4
н-да... я ожидал возможности работы с прерываниями, ардуина не способна генерировать прерывание по завершению преобразования AЦП?
Martian писал(а):я ожидал возможности работы с прерываниями, ардуина не способна генерировать прерывание по завершению преобразования AЦП?
мега328 способна генерировать прерывание по завершению преобразования AЦП, я к этому и подводил, скрестить АЦП и запись на карту, но, к сожелению, выше все померили, измерили, и сделали соответствующий вывод
roman.com писал(а):круто !))
нафиг те флешки))
а давайте писать сразу в ОБЛАКО ))
[uquote="Martian",url="/forum/viewtopic.php?p=4243600#p4243600"][uquote="olegue",url="/forum/viewtopic.php?p=4243399#p4243399"]Если я задействую еще один аналоговый вход уже командой AnalogRead(pin4) на собьются ли настройки того первого аналогово входа с которого я пишу звук?[/uquote]
Нет, команда просто выполняет коммутацию каналов и запускает обработку АЦП, судя по исходникам: https://forum.arduino.cc/t/arduino-sour ... c/229752/4
н-да... я ожидал возможности работы с прерываниями, ардуина не способна генерировать прерывание по завершению преобразования AЦП?[/uquote]
ну собственно случилось то что я и предполагал, при добавлении еще одого канал получения сигнала analogRead(A0) считывание с А0 происходит прекрасно, файл на флэшку якобы пишется и имеет размер ,но звука в нем нет!!!!
Добавлено after 1 minute 32 seconds:
analogRead - это 10 битная обработка с разрешение 1024, а вот звук насколько я понимаю у нас 8ми битный. Ну это так, рассуждения дилетанта.
Добавлено after 4 hours 39 minutes 28 seconds:
Не видать не будет этого. В паралельном проекте( там где используется библиотека TMRpsm.h написано в комментарии что не будет писать звук в Multi Mode. Я так понимаю что это режим использования несклькоих аналоговых входов одновременно. Не понимаю, конечно , в чем причина этого ограничения. Но вот удалось накопать такие мысли
в Setup() я задаю
SetupADC() где прописываю пин , ну типа ADMUX=0x61, т.е А1
А вот когда я в Loop() обращаюсь к пину А0, т.е пишут analogRead(A0), то больше к пину А1 я уже не возвращаюсь.
Вообще то вся работа по оцифровке , насколько я понимаю , происходит здеьс
ISR(TIMER2_COMPA_vect) {
///////////////////////////////
while (bit_is_set(ADCSRA, ADSC)); //необходимо убедиться, что другой канал ацп завершил работу. Возможно, в ардуине для это есть лучший способ
ADMUX=0x61; // переключаем канал на нужный
////////////////////////////////
sbi(ADCSRA, ADSC); // start ADC sample
while (bit_is_set(ADCSRA, ADSC)); // wait until ADSC bit goes low = new sample ready
recByteCount++; // increment sample counter
bufByteCount++;
if (bufByteCount == 64 && bufWrite == 0) {
bufByteCount = 0;
bufWrite = 1;
} else if (bufByteCount == 64 & bufWrite == 1) {
bufByteCount = 0;
bufWrite = 0;
}
if (bufWrite == 0) {
buf00[bufByteCount] = ADCH;
}
if (bufWrite == 1) {
buf01[bufByteCount] = ADCH;
}
// if (recByteCount % 128 < 64) { // determine which buffer to store sample into
// buf01[recByteCount % 64] = ADCH;
// } else {
// buf02[recByteCount % 64 ] = ADCH;
// }
}
Добавлено after 11 minutes 23 seconds:
А вообще, я бы и здесь переключился на A0 и заново запустил бы процесс оцифровки, а вот там, где был analogRead(A0) оставить лишь две проверки: первая, что AЦП завершил работу, вторая - что при этом был установлен вход А0. Таким образом, пока идёт запись звука и вся кухня с буфером, ацп спокойненько работает с другим входом. Разумеется, надо предварительно сохранить ADCH и ADCL куда-то во временные переменные. Наверное. Особо не разбирался, но, думаю, мысль понятна.
дело в том, что запись вызывается таймером, а аналогриад, как я понял, когда угодно. разумеется, начнётся конфликт. потому и предложил иной путь. ща покажу
The ADLAR determines the presentation of the ADC conversion result. If it is 1, the ADC conversion result is left adjusted. If 0, right adjusted. It is set to 0, right adjusted, by the Arduino software.
Что если я при сэмплировании тоже перейду на ADLAR=0. И тоггда не будет конфликта!
ISR(TIMER2_COMPA_vect) {
///////////////////////////////
while (bit_is_set(ADCSRA, ADSC)); //необходимо убедиться, что другой канал ацп завершил работу. Возможно, в ардуине для это есть лучший способ
ADMUX=0x61; // переключаем канал на нужный
////////////////////////////////
sbi(ADCSRA, ADSC); // start ADC sample
while (bit_is_set(ADCSRA, ADSC)); // wait until ADSC bit goes low = new sample ready
////////////////////
byte ah = ADCH;//сохраним на всяк случай, так как я не знаю работы остального кода
ADMUX=0x60; // переключаем канал на А0 наверное,если 0х60 если - это он
sbi(ADCSRA, ADSC); // запускаем ADC и идём делать наши дела
////////////////////////////
recByteCount++; // increment sample counter
bufByteCount++;
if (bufByteCount == 64 && bufWrite == 0) {
bufByteCount = 0;
bufWrite = 1;
} else if (bufByteCount == 64 & bufWrite == 1) {
bufByteCount = 0;
bufWrite = 0;
}
//////////////////////////////////////////////
if (bufWrite == 0) {
buf00[bufByteCount] = ah; //используем наш буфер
}
if (bufWrite == 1) {
buf01[bufByteCount] = ah;
}
///////////////////////////////////////////////
// if (recByteCount % 128 < 64) { // determine which buffer to store sample into
// buf01[recByteCount % 64] = ADCH;
// } else {
// buf02[recByteCount % 64 ] = ADCH;
// }
}
if (!bit_is_set(ADCSRA, ADSC) //убеждаемся, что ацп завершил работу
{
if (ADMUX == 0x60) //убеждаемся, что данные от нашего канала А0
{
byte ah = ADCH; //здесь берём данные из ADCH
byte al = ADCL; //и ADCL, далее работаем только c ahи al
}
}
Добавлено after 1 minute 22 seconds:
[uquote="olegue",url="/forum/viewtopic.php?p=4244632#p4244632"]И тоггда не будет конфликта![/uquote]сожалею но нет. просто изменится расположение битов, не более. Регистры-то останутся всё равно общими и изменятся оба.
Добавлено after 3 minutes 51 second:
это аналогично, как в analogRead(), но не всегда справедливо... зависит от расположения битов при выбранном выравнивании вправо или влево... но я не знаю атмегов.
сделай две процедуры АЦП подряд (те, что у тебя были изначально), но между ними впиши в адмукс значение для второго канала (скорее всего 0х60) и подожди 10мкс (вроде так по д.ш., уточню только завтра), после 2й процедуры оцифровки снова запиши в адмукс значение для первого канала (0х61)
Для тех, кто не учил магию мир полон физики
Безграмотно вопрошающим про силовую или высоковольтную электронику я не отвечаю, а то ещё посадят за участие в (само)убиении оболтуса...
это - нормальная? ну-ну. Результат не возвращает. Тратит время. Не проверяет готовность АЦП. И ничем особо не отличается от уже написанного AnalogRead(), какой в ней смысл?
Нормально - это написать обработчик прерывания АЦП, переключать каналы в нём и запустить АЦП в режим бесконечного преобразования, в итоге получая поток данных с нужного количества каналов, которые потом уже и обрабатывать.
Martian писал(а):Нормально - это написать обработчик прерывания АЦП
Я еще на какой странице про это торочил.
Ну нет у меня на этом компе протеуса, что бы проверить с какой скоростью идет семплирование, и ни кто здесь про это не сказал. При последовательной оцифровке двух каналов скорость семплирования в два раза упадет.
olegue, за чем тебе второй канал, куда ты его собрался использовать? Писать во второй файл на карту?
Имей ввиду этот драйвер, на верное, я не смотрел код, не поддерживает работу с двумя открытыми файлами.
Ты так и не ответил на вопрос, рушит ли он файловую систему на карте?