На кроме того, что на Шоттки будет падение, которое будет снижать время работы от батареек, дак еще Шотткой отключить прибор нельзя. Ключ не только мультиплексирует питание (именно поэтому он ключ, а не диод), но и отключает прибор :)
если честно, то это статья про создание себе проблем и их героического решения. В цепь батарейного питания ставится диод Шоттки, а т. к. напряжение автономного источника ниже, чем напряжение на USB, то ничего отключать не надо.
Я бы поставил всего 1 микросхему и не стал городить кучу дискретных элементов. О преимуществах такого решения даже писать нечего, т. к. перечислять долго.
Ключ не будет закрываться, а устройство не будет отключаться. Ключ не только как переключатель батарейка-USB, но и включает/отключает устройство — посмотри на схему i3.
Судя по вот этому, будет но не большой. Рынок скорее гиковский.
Заметь, что сейчас народ даже обычными часами перестал пользоваться (если пользуются, то крутыми, статусными). Зачем, если есть мобильник, который можно вытащить из кармана и посмотреть время? Если часы использовать в качестве пульсометра (коих куча уже), батарейку нужно будет заряжать каждый день — тоже не очень. Велосипедист и мотоциклист тоже не в восторге будут отвлекаться от дороги. Существующие голосовые подсказки навигаторов намного удобнее.
А вот идея с чернилами — здравая. Мобильник с eink-экраном наверняка нашел бы поклонников. Бeда в том, что fps маловато.
Еще есть вариант — наручный компьютер, как в fallout. Фактически просто мобильник, который цепляется к запястью.
UPD: Гы, не я первый придумал цеплять телефон к запястью:
Если честно, то Браун мне совсем не понравился. Подход какой-то «от балды». Практические рекомендации есть, но почему та или иная рекомендация работает — никак не объяснено. В итоге, шаг влево/вправо от примеров и не знаешь, что делать.
Детально разобраться можно, почитав учебник по ТФКП. Учебников в сети куча, но, боюсь, совсем с нуля его не осилить.
Кроме учебников, на ютубе есть довольно хорошие видушники. К примеру, вот про преобразование Лапласа, а вот про полюса и нули: часть 1, часть 2. Кстати, советую посмотреть остальные видео этого автора — очень много полезной математики.
Раз уж начал букмарки делать, вот еще куча хороших видушников по теме (наверное, для начинающих эти даже лучше остальных). Эти видео сосредоточены именно теории управления, но полюса и нули применяются не только там.
Дак образцы именно для коммерческого применения и нужны, наверное, вы что-то не так поняли. Кстати, TI нынче не шлет в Украину вообще ничего, даже если заплатить. Объясняют это тем, что слишком много посылок не доходит до адресата.
На сайте попробовал заказать микросхему безcплатно (sample), заказ отменили, потому что мой проект им смахивает на комерчиский. А я просто написал что микросхема нужна для «Robot car model»
Вот оно как. А я всё думал, с чем связано требование на минимальный ESR у TPS7333. Они даже советуют ставить 1R резистор, последовательно с конденсатором.
Никто не мешает создавать объекты с виртуальными функциями статически.
Если выбор стоит только между стеком и кучей (static-only классы, кстати нельзя создать на стеке или в куче — вот и потеря гибкости), то стек не порвет — просто стек нужно больше сделать и все. По использованию памяти будет — абсолютно тоже самое, что и выделить память для статического объекта. Кроме того, стек можно еще и в других местах использовать.
Лично я объекты создаю только статически. Иногда использую allocate-only кучу.
Если объект не имеет статичных полей, чтобы поюзать его, его нужно создать:) а создать как? на стеке или в куче? а если в объекте массив байт на 1000[]? Порвет стек?
Имеет смысл использовать статичный класс, чтобы юзать модификаторы доступа к полям и методам. А как Вы создаете объекты в микроконтроллерных приложениях, статически или динамически? (имеется в виду в более серьезных uc, типо ARM).
Дак, если в классе только статичные методы, то в нем (классе) смысла нет. Тогда уж лучше не классы а namespace использовать. А виртуальность и куча — совершенно разные понятия. Вот более микроконтроллерный пример:
class ComPortChannel : public ICommunicationChannel;
class UsbChannel : public ICommunicationChannel;
ComPortChannel com_port;
UsbPort usb_port;
...
data.send_via(&com_port);
data.send_via(&usb_port);
Виртуальный метод не может быть статичным.
На микроконтроллере создание объекта (если еще тем более в куче) может ухудшить скорость работы кода.
Как правильно, если использую C++ на мк, стараюсь обходится static-only классами.
А какую микросхему бы ты поставил?
Я бы поставил всего 1 микросхему и не стал городить кучу дискретных элементов. О преимуществах такого решения даже писать нечего, т. к. перечислять долго.
Заметь, что сейчас народ даже обычными часами перестал пользоваться (если пользуются, то крутыми, статусными). Зачем, если есть мобильник, который можно вытащить из кармана и посмотреть время? Если часы использовать в качестве пульсометра (коих куча уже), батарейку нужно будет заряжать каждый день — тоже не очень. Велосипедист и мотоциклист тоже не в восторге будут отвлекаться от дороги. Существующие голосовые подсказки навигаторов намного удобнее.
А вот идея с чернилами — здравая. Мобильник с eink-экраном наверняка нашел бы поклонников. Бeда в том, что fps маловато.
Еще есть вариант — наручный компьютер, как в fallout. Фактически просто мобильник, который цепляется к запястью.
UPD: Гы, не я первый придумал цеплять телефон к запястью:
Про компенсацию есть более-менее доступно в книге Брауна Источники питания. Расчет и конструирование
Кроме учебников, на ютубе есть довольно хорошие видушники. К примеру, вот про преобразование Лапласа, а вот про полюса и нули: часть 1, часть 2. Кстати, советую посмотреть остальные видео этого автора — очень много полезной математики.
Раз уж начал букмарки делать, вот еще куча хороших видушников по теме (наверное, для начинающих эти даже лучше остальных). Эти видео сосредоточены именно теории управления, но полюса и нули применяются не только там.
Желательно так, что бы почти с нуля можно было разобраться.
Я еще как прочитал статью об обратной связи спросить хотел…
Если выбор стоит только между стеком и кучей (static-only классы, кстати нельзя создать на стеке или в куче — вот и потеря гибкости), то стек не порвет — просто стек нужно больше сделать и все. По использованию памяти будет — абсолютно тоже самое, что и выделить память для статического объекта. Кроме того, стек можно еще и в других местах использовать.
Лично я объекты создаю только статически. Иногда использую allocate-only кучу.
Имеет смысл использовать статичный класс, чтобы юзать модификаторы доступа к полям и методам. А как Вы создаете объекты в микроконтроллерных приложениях, статически или динамически? (имеется в виду в более серьезных uc, типо ARM).
На микроконтроллере создание объекта (если еще тем более в куче) может ухудшить скорость работы кода.
Как правильно, если использую C++ на мк, стараюсь обходится static-only классами.