Atmel Studio 7, тема моя, код под тиньку 13а, но заработает на всех мегах

только энкодер должен быть на одном порту всеми ногами

Хм, с виду очень няшненько выглядит. Жаль, а то я ищу темку под эклипс

а мне старая тема больше нравилась :)

https://habrahabr.ru/post/274895/

Хм, а я всё ещё не могу определиться, белая или тёмная тема :( Тёмная удобнее для глаз, но внимание лично у меня становится каким-то рассеянным

Много факторов играют роль, например основные настройки цвета ок, но при выделении или поиске, если цвета выбиваются из общего контраста - аж бесит. Однажды так донастраивался, что потерял все комментарии. Только через неделю понял что чего-то нет ))

Народ, а кто какую структуру проекта (софт) использует в работе?

Просто интереса ради

Atmel Studio 7, Proteus 8, Arduino IDE, Processing, Eagle (и Spring Layout) для Атмел. Программатор - MiniPro A

зависит от проекта

Keil IAR, Eclipse, Arduino IDE, Processing, ST-Link v2 для STM32

Ненене, я имею ввиду папки, куда сорцы, куда файлы проекта вспомогательные и прочее

MSVS, Lasarus, Processing - для Винды

Платформа то какая?

Да вообще, в целом)) мне интересна организация проекта, кто что куда рсспихивает, чтобы потом можно было просто взять и собрать проект. У меня конкретно С++ для эмбеда, использую gcc. Но инструмент особой роли не играет же тут)

Обычно каждый проект в своей папке, созданные либы - просто выносятся и складируются, а при необходимости накидываются в проект и подключаются. (у меня так, потому что либы тоже правятся, и чаще всего под каждый проект)

Стандарта нет короче, я не поточник.

Понятно) а то я тут ищу варианты получше, думал, что может уже кто-то за меня изобрел удобный велосипед

я не настолько крут. Ничего из исходника не вытаскиваю

Прост есть какието готовые куски кода, копипастю и все

Просто проекты мелкие, когда станут большими, появятся библиотеки, без них никуда.

Тем более это удобно, если библиотеки имеют законченный вид, значит полностью протестированы и их код не мозолит глаза.

Я потихоньку пилю либы мелкие под разные задачи, в виде отдельных проектов. С лицензией MIT

Раньше был разброд, сейчас все к единому виду стараюсь привести

Ну и по мере накопления знаний/использованию рефакторю

Просто проекты мелкие, когда станут большими, появятся библиотеки, без них никуда.

Ага мелкие....да и не програмист я.......большие проекты не светят

Ага мелкие....да и не програмист я.......большие проекты не светят

Программист не пишет код, он его проектирует ;)

Да вообще, в целом)) мне интересна организация проекта, кто что куда рсспихивает, чтобы потом можно было просто взять и собрать проект. У меня конкретно С++ для эмбеда, использую gcc. Но инструмент особой роли не играет же тут)

гитрепы и сабмодули

Понятно) а то я тут ищу варианты получше, думал, что может уже кто-то за меня изобрел удобный велосипед

Видел на stackoverflow задавали этот вопрос ?

Вот что попалось на скорую руку: http://stackoverflow.com/questions/2360734/whats-a-good-directory-structure-for-larger-c-projects-using-makefile http://stackoverflow.com/questions/13521618/c-project-organisation-with-gtest-cmake-and-doxygen и еще: http://www.cplusplus.com/forum/lounge/90812/ http://hiltmon.com/blog/2013/07/03/a-simple-c-plus-plus-project-structure/

это про проекты вообще, думаю особой разницы эмбед или нет тут нет ?

Походил по ссылкам, в принципе примерно все одинаково ± пару нюансов :) Только я не делю .hpp/.cpp в отдельные папки, так как свой код стараюсь делать header-only, пока это не критично. Просто смотрю на организацию кода в lwip и она мне ну вообще не нравится... Или какую структуру генерит тот же STMCubeMX. Понятно, что я этим проектом и кодом не пользуюсь, но просто если нужно что-то быстро глянуть - глаза кровью обливаются. Я использую такое: Project |-- bin |-- doc |-- tests |-- src |-- lib // third_party по другому, вероятно это лучше будет archive |-- v.0.1.0 ...

Еще можно делать дополнительно resources и tools. Чтобы можно было в любой момент взять папку проекта и из нее получить все необходимое для сборки.

и загнать 500+ мегов в репозиторий?

ггг

оно еще и каждый раз будет качаться в него

Еще можно делать дополнительно resources и tools. Чтобы можно было в любой момент взять папку проекта и из нее получить все необходимое для сборки.

Только если в сорцах, а иначе так не принято.

