- Добро пожаловать на форум умных покупателей! Присоединяйтесь к нашей уютной компании и участвуйте в обсуждениях – Регистрация
I
Ivan
Новичок
при записи этих файлов система изначально освободила (имеется ввиду удалила) необходимое место на карте, вот и получается что при начале записи второй части ничего на карте удалять не надо и соответственно время разрыва уменьшается
M
Mark_KA
Продвинутый
Что мешает делать так-же при циклической записи?
M
m72m72
Начинающий
Serge-bay
Угу. Через два гига боятся перешагнуть. Почему7 Да кто их китайсев знает.
Ivan
Ты не считал, сколько времени надо на удаление файла? Так я тебе скажу. Гораздо меньше, чем кажется. Там всего несколько байт черкануть в ФАТ и в каталоге. Вот и всё удаление. Это чуть - пара секторов, несколько килобайт. А за секунду пишется 1 МЕГАбайт данных, при этом ФАТ так же правится, ка ки при стирании, только в другую сторону. То, что винда тупит при стирании - так на то она и винда. Но разрывы то есть и когда ничего стирать не надо! Т.е. при первом заполнении карточки!
И заметь при переходе на другой файл время разрыва не уменьшается. РАЗРЫВА ВООбЩЕ НЕТ. Нет разрыва! Все 30 кадров со значение одной и той же секунды на месте.
Умные люди вообще фат не трогают при записи в регистраторах. На этапе инициализации флешки на ней размечаются файлы, которые потом вычеркиваются только из оглавления. Так что любой чек диск будет матом орать, но тем не менее содержиме будет раскидано правильно и если не докапываться, то файловая система вполне в порядке.
Mark_KA
Что мешает? Да лень и тупость, больше нечего.
Как сделано сейчас:
Взяли видеокамеру и накинули старт/стоп видеозаписи по таймеру. Ну еще удаление предыдущих файлов. Даже не удивлюсь, что настолько им лень было, что эмулируют это через нажатие на кнопочки.
По хорошему - надо чуть глубже копнуть и все дела. Ведь есть же ПОЛНЫЕ исходники, которые к SDK прилагаются. Вот там найти те самые упоминания про два гига, при которых файл на части режется и подставлять для каждого разрешения свой размер файла. Да, не будет точно по одной минуте нарезано, зато кадры пропадать не будут.
Про глюки с таймером ГПС. Ну тупые они, тупые. Нашли где-то библиотеку, которая поток данных с ГПС переваривает. Суют ей строчки с ГПС и получают время по гринвичу и координаты. Но они же тупят. Не надо дату корректировать, когда уже день/час получены из количества секунд. Надо к изначальным секундам добытым из ГПС прибавить 3600*время сдвига и затем уже дату готовую получать на руки. Ничего мудрить со сдвигом часов не надо. Но это ж китайсы. Им библиотеку то подправить слабо...
Везде косяки копеечные, но мерзкие и много. Вот реально, я таких ляпов даже в когда в школе учился не делал...
Угу. Через два гига боятся перешагнуть. Почему7 Да кто их китайсев знает.
Ivan
Ты не считал, сколько времени надо на удаление файла? Так я тебе скажу. Гораздо меньше, чем кажется. Там всего несколько байт черкануть в ФАТ и в каталоге. Вот и всё удаление. Это чуть - пара секторов, несколько килобайт. А за секунду пишется 1 МЕГАбайт данных, при этом ФАТ так же правится, ка ки при стирании, только в другую сторону. То, что винда тупит при стирании - так на то она и винда. Но разрывы то есть и когда ничего стирать не надо! Т.е. при первом заполнении карточки!
И заметь при переходе на другой файл время разрыва не уменьшается. РАЗРЫВА ВООбЩЕ НЕТ. Нет разрыва! Все 30 кадров со значение одной и той же секунды на месте.
Умные люди вообще фат не трогают при записи в регистраторах. На этапе инициализации флешки на ней размечаются файлы, которые потом вычеркиваются только из оглавления. Так что любой чек диск будет матом орать, но тем не менее содержиме будет раскидано правильно и если не докапываться, то файловая система вполне в порядке.
Mark_KA
Что мешает? Да лень и тупость, больше нечего.
Как сделано сейчас:
Взяли видеокамеру и накинули старт/стоп видеозаписи по таймеру. Ну еще удаление предыдущих файлов. Даже не удивлюсь, что настолько им лень было, что эмулируют это через нажатие на кнопочки.
По хорошему - надо чуть глубже копнуть и все дела. Ведь есть же ПОЛНЫЕ исходники, которые к SDK прилагаются. Вот там найти те самые упоминания про два гига, при которых файл на части режется и подставлять для каждого разрешения свой размер файла. Да, не будет точно по одной минуте нарезано, зато кадры пропадать не будут.
Про глюки с таймером ГПС. Ну тупые они, тупые. Нашли где-то библиотеку, которая поток данных с ГПС переваривает. Суют ей строчки с ГПС и получают время по гринвичу и координаты. Но они же тупят. Не надо дату корректировать, когда уже день/час получены из количества секунд. Надо к изначальным секундам добытым из ГПС прибавить 3600*время сдвига и затем уже дату готовую получать на руки. Ничего мудрить со сдвигом часов не надо. Но это ж китайсы. Им библиотеку то подправить слабо...
Везде косяки копеечные, но мерзкие и много. Вот реально, я таких ляпов даже в когда в школе учился не делал...
M
m72m72
Начинающий
Так-с.
Погорячился, был неправ насчет секунд и часовых поясов. Признаю.
Сейчас посмотрел логи с ГПС модуля.
Действительно с ГПС приемника приходит время в виде hhmmss.sss и дата в виде ddmmyy.
Т.е. просто прибавить 3600*N секунд не получится... Надо вручную дату туда-сюда преобразовывать. Но как бы не вижу ничего страшного в этом, хотя да, парой строк не обойдешься и придется учитывать високосность года для 29 февраля. Но! Ведь девайс этот не вечен и жить ему лет пять максимум, так что заморачиваться на тему вискосности 2100 года явно не стоит. Это же не механические часы образца 1890 года с календарем.
Так что деление года на 4 вполне сошло бы с рук.
Погорячился, был неправ насчет секунд и часовых поясов. Признаю.
Сейчас посмотрел логи с ГПС модуля.
Действительно с ГПС приемника приходит время в виде hhmmss.sss и дата в виде ddmmyy.
Т.е. просто прибавить 3600*N секунд не получится... Надо вручную дату туда-сюда преобразовывать. Но как бы не вижу ничего страшного в этом, хотя да, парой строк не обойдешься и придется учитывать високосность года для 29 февраля. Но! Ведь девайс этот не вечен и жить ему лет пять максимум, так что заморачиваться на тему вискосности 2100 года явно не стоит. Это же не механические часы образца 1890 года с календарем.
Так что деление года на 4 вполне сошло бы с рук.
S
Serge-bay
Новичок
Ну так и календарь там всё-равно есть, время же идёт и дата правильно(надеюсь) меняется, даже елси жпс был пойман позавчера и устройство не выключалось. в крайнем случае в ф200-500-900 же есть календарь :celebrity: даже если в 600м они каждый раз в 00-01 у жпс спрашивают дату.
M
mtsblogs
Новичок
Сергей совершенно верно говорит.
одна строчка:
hh = (hh + GMT_offset)
Если новое hh больше 24 (например 23 по гринвичу + 3 для Москвы hh = 26), то выбрать следующий день и отнять от hh 24.
Если новое hh меньше 0, то выбрать предыдущий день и прибавить к hh 24. (это для америки)
Глюк может быть со второй частью. Первая точно прописана, ведь календарь день меняет вперед ок, а вот сменить назад не факт что умеет.
одна строчка:
hh = (hh + GMT_offset)
Если новое hh больше 24 (например 23 по гринвичу + 3 для Москвы hh = 26), то выбрать следующий день и отнять от hh 24.
Если новое hh меньше 0, то выбрать предыдущий день и прибавить к hh 24. (это для америки)
Глюк может быть со второй частью. Первая точно прописана, ведь календарь день меняет вперед ок, а вот сменить назад не факт что умеет.
M
m72m72
Начинающий
Serge-bay
Для тех кто не знаком со схемотехникой расскажу немного.
Есть так называемые микросхемы RTC - real time clock. Собственно календарь находится в этой микросхеме (или её аналоге на кристалле микроЭВМ), чтобы при проектировании микропроцессорных систем программисту не надо было тратить силы и память программ на пересчет времени туда/сюда, учитывание високосных годов и т.д. и т.п.
Короче микросхема RTC отдает время и дату в привычном человеку виде, т.е. год, месяц, день, часы, минуты, секунды отдельно. Эта же микруха отвечает за переход месяца, года и т.д. В итоге ЛЕНИВОМУ программисту даже не надо заморачиваться. Тупо считывать дату/время из портов микрухи и полученные цифры выводить на экран, что и делается во всех поделках Fx00.
И это четко видно, т.к. дата и время, когда они сама по себе (девайсы без ГПС, на GS600 после того как спутники поймалмсь, время выставили и больше не трогают), тикают правильно, ибо берется готовыми из микрухи. А вот когда дату исправляют, точнее выставляют полученные из GPS данные, то и случается глюк. Кстати, это так же подтверждает, что часы всегда равны нулю в баговых ситуациях. В RTC прописывают либо -1, -2, либо 24, 25... часов, а RTC это переваривает, но именно как железка. Тупо выставляет неправильные параметры нуль часов, тем самым приводя дату/время к допустимом значениям.
У RTC есть офигенный плюс: схемотехника отработана годами, календари не сбоят, сама по себе очень дуракоустойчивое изделие. Когда делаешь девайс на микроконтроллере у которого 8 КИЛОБАЙТ памяти под код, то очень удобно.
mtsblogs
Ага. Одна строчка. Именно так китайцы и сделали. И забыли об этом.
Ты почти угадал, только забыл, что следующий день может оказаться в новом месяце, новом году и т.д. А это уже не пара строчек. При этом не забывай, что еще есть високосные года, когда наступление 29 февраля не означает необходимости перехода на март месяц.
Опять же для перехода в обратном направлении, т.е. когда оффсет GMT отрицательный (это в Америке) тоже может потребоваться перейти на предыдущий день, месяц, год. Опять же в 2012 году перед 1 марта будет 29 февраля, а в 2011 только 28.
С таким китайский мозг среднего "разработчика" уже не справляется. Он только может скопировать сэмп из референса и обозвать это готовым изделием. Ога.
Для тех кто не знаком со схемотехникой расскажу немного.
Есть так называемые микросхемы RTC - real time clock. Собственно календарь находится в этой микросхеме (или её аналоге на кристалле микроЭВМ), чтобы при проектировании микропроцессорных систем программисту не надо было тратить силы и память программ на пересчет времени туда/сюда, учитывание високосных годов и т.д. и т.п.
Короче микросхема RTC отдает время и дату в привычном человеку виде, т.е. год, месяц, день, часы, минуты, секунды отдельно. Эта же микруха отвечает за переход месяца, года и т.д. В итоге ЛЕНИВОМУ программисту даже не надо заморачиваться. Тупо считывать дату/время из портов микрухи и полученные цифры выводить на экран, что и делается во всех поделках Fx00.
И это четко видно, т.к. дата и время, когда они сама по себе (девайсы без ГПС, на GS600 после того как спутники поймалмсь, время выставили и больше не трогают), тикают правильно, ибо берется готовыми из микрухи. А вот когда дату исправляют, точнее выставляют полученные из GPS данные, то и случается глюк. Кстати, это так же подтверждает, что часы всегда равны нулю в баговых ситуациях. В RTC прописывают либо -1, -2, либо 24, 25... часов, а RTC это переваривает, но именно как железка. Тупо выставляет неправильные параметры нуль часов, тем самым приводя дату/время к допустимом значениям.
У RTC есть офигенный плюс: схемотехника отработана годами, календари не сбоят, сама по себе очень дуракоустойчивое изделие. Когда делаешь девайс на микроконтроллере у которого 8 КИЛОБАЙТ памяти под код, то очень удобно.
mtsblogs
Ага. Одна строчка. Именно так китайцы и сделали. И забыли об этом.
Ты почти угадал, только забыл, что следующий день может оказаться в новом месяце, новом году и т.д. А это уже не пара строчек. При этом не забывай, что еще есть високосные года, когда наступление 29 февраля не означает необходимости перехода на март месяц.
Опять же для перехода в обратном направлении, т.е. когда оффсет GMT отрицательный (это в Америке) тоже может потребоваться перейти на предыдущий день, месяц, год. Опять же в 2012 году перед 1 марта будет 29 февраля, а в 2011 только 28.
С таким китайский мозг среднего "разработчика" уже не справляется. Он только может скопировать сэмп из референса и обозвать это готовым изделием. Ога.
R
Rustamische
Новичок
Да уж поторопился я с покупкой, изделие оказалось из серии "работаю как хочу а если не хочу то ваще не работаю" постоянно зависает, пока карту не отформатирую на запись не включается, после заполнения карты старые файлы не затираются или можт я не так чот делаю. Попробую вернуть обратно китайцам
M
mtsblogs
Новичок
m72, ты не читаешь, что пишу я и Сергей.
Одна строчка решает, что делать.
Не нужно считать, какой будет следующий день. Система уже умеет включать следующий день, вот это и нужно запустить: gosub next_day
Смотреть какой месяц будет, какой день... - все ерунда, это уже заложено в next_day.
Потенциальная проблема - откатка назад. Это если в софте все реализовано.
А если RTC, как ты вспомнил.
Ты их лично когда-нибудь использовал? Не просто включал, а программировал чип, чтоб работал с RTC и временными зонами? Тогда знал бы, что и високосный год, и месяц и все дела считывается одной командой, а затем одной же строчкой правится и записывается назад. Все реально делается парой строк. Основное - if hh>23 then hh=hh-24. Остальное мелочи.
offset_up: // на примере увеличения времени
if hh > 23 then inc dd, hh = hh-24 // первая строчка
if (dd = 31 & (mm = 4 | mm = 6 | mm = 9 | mm = 11)) | ( dd = 29 & mm = 2 & leap = 0 ) | (dd = 30 & mm = 2 ) | (dd = 32 ) then inc mm, dd = 1 // вторая
if mm = 13 then mm = 1, inc yy // правка месяца
return
где inc = increase (AKA ++)
& = Logic AND
| = Logic OR
Одна строчка решает, что делать.
Не нужно считать, какой будет следующий день. Система уже умеет включать следующий день, вот это и нужно запустить: gosub next_day
Смотреть какой месяц будет, какой день... - все ерунда, это уже заложено в next_day.
Потенциальная проблема - откатка назад. Это если в софте все реализовано.
А если RTC, как ты вспомнил.
Ты их лично когда-нибудь использовал? Не просто включал, а программировал чип, чтоб работал с RTC и временными зонами? Тогда знал бы, что и високосный год, и месяц и все дела считывается одной командой, а затем одной же строчкой правится и записывается назад. Все реально делается парой строк. Основное - if hh>23 then hh=hh-24. Остальное мелочи.
offset_up: // на примере увеличения времени
if hh > 23 then inc dd, hh = hh-24 // первая строчка
if (dd = 31 & (mm = 4 | mm = 6 | mm = 9 | mm = 11)) | ( dd = 29 & mm = 2 & leap = 0 ) | (dd = 30 & mm = 2 ) | (dd = 32 ) then inc mm, dd = 1 // вторая
if mm = 13 then mm = 1, inc yy // правка месяца
return
где inc = increase (AKA ++)
& = Logic AND
| = Logic OR
M
m72m72
Начинающий
mtsblogs
1. Читаю.
2. Как бы за 25 лет топтания кнопок и тыкания в платы паяльником многое повидал и перепробовал. RTC тоже попадались на пути.
3. next_day - прикольно. Зуб даешь, что эта функция есть в SDK для Ambarella?
4. Такой стиль "одной строчкой" давно считается правилом плохого тона, т.к. в случае чего, при редизайне софта, понять что имел в виду программист и устранить пойманный баг достаточно сложно. Иногда приходится вообще всё с нуля переписывать, т.к. изменения невозможно вписать в такую конструкцию.
Все оптимизации кода уж лет 30 как берет на себя компилятор, если он не тупой и ему без разницы, одна строка кода или двадцать. Зато читабельность кода на уровне. Компиляторы "слово-в-слово" я давно не встречал.
5. Откатка назад абсолютно не проблема. Пишется ровно столько же кода. Ломать мозг ради написания "двухстрочной" конструкции влом, хотя и могу. Но зачем?
6. Про основное и не очень. Да, это элементарно hh+offset и затем проверить на переход через 24. Только всё остальное и занимает 90% кода, который однако НАДО писать, каким бы рутинным это не казалось и как бы этого не хотелось. Проверки на ошибки, допустимости диапазонов и проч. Увы девайсы для правильной работы которых надо отварить сушеную лапку кролика не позднее трех часов после полуночи меня не устраивают. Девайс должен работать в любое время суток, месяца и года. Работа не должна зависеть от фаз луны и парада планет.
Увы, вот китайсы тоже положились на то, что "всё просто", добавили смещение и забили на всё остальное. В итоге имем, что имеем.
1. Читаю.
2. Как бы за 25 лет топтания кнопок и тыкания в платы паяльником многое повидал и перепробовал. RTC тоже попадались на пути.
3. next_day - прикольно. Зуб даешь, что эта функция есть в SDK для Ambarella?
4. Такой стиль "одной строчкой" давно считается правилом плохого тона, т.к. в случае чего, при редизайне софта, понять что имел в виду программист и устранить пойманный баг достаточно сложно. Иногда приходится вообще всё с нуля переписывать, т.к. изменения невозможно вписать в такую конструкцию.
Все оптимизации кода уж лет 30 как берет на себя компилятор, если он не тупой и ему без разницы, одна строка кода или двадцать. Зато читабельность кода на уровне. Компиляторы "слово-в-слово" я давно не встречал.
5. Откатка назад абсолютно не проблема. Пишется ровно столько же кода. Ломать мозг ради написания "двухстрочной" конструкции влом, хотя и могу. Но зачем?
6. Про основное и не очень. Да, это элементарно hh+offset и затем проверить на переход через 24. Только всё остальное и занимает 90% кода, который однако НАДО писать, каким бы рутинным это не казалось и как бы этого не хотелось. Проверки на ошибки, допустимости диапазонов и проч. Увы девайсы для правильной работы которых надо отварить сушеную лапку кролика не позднее трех часов после полуночи меня не устраивают. Девайс должен работать в любое время суток, месяца и года. Работа не должна зависеть от фаз луны и парада планет.
Увы, вот китайсы тоже положились на то, что "всё просто", добавили смещение и забили на всё остальное. В итоге имем, что имеем.
M
mtsblogs
Новичок
Не читаешь.
next_day конечно присутствует, если и не в sdk, то уже написана и так: девайс успешно переключает день уже сейчас, значит это умеет. Значит функцию можно вызвать один раз дополнительно.
Сколько можно про это писать?
И я правильно понял, что "плохой тон" это потому что ты не смог разобраться с логическими операторами? Хорошо что на примере ассемблера не показал.
"RTC попадились на пути" и работать с ними (и с gps в том числе) в коммерческой компании придумывая новые штуки - разные вещи.
А плохой тон (чтоб другие видя исходник не поняли что там) это когда каждая переменная и каждая функция не больше трех букв/цифр, включая начальные регистры. Вот тогда действительно понятно только тому, кто писал, да и то пока не забыл.
next_day конечно присутствует, если и не в sdk, то уже написана и так: девайс успешно переключает день уже сейчас, значит это умеет. Значит функцию можно вызвать один раз дополнительно.
Сколько можно про это писать?
И я правильно понял, что "плохой тон" это потому что ты не смог разобраться с логическими операторами? Хорошо что на примере ассемблера не показал.
"RTC попадились на пути" и работать с ними (и с gps в том числе) в коммерческой компании придумывая новые штуки - разные вещи.
А плохой тон (чтоб другие видя исходник не поняли что там) это когда каждая переменная и каждая функция не больше трех букв/цифр, включая начальные регистры. Вот тогда действительно понятно только тому, кто писал, да и то пока не забыл.
P
poweruser007
Новичок
И мне GS600 приехал. Заказал в начале января числа 6-го примерно. Версия V1.2.2H. С комплектностью косяк - дали кабель miniUSB, а на девайсе разъем microUSB, хорошо, у меня от фотоаппарата был такой кабель в наличии. Вначале не хотел запускаться от 12В в машине, я даже его разобрал, посмотрел, вроде все ок, собрал - подключил - работает. Вот и пойми, что это было.
Что интересно, в инструкции сказано, что на него должно подаваться строго +5В! Но в прилагаемом автокабеле нет никакого преобразователя, а внутри, наоборот, преобразователь есть. То есть на самом деле там на вход должно идти именно +12, а от +5 он даже не запустился.
Пока исследую корректную работу, сегодня первый раз с ним проехал, позже отпишу результаты.
В целом собран очень даже ничего так (для китайцев), пластмасса нормальная, и внутри пайка не идеал, но покатит.
Еще мне непонятно, как эти китайцы предполагали подключать девайс к ТВ, если прилагаемый композитный кабель втыкается в разъем microUSB, то есть от компа его не запитаешь, т.к. разъем занят, а другого способа подать питание на устройство исходя из комплекта нет. То есть варианта два:
1) Сделать самому блок питания с разъемом, как у автомобильного кабеля (я так и сделал), использовать прилагаемый композитный кабель для подключения к ТВ.
2) Купить дополнительно кабель miniHDMI (для подключения к ТВ) + кабель microUSB (для подачи питания с компа). Какого фига они тогда не приложили оба эти кабеля?
Что интересно, в инструкции сказано, что на него должно подаваться строго +5В! Но в прилагаемом автокабеле нет никакого преобразователя, а внутри, наоборот, преобразователь есть. То есть на самом деле там на вход должно идти именно +12, а от +5 он даже не запустился.
Пока исследую корректную работу, сегодня первый раз с ним проехал, позже отпишу результаты.
В целом собран очень даже ничего так (для китайцев), пластмасса нормальная, и внутри пайка не идеал, но покатит.
Еще мне непонятно, как эти китайцы предполагали подключать девайс к ТВ, если прилагаемый композитный кабель втыкается в разъем microUSB, то есть от компа его не запитаешь, т.к. разъем занят, а другого способа подать питание на устройство исходя из комплекта нет. То есть варианта два:
1) Сделать самому блок питания с разъемом, как у автомобильного кабеля (я так и сделал), использовать прилагаемый композитный кабель для подключения к ТВ.
2) Купить дополнительно кабель miniHDMI (для подключения к ТВ) + кабель microUSB (для подачи питания с компа). Какого фига они тогда не приложили оба эти кабеля?
B
boyanos
Новичок
poweruser007
А где купил свой GS600?
А где купил свой GS600?
R
Rustamische
Новичок
Сегодня тестил в разных режимах, прошивка V1.1.7 E2.
Виснет через разные промежутки времени. К работе возвращается посредством кнопки RESET. Пробовал менять разные флешки не помогает. Написал претензию китайцам хотя надежды мало.
Виснет через разные промежутки времени. К работе возвращается посредством кнопки RESET. Пробовал менять разные флешки не помогает. Написал претензию китайцам хотя надежды мало.
M
m72m72
Начинающий
Значит так. Пришел типичный ответ китайцев: В новых версиях мы коррекцию времени GMT исправили, если хотите купить новые девайсы, вот наш новый прайс. Т.е. хрен (это овощ такой) кто что исправит. Знакомая ситуация, продавцы "Паленой Кошки" (Ц), т.е. сигналок Шерхан, ведут себя так же. Теперь понятно почему: Азия дело тонкое.
Live
