AVR Freaks

Even 150uA is not that low for modern LEDs.  I tested some cheap blue LEDs that were plenty bright with just a few tens of uA.

http://nerdralph.blogspot.com/20...

The other reason I like blue LEDs is because they all have a relatively high Vf (~2.6V @ 1mA).  Most of my green LEDs are <2V, though I did get a couple with a different chemistry that are closer to 3V.

Cliff
That last picture looks.like a program I used a long time ago called patcher.

Jim

The funny thing is people have thought that visual programming was the future for a long time. I was using Visual Basic and HP-VEE back in 2001. At the time the VEE visual blocks were shown to a customer that wanted a test setup for validating embedded equipment after the sale. The VEE blocks called programs that ran TCL scripts running in a VM on the test machine.

https://www.keysight.com/en/pd-1476554-pn-W4000D/vee-pro-932

The TCL scripts were what was used for testing during product integration. I am leaving out many ugly details about keeping everything up to date.

Here is one little recent project, an update of the classic Leslie 122/147 amplifier *and* there is an AVR tucked in there 8) It controls bldc motors in order to get rid of the fussy, heavy old induction motors!

Do you have a special tool to "punch" the wires onto those connectors?   I seem to remember fussing with a small screwdriver or similar (or whatever was handy), with mixed results.  

 21 WS2812B LEDs

+ 1 RS-485 transceiver

+ 2 tact switches

+ 1 ATtiny4

-----------------------------------------

= a (mostly) fully functional DMX monitor:

Why?  What can I say?  Some people juggle geese.

I've a hand-built prototype on perfboard with an m328p for proof of concept/code.  Much ugly.

I haven't spun the above PCB yet.  Possibly never will!  The LED layout isn't quite the way I'd like.  I'd prefer to use something like these, if I could get them in singles or as a 3-digit unit... but the website appears to have vanished and the domain is up for grabs.

