Не менее интересны как раз схемотехнические моменты ,обратная ЭДС, , насыщение и тд с участками схем. В тексте конечно есть понятные отсылки, но увидеть быстрее и надёжнее. И спасибо вам и kuza2000 за комменты по теме.
Когда-то зимой в горах (конец ноября, Кавказ) ночью палатку капитально засыпало снегом.
Стоял как то на 3000м в сильный снегопад, палатка с пологом, но не помню точно какая тогда была - с ушками для вентиляции или нет. Просыпался часто и откапывался. Снег мокрый и тяжёлый. В очередной раз проснулся от того что придавило - палатка легла сверху. Но спать очень хотелось:)
А ещё прикол...
Несколько раз тогда проснулся - отчётливо звали по имени:) (ближайшая деревня в неск км.через реку) А на утро было прекрасно - всё было белое, идти никуда было невозможно пока не замотал глаза тряпками. ЛЭП была порвана во многих местах, со склоном с шумом тут и там съезжали небольшие лавины:) А потом всё поплыло..)
После написания основной части планируемой логики работы ПЛИС, оказалось что объем использованных логических ячеек ненамного превысил только половину от имеющихся
Следующим логическим шагом, встроить туда какой нибудь @VT100 или кто там следующий цветной. Вот от такого с UART я бы наверное не отказался. ps у самого многолетний, вялотекущий проект превращение плазмы MC6205 в терминал, уже сбился какая итерация:)
вот так всегда... когда интересно и вроде даже начинает казаться понятным до момента пока не придёт @Tyusha и не скажет, что это дичь не совсем верно :)
Да что то я подзабыл, т.к. изначально всё равно там 9600 планировалось, но где то в районе 57 кажется тоже не особо работало. И наблюдал на осцилле, там завалы видны, но на практике может быть и работало бы. В даташите пишут 4-18 us rise/fall, вот у меня скорее всё виделось по максимально медленной границе.
У меня был Спектрум с дисководом и программатором. В качестве dev board - плата АОН на том же самом Z80. Программа переносилась с программатора на SRAM (РУ10) с кондёрчиком. Писалось тогда конечно же на asm. А на сам спектрум по мелочи вполне себе на basic. О PC понятия не имел тогда вообще, хотя слышал мечтательные вздохи коллег.
Не очень в этом разбираюсь, но для себя отметил как то читая по теме у буддистов. В одной из (4?) основных школ есть "квантование", но в окончательной версии воззрения наитончайшее сознание(это не привычное нам сознание если что) не квантуется и процесс восприятия происходит неразрывно. Это наверное похоже на то что код одновременно данные и наоборот.
Как то очень удивился когда UART развязывал через PC817 и оно начало при повышении скорости очень быстро деградировать. Пришлось подбирать режимы по постоянному току что бы хотя бы убрать насыщение, как-то не осознавал даже глядя в даташит на сколько они медленные.
After switching to C code from assembly language for firmware development, it’s hard to go back. You still have to know the target processor’s machine code to be an effective firmware developer for resource-limited microcontrollers like the ATtiny15L, but I find that being able to program in C makes me more productive and results in a much more maintainable product. Plus, with careful work and planning, there’s no net loss of efficiency with respect to how much functionality you can stuff into the target microcontroller.
My C compiler of choice has always been GNU’s open-source GCC compiler, which is supported in some form on almost every operating system. It targets virtually every instruction set in the universe, and it has generated good machine code every time I’ve used it. There is an AVR version of GCC with a full complement of support tools, including an assembler and a linker. For years, I’ve used AVRGCC to develop firmware for Atmel AVR chips, using both Windows and Linux. The machine code it has generated has been especially good. However, when it was time to start working with the ATtiny15L, I was disappointed to discover that AVR-GCC didn’t support the low-end Atmel microcontrollers like the ATtiny15L that have no RAM. What was I to do?
I have years of experience with the AT90S8515 microcontroller, which has only 512 bytes of RAM, so I knew I could write C code for the chip, which uses almost no RAM. In fact, the hard part about using AVR-GCC for AVR microcontrollers like the AT90S18515 is writing C code in a way that conserves the precious small amount of RAM.
The AVR-GCC generates AVR code that uses the 32 8-bit hardware registers for local variables. It passes parameters to and from subroutines and functions using the same registers. Therefore, it’s reasonably easy to write complex C programs that use little or no RAM. The reward for doing this well is tightly coded machine code that tends to run fast. Like many firmware developers, I always generate a mixed listing from the compiler that shows the compiler’s machine code interspersed with my C source code lines. This way I know exactly what the compiler is doing. By reviewing this output on a regular basis, I can learn what the compiler does well and what it has problems with.
My experiences with the code generator from the AVR-GCC taught me that, in fact, the compiler should work with a microcontroller without RAM. The key is making sure that AVR instructions that reference RAM never make it into the target microcontroller’s executable image. I solved this problem by putting together a simple Perl script that post-processes the C compiler’s output and checks for illegal instructions.
I use the GNU make program (supplied with the AVR-GCC) to cause the assembler to automatically generate a mixed listing and then check it for bad instructions using the Perl script. If problems are detected, the Perl script outputs an error message, which includes the C source line that generated the problem instruction along with the bad assembly language instructions. The make file logic then deletes the resultant object file and aborts the entire process.
Therefore, bad code never makes it to the linker.
With these checks in place, it’s now a simple matter of coding in such a way as to completely avoid any use of RAM. Also, remember that the ATtiny15L has only a three-deep call-return stack. Let’s consider some tricks for programming AVRs without RAM. These tricks tend to yield fast and efficient machine code, no matter which AVR processor your C program targets. Constant data that would otherwise need to be placed in RAM is stored in program memory using some special compiler attributes. It’s then retrieved with the load program memory (LPM) instruction when needed.
The main program is declared naked to inhibit the generation of subroutine entry/exit code. The project is structured to include no more than two (or three) levels of subroutine calls (depending on whether or not interrupts are enabled). Without this declaration, registers used for local variables would be pushed and popped from the (nonexistent) stack. Any storage needed in the interrupt handler is globally declared both in the interrupt handler and in the main program and subroutines:
register unsigned char foo asm("r2");
Note that r2 specifies one of the AVR hardware registers. In this case, the register selected in this way must not be one of the registers reserved by the AVR-GCC for special uses, such as parameter passing or temporary storage. Use a special in-line assembly macro in situations where the AVRGCC uses a RAM location and an lds instruction to load constant data into one of the AVR lower registers (r0–r15). For example:
foo = 1; // May generate a "lds" foo = BYTE(1); // Uses "ldi/mov"
The in-line assembly macro BYTE() causes the compiler to first load the constant into one of the high registers (r16–r31) using an ldi instruction. It then moves the data into the variable’s assigned low register. Keep all subroutines and functions simple enough so that they don’t require any local variable storage other than those registers reserved by the AVRGCC for parameter passing and temporary storage. Basically, this includes 12 of the 16 upper 8-bit AVR registers (r18–r27 and r30–r31). Plus, avoid nonleaf C subroutines and functions that include any state. A routine with no local storage meets this requirement, which is needed to avoid push and pop instructions needed to save and restore this state before and after calling another routine. Use static in-line routines and in-line assembly macros liberally. Such code is expanded in-line by the compiler. It completely eliminates subroutine calls, which serves to avoid some of the aforementioned restrictions. In fact, it’s more efficient for routines that are called from only one place.
Of course, your other option is to use an ATtiny device that has RAM. That would be way too easy for me! Besides, not having RAM tends to make the microcontroller cheaper, and in the embedded world, cheaper is always better.
кратко: Правила написания кода, макросы и perl скрипт постпроцессинга asm кода
Спасибо за статью, у меня вроде как подошёл момент когда надо об этом озаботиться в коде и были разные мысли по этому поводу, некие казались абсурдными. Но теперь почти уверен, что к моему контроллеру (в единственном экземпляре) на stm32 с 32к проще поставить рядом малинку для прошивки :)
Магнитные усилители массово применялись в ЖКХ в районных теплопунктах для усиления сигнала с термопар.
Не менее интересны как раз схемотехнические моменты ,обратная ЭДС, , насыщение и тд с участками схем. В тексте конечно есть понятные отсылки, но увидеть быстрее и надёжнее.
И спасибо вам и kuza2000 за комменты по теме.
наверное имелось в виду VL53L0X, тут по нему много было
Стоял как то на 3000м в сильный снегопад, палатка с пологом, но не помню точно какая тогда была - с ушками для вентиляции или нет. Просыпался часто и откапывался. Снег мокрый и тяжёлый. В очередной раз проснулся от того что придавило - палатка легла сверху. Но спать очень хотелось:)
А ещё прикол...
Несколько раз тогда проснулся - отчётливо звали по имени:)
(ближайшая деревня в неск км.через реку)
А на утро было прекрасно - всё было белое, идти никуда было невозможно пока не замотал глаза тряпками. ЛЭП была порвана во многих местах, со склоном с шумом тут и там съезжали небольшие лавины:) А потом всё поплыло..)
напомнило - анализ звуков подводной лодки в доке, там чуть ли не десятки тысяч кэйсов можно было диагностировать (по старым данным от "у них")
... и не признал сразу без фирменной
картинки
Следующим логическим шагом, встроить туда какой нибудь @VT100 или кто там следующий цветной. Вот от такого с UART я бы наверное не отказался.
ps у самого многолетний, вялотекущий проект превращение плазмы MC6205 в терминал, уже сбился какая итерация:)
вот так всегда... когда интересно и вроде даже начинает казаться понятным до момента пока не придёт @Tyusha и не скажет, что это
дичьне совсем верно :)Да что то я подзабыл, т.к. изначально всё равно там 9600 планировалось, но где то в районе 57 кажется тоже не особо работало. И наблюдал на осцилле, там завалы видны, но на практике может быть и работало бы. В даташите пишут 4-18 us rise/fall, вот у меня скорее всё виделось по максимально медленной границе.
У меня был Спектрум с дисководом и программатором. В качестве dev board - плата АОН на том же самом Z80. Программа переносилась с программатора на SRAM (РУ10) с кондёрчиком. Писалось тогда конечно же на asm. А на сам спектрум по мелочи вполне себе на basic. О PC понятия не имел тогда вообще, хотя слышал мечтательные вздохи коллег.
Очень круто!
ps проситься запилить в место FLASH -> SRAM, а может и DRAM, загрузчик получается сложнее всей этой штуки
Не очень в этом разбираюсь, но для себя отметил как то читая по теме у буддистов. В одной из (4?) основных школ есть "квантование", но в окончательной версии воззрения наитончайшее сознание(это не привычное нам сознание если что) не квантуется и процесс восприятия происходит неразрывно. Это наверное похоже на то что код одновременно данные и наоборот.
Как то очень удивился когда UART развязывал через PC817 и оно начало при повышении скорости очень быстро деградировать. Пришлось подбирать режимы по постоянному току что бы хотя бы убрать насыщение, как-то не осознавал даже глядя в даташит на сколько они медленные.
полез сначала в журнал, а потом увидел, что там http://lightner.net/avr/ATtiny/projects/README.txt
Cпасибо!, - мощная статья по ссылке из Circuit Cellar Magazine (#192, p. 20, July 2006)
оставлю часть про Си тут
After switching to C code from assembly language for firmware development, it’s hard to go back. You still have to know the target processor’s machine code to be an effective firmware developer for resource-limited microcontrollers like the ATtiny15L, but I find that being able to program in C makes me more productive and results in a much more maintainable product.
Plus, with careful work and planning, there’s no net loss of efficiency with respect to how much functionality you can stuff into the target microcontroller.
My C compiler of choice has always been GNU’s open-source GCC compiler, which is supported in some form on almost every operating system. It targets virtually every instruction set in the universe, and it has generated good machine code every time I’ve used it. There is an AVR version of GCC with a full complement of support tools, including an assembler and a linker. For years, I’ve used AVRGCC to develop firmware for Atmel AVR chips, using both Windows and Linux.
The machine code it has generated has been especially good. However, when it was time to start working with the ATtiny15L, I was disappointed to discover that AVR-GCC didn’t support the low-end Atmel microcontrollers like the ATtiny15L that have no RAM. What was I to do?
I have years of experience with the AT90S8515 microcontroller, which has only 512 bytes of RAM, so I knew I could write C code for the chip, which uses almost no RAM. In fact, the hard part about using AVR-GCC for AVR microcontrollers like the AT90S18515 is writing C code in a way that conserves the precious small amount of RAM.
The AVR-GCC generates AVR code that uses the 32 8-bit hardware registers for local variables. It passes parameters to and from subroutines and functions using the same registers. Therefore, it’s reasonably easy to write complex C programs that use little or no RAM. The reward for doing this well is tightly coded machine code that tends to run fast. Like many firmware developers, I always generate a mixed listing from the compiler that shows the compiler’s machine code interspersed with my C source code lines.
This way I know exactly what the compiler is doing. By reviewing this output on a regular basis, I can learn what the compiler does well and what it has problems with.
My experiences with the code generator from the AVR-GCC taught me that, in fact, the compiler should work with a microcontroller without RAM. The key is making sure that AVR instructions that reference RAM never make it into the target microcontroller’s executable image. I solved this problem by putting together a simple Perl script that post-processes the C compiler’s output and checks for illegal instructions.
I use the GNU make program (supplied with the AVR-GCC) to cause the assembler to automatically generate a mixed listing and then check it for bad instructions using the Perl script. If problems are detected, the Perl script outputs an error message, which includes the C source line that generated the problem instruction along with the bad assembly language instructions. The make file logic then deletes the resultant object file and aborts the entire process.
Therefore, bad code never makes it to the linker.
With these checks in place, it’s now a simple matter of coding in such a way as to completely avoid any use of RAM. Also, remember that the ATtiny15L has only a three-deep call-return stack. Let’s consider some tricks for programming AVRs without RAM. These tricks tend to yield fast and efficient machine code, no matter which AVR processor your C program targets.
Constant data that would otherwise need to be placed in RAM is stored in program memory using some special compiler attributes. It’s then retrieved with the load program memory (LPM) instruction when needed.
The main program is declared naked to inhibit the generation of subroutine entry/exit code. The project is structured to include no more than two (or three) levels of subroutine calls (depending on whether or not interrupts are enabled). Without this declaration, registers used for local variables would be pushed and popped from the (nonexistent) stack.
Any storage needed in the interrupt handler is globally declared both in the interrupt handler and in the main program and subroutines:
register unsigned char foo asm("r2");Note that r2 specifies one of the AVR hardware registers. In this case, the register selected in this way must not be one of the registers reserved by the AVR-GCC for special uses, such as parameter passing or temporary storage.
Use a special in-line assembly macro in situations where the AVRGCC uses a RAM location and an lds instruction to load constant data into one of the AVR lower registers
(r0–r15). For example:
foo = 1; // May generate a "lds"foo = BYTE(1); // Uses "ldi/mov"
The in-line assembly macro BYTE() causes the compiler to first load the constant into one of the high registers (r16–r31) using an ldi instruction. It then moves the data into the variable’s assigned low register.
Keep all subroutines and functions simple enough so that they don’t require any local variable storage other than those registers reserved by the AVRGCC for parameter passing and temporary storage. Basically, this includes 12 of the 16 upper 8-bit AVR registers (r18–r27 and r30–r31). Plus, avoid nonleaf C subroutines and functions that include any state. A routine with no local storage meets this requirement, which is needed to avoid push and pop instructions needed to save and restore this state before and after calling another routine.
Use static in-line routines and in-line assembly macros liberally. Such code is expanded in-line by the compiler. It completely eliminates subroutine calls, which
serves to avoid some of the aforementioned restrictions.
In fact, it’s more efficient for routines that are called from only one place.
Of course, your other option is to use an ATtiny device that has RAM. That would be way too easy for me!
Besides, not having RAM tends to make the microcontroller cheaper, and in the embedded world, cheaper is always better.
кратко: Правила написания кода, макросы и perl скрипт постпроцессинга asm кода
80 битный ЛУТ
64 битный от плазмы (аж 80 мощных Вольт) и пара 595
нашёлся повод вставить свою картинку :)
Подписался:)
ps одинокий частотник на фото вижу, а что за интересные однотипные блоки У234 в стойке, с ходу найти не удалось.
этой картинки не хватает в статье
Разбирал аккуратно, но всё равно где-то задел жижу, пришлось всё стирать, т.к. локализовать
воньзапах не удалось.Спасибо за статью, у меня вроде как подошёл момент когда надо об этом озаботиться в коде и были разные мысли по этому поводу, некие казались абсурдными. Но теперь почти уверен, что к моему контроллеру (в единственном экземпляре) на stm32 с 32к проще поставить рядом малинку для прошивки :)