У меня в репозитории лежат tools и всякий генерированный код. В результате репозиторий весьма немаленький. Но качаются только обновления

оно еще и каждый раз будет качаться в него

В смысле каждый раз? Один раз clone сделал и есть у тебя что нужно.

Только если в сорцах, а иначе так не принято.

Т.е. как минимум ресурсы в src положить? Потому что tools не только для сорцов же

Т.е. как минимум ресурсы в src положить? Потому что tools не только для сорцов же

Я про tools. Ресурсы конечно можно. Просто крупные бинарники, если они не имеют прямого отношения к проекту, не принято хранить в Git. Как бы можно, да, он не глупый и подсчитать хэш от него не убудет, но просто вот. Хотя, опять же, это дело всех и каждого, но я бы таки клал сорцы и написал бы скрипты для их сборки, при необходимости.

В дереве много проектов под разные архитектуры. Есть папка common. В ней по папочкам разложен общий код. Также есть папки для платформ, в них тоже есть общий код и проекты.

Проекты либо на основе эклипса, либо на make. Там там код собирается из разных папок

Так никто левое хранить не будет :)) если скрипт справляется, то будет, конечно же, скрипт, а не бинарь)

В SRC только код относящийся именно к этому проекту. Юниттесты в отдельном проекте для десктопа

В дереве много проектов под разные архитектуры. Есть папка common. В ней по папочкам разложен общий код. Также есть папки для платформ, в них тоже есть общий код и проекты.

А общий код какого плана? Потому что тогда ничего не поломается если апи общего кода меняться не будет

Бинарники приходится хранить т.к. не у всех стоит полный набор инструментов и они не могут собрать инструментарий когда он им нужен. Например, под дождем на поле аэродрома превращенном в гоночный трек

Да, в этом и смысл такой папки. Чтобы можно было в любой момент взять проект и быстро стратануть в работу без длительного поиска нужных вещей.

бесконечный цикл с переполнениями переменных - так и задумано?

лучше спикер цеплять между двумя лапками. так амплитуда на нём удвоится

на одну прямой сигнал, на другую инверсный

Ага и ага

Смотря какой спикер. Те, которые на 3.3В - ну не знаю как они будут жить с 6.6В.

Да и то, смотря как включать

6.6В получить туго

Или я не то понял?

не то

получится при таком подключении вольт столько же, полярность меняется

амплитуда тоже

но тогда код подправить нужно

Ааа, тфу. А я уже думал как и зачем городить минус

но! при таком подключении изменится и частота

и звук будет другим

В дереве много проектов под разные архитектуры. Есть папка common. В ней по папочкам разложен общий код. Также есть папки для платформ, в них тоже есть общий код и проекты.

почему не отдельная репа под каждый проект, а общий код - в отдельной репе, которая подтягивается сабмодулем в проектные?

https://countercomplex.blogspot.fi/2011/10/algorithmic-symphonies-from-one-line-of.html

https://countercomplex.blogspot.fi/2011/10/algorithmic-symphonies-from-one-line-of.html

Спасибо :)

там правда не одна нога, а 8-битные семплы

https://countercomplex.blogspot.fi/2011/10/algorithmic-symphonies-from-one-line-of.html

?

вот еще: https://www.youtube.com/watch?v=tCRPUv8V22o

там правда не одна нога, а 8-битные семплы

Я думаю это не столь важно, главное принцип генерации модулирующей

почему не отдельная репа под каждый проект, а общий код - в отдельной репе, которая подтягивается сабмодулем в проектные?

В гите неудобно подтягивать свежие версии других проектов

должно работать, хоть и не так

в видео котором скинул, на 2:55 ваще шедевр ))

В гите неудобно подтягивать свежие версии других проектов

git submodule update —recursive —remote ? и при этом можно закоммитить утверждение "проект A использует ревизию N либы B" чтоб не удивляться тому что внезапно что-то сломалось из-за изменений в библиотеке, например.

В результатае мы получаем тоже самое, что при использовании одного проекта+геморой по поддержке. В этом плане перфорс куда лучше.

Прикольный аларм )

wtf fast16?

16 бит uint

в зависимости от платформы подставится тот тип, с которм работа будет быстрее всего

не факт, что там будет 16 бит, может быть и 32 бита

И будет работать даже если нет 16-битного типа на платформе

Странно все это

Судя по коду это АВР, на нем 16 не быстро

:)

На последнем видео, мелодии играют порциями

это цикл одного переполнения такого инта

это цикл одного переполнения такого инта

Бляха муха спасибище

Бляха муха спасибище

?

?

За исходники

Иногда надо чето такое

да незачто ))

Только учти что это для 4.8 МГц