The fun part was the code.  I crammed quite a bit into 512 bytes of flash.  Assembly language, of course.  Here's an excerpt from the comments:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;                                                                       ;;;;
;;;; Introduction.                                                         ;;;;
;;;;                                                                       ;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;                                                                           ;;
;; This project originated as an exploration of the possibility of           ;;
;; implementing some kind -- any kind -- of DMX512 / DMX512-A (ANSI E1.11)   ;;
;; application on the most resource-constrained member of the AVR family     ;;
;; (the ATtiny4 with 4 I/O pins, 16 8-bit general purpose registers, 32      ;;
;; bytes of SRAM, and 512 bytes of flash), and for not much more of a reason ;;
;; than 'because'.                                                           ;;
;;                                                                           ;;
;; Once it became clear that this was easily possible (say, controlling a    ;;
;; single LED or servo with PWM via DMX at a hard-coded address), it rapidly ;;
;; evolved in an unbounded manner into a software puzzle, attempting to      ;;
;; answer the question:                                                      ;;
;;                                                                           ;;
;;    "How much functionality can be squeezed into 512 bytes of flash?"      ;;
;;                                                                           ;;
;; In fact, it has become more of an exercise in code compression than an    ;;
;; example of good design.  Mating a 33 cent microcontroller with twenty     ;;
;; dollars worth of addressable LEDs is not fiscally sound.  A proper        ;;
;; implementation of this application would choose a micro with the proper   ;;
;; resources for the task:  Enough pins to handle a standard (and much less  ;;
;; expensive) 7-segment LED display matrix, for starters.  One with a UART   ;;
;; would greatly simplify design and coding, and a crystal oscillator or at  ;;
;; least an accurate RC oscillator is a good idea.                           ;;
;;                                                                           ;;
;; The ATtiny104 would be an excellent fit:                                  ;;
;;                                                                           ;;
;;    - 12 GPIO                                                              ;;
;;    - 1KB flash                                                            ;;
;;    - Self-programming flash                                               ;;
;;    - USART module                                                         ;;
;;    - Improved Internal 8MHz RC Oscillator accuracy                        ;;
;;                                                                           ;;
;; With 12 I/O, there would be just enough:                                  ;;
;;                                                                           ;;
;;    - 7 pins for 7-segments                                                ;;
;;    - 3 pins for 3 digits                                                  ;;
;;    - 1 pin for DMX RXD                                                    ;;
;;    - 1 pin for 2 buttons (via ADC resistor network)                       ;;
;;                                                                           ;;
;; Although, this wouldn't permit the use of colour.  A 13th pin would allow ;;
;; the use of the DP to signify 'Address', 'DMX present', etc.  Or 12 pins   ;;
;; could work by blinking the display for 'Address', 'DMX absent', etc.  The ;;
;; extra flash space would make all of this fairly easy.                     ;;
;;                                                                           ;;
;; With the use of Charlieplexing, seven segments could be driven with just  ;;
;; eight I/O, leaving 4 for other purposes.  The DP also could be driven by  ;;
;; using nine I/O, leaving 3 for other purposes.                             ;;
;;                                                                           ;;
;; However, that's not the point of this exercise...                         ;;
;;                                                                           ;;
;; This application implements a simple DMX monitor.  For input, a DMX       ;;
;; universe is connected to DMX_RXD (PB1), and two user buttons are          ;;
;; connected to BUTTON_DN (PB2) and BUTTON_UP (PB3).  Output is via a single ;;
;; pin, LED_DI_BIT (PB0), connected to a string of 21 WS2812B compatible     ;;
;; addressable LEDS, arranged in three seven-segment digits.                 ;;
;;                                                                           ;;
;; DMX is an asynchronous serial protocol, and requires a fairly accurate    ;;
;; system clock for reliable comms.  The ATtiny4 lacks this, having only an  ;;
;; internal RC oscillator, but one which can be user-calibrated.  The app    ;;
;; auto-calibrates against the DMX frame itself, relying on known timing     ;;
;; characteristics.  Calibration is performed on power-up, and repeatedly as ;;
;; serial framing errors and other signal anomalies are detected, as well as ;;
;; any time the display times out after user input.  In this way the user    ;;
;; can force a calibration simply by pressing a button.                      ;;
;;                                                                           ;;
;; The display can show the:                                                 ;;
;;    - selected DMX address in decimal 001 to 512                           ;;
;;    - contents of selected address as:                                     ;;
;;        - the PWM intensity of all 21 segments (white)                     ;;
;;        - a bar graph (using segments)                                     ;;
;;        - a percentage %00 to %99 and %FL                                  ;;
;;        - a decimal value 0 to 255                                         ;;
;;        - a hexadecimal value h00 to hFF                                   ;;
;;    - most recent non-zero alternate start code in hexadecimal n01 to nFF  ;;
;;    - DMX frame rate (FPS) in hexadecimal as 'r00' to 'r7F'                ;;
;;    - current OSCCAL in hexadecimal as 'o00' to 'oFF'                      ;;
;;                                                                           ;;
;; If no alternate start code has been seen since power-up, 'n00' is shown.  ;;
;;                                                                           ;;
;; Each time an alternate start code is received, the display is blinked by  ;;
;; altering its intensity until the next display update, as an indication.   ;;
;; This occurs even if the new alternate start code is the same as the       ;;
;; previous one.  This blinking occurs in every display mode except PWM.     ;;
;;                                                                           ;;
;; The frame rate is only 7-bit, so maximum measurable frame rate is 127     ;;
;; FPS.  Frame rates greater than that will be displayed modulo 128.  The    ;;
;; measurement will be disturbed by button presses, absent DMX, and periodic ;;
;; calibration.  This mode was added to round out a list of 8 data display   ;;
;; modes.  It may one day be replaced with a more useful mode, as might the  ;;
;; display of the current OSCCAL.                                            ;;
;;                                                                           ;;
;; The colour of the display changes as well:                                ;;
;;    - BLUE:   Selected address                                             ;;
;;    - RED:    Contents/data while DMX not present                          ;;
;;    - GREEN:  Contents/data while DMX present                              ;;
;;    - WHITE:  Contents as PWM intensity                                    ;;
;;                                                                           ;;
;; The default state is to show data (contents, start code, OSCCAL, or frame ;;
;; rate).  The address itself can be shown by pressing either button.  The   ;;
;; address will remain visible for about 2 seconds, then the display will    ;;
;; revert to showing data.                                                   ;;
;;                                                                           ;;
;; Changing the selected address can be done by pressing either the 'UP'     ;;
;; or 'DOWN' buttons while the address is already displayed.  That is, the   ;;
;; first press shows the current address, and subsequent presses (before the ;;
;; display reverts to showing data) will change the address.  Changes are    ;;
;; immediate.  The selected address wraps from 512 to 001, and vice versa.   ;;
;;                                                                           ;;
;; Pressing and holding a button will keep the address on the display,       ;;
;; but it does not result in fast-changing the address as experience with    ;;
;; similar devices might make you expect.  That would take too much flash!   ;;
;; Without fast-changing, going from address 001 to address 257 would take   ;;
;; an uncomfortable number of button presses.  As a compromise, the 'DOWN'   ;;
;; button lowers the address by 10, while the UP' button raises it by 1.  In ;;
;; this way, no address is more than about 50 button presses away from any   ;;
;; other address.  Both step sizes are configurable in the .h.               ;;
;;                                                                           ;;
;; The data displayed can be changed by pressing both buttons at the same    ;;
;; time.  The display will cycle through 8 modes: the five different         ;;
;; contents formats, alternate start code, frame rate, and OSCCAL value.     ;;
;;                                                                           ;;
;; Since the ATtiny4 lacks EEPROM or self-programming, the app cannot save   ;;
;; the selected format or the selected address anywhere.  As such, the       ;;
;; selected address will reset to 001 (or whatever has been configured in    ;;
;; the project's .h file), and the selected format will reset to contents as ;;
;; a PWM intensity, whenever the device is power-cycled.  This allows the    ;;
;; default behaviour to be that of a normal lighting fixture, hard-coded to  ;;
;; a specific address.                                                       ;;
;;                                                                           ;;
;; The register used to store the computed frame rate is initialised, but    ;;
;; the register used to accumulate the packet count which leads to it isn't, ;;
;; so FPS will display a meaningless value for the first 4 or so seconds     ;;
;; after DMX is present.  Frame rate computations do not include frames with ;;
;; alternate start codes, only frames with a null start code.                ;;
;;                                                                           ;;
;; Alternate start codes include 0xCC used by RDM (ANSI E1.20), an emerging  ;;
;; protocol which lies atop and co-exists with DMX.  This application        ;;
;; ignores RDM traffic and all other traffic with alternate start codes, but ;;
;; is otherwise compatible with it.                                          ;;
;;                                                                           ;;
;; As alluded to earlier, the ATtiny4 lacks a hardware UART.  As such, the   ;;
;; async receive code is 'bit-banged', as is the DMX start-of-frame break    ;;
;; detection code.                                                           ;;
;;                                                                           ;;
;; It may be interesting to note that this little DMX512 application uses    ;;
;; 15 of the 16 general purpose registers, and a maximum 8 of the 32 bytes   ;;
;; of SRAM for return addresses of rcall instructions and interrupts.  No    ;;
;; other SRAM is used.  The ATtiny4 lacks GPIORn registers, so a handful of  ;;
;; single-bit flags are implemented by exploiting otherwise unused bits in   ;;
;; low special function registers.  However, every single poetic one of the  ;;
;; 512 bytes of flash is spoken for.  Sixteen bytes are used for a lookup    ;;
;; table, with the remaining 248 words used for instructions.                ;;
;;                                                                           ;;
;; Surely any sane reader has already asked the question:  "Why?!"           ;;
;;                                                                           ;;
;; What can I say?  Some people juggle geese.                                ;;
;;                                                                           ;;
;; Previous versions of this code padded unused flash with the more-or-less  ;;
;; pointless string "DMX512-A", or some variation thereupon.  The current    ;;
;; version uses every byte of flash for the application.                     ;;
;;                                                                           ;;
;; This string was included purely for the warm fuzzy feeling of unity it    ;;
;; created in the author, knowing that a DMX512 / DMX512-A compatible        ;;
;; application completely fills the 512 bytes of flash available.  That,     ;;
;; and he couldn't fathom what else to do with the remaining space, having   ;;
;; shaved away as many instructions as possible, and crammed in as much      ;;
;; functionality as he could think of.  At the time.                         ;;
;;                                                                           ;;
;; Previous versions also included a brief all-segments display test with    ;;
;; dimming on power-up, but the current operational feature set consumes     ;;
;; 100% of available flash.                                                  ;;
;;                                                                           ;;
;; As noted in the introduction of those earlier versions, 'That may one day ;;
;; change':                                                                  ;;
;;                                                                           ;;
;;     "An artist never finishes a work, he merely abandons it".             ;;
;;         - Aaron Copland                                                   ;;
;;                                                                           ;;
;; One more note on the, at first glance, excessive documentation:           ;;
;;                                                                           ;;
;;     "If the code isn't important enough to document,                      ;;
;;      throw it away right now." - Phil Koopman                             ;;
;;                                                                           ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Cool!

There's 16b floating point; likewise for fixed-point.

P.S.

Buck instead of boost :

What are the AVR28DA128 AVR32DA128 AVR48DA128 AVR64DA128 ?? | Page 5 | AVR Freaks

e2 PowerEdgeTM Economic Energy using Low VCEsat BJT’s (ON Semiconductor)

[page 7]

Pass Element in Buck / Boost converter

[hysteretic instead of PWM]

Fixed-Point Support - avr-gcc - GCC Wiki

Geek Like Me, Too: Fixed Point Math with AVR-GCC

I'll start by making simple feedback (P, I or PI) so simpler code

You likely barely need even that, depending on the speed of needed response (input & output).   Will you have large input or transients that need responded to?  Try setting the  OCR to some value (0-255 if 8 bit PWM, etc)---you will get some very steady voltage.  Try another OCR value & you will see another steady voltage.  Now you have 256 different voltages to select from.   If the load is not too demanding, the voltage will remain steady, even if the load changes.  Unlike an analog circuit, you only have 256 possible selections anyhow,  so a high accuracy computation really does little statically.  If Vout seems to be sagging, merely increase it one click or two. A small deadband is helpful to remove chatter, dur eto one setting being slightly too high and the next being slightly too low.  You can dither between 2 selections to create maybe another bit or two of resolution, of needed. How accurate of a Vout do you need? Usually within +/-5%, so it is very easy to maintain.