AVR Freaks

>> I am looking for how to find people interested to get them reviewed, critiqued, and vetted if reviewers agree they're among the better alternatives, and finally promoted so the community can find and use them, and hopefully contribute to them too.

Does this really happen ? Call me cynical but 90% of Arduino users just want stuff that works. Very few are qualified to sort the wheat from the chaff.

There are a few well-known YouTubers with substantial followings, but I don't how you get to them. And then your code has to be 'interesting' and be whatever the flavour-of-the-month tech is.

I think you have to self-promote. Blog about it, post on the usual forums, create YouTube videos and tutorials, be searchable. People will eventually find out about you; some may even collaborate. Then be visible and supportive of people using your code. It takes time. There's a lot of noise out there.

how to promote...

partner with a hardware vendor other than Arduino, who is trying to push the envelope.  Find someone doing Xmega or AVR-DA or something that doesn't have "legacy support issues."  Maybe Spence Konde's tiny mega core (for tiny0/tiny1)

I also performance oriented. Since I care a lot about minimal memory footprint for my projects, I code those libraries with compiler constant folding in mind to minimize program and RAM space usage. For example the library has an AVR mode that accesses ports directly instead of arduino pin numbers going through PROGMEM tables that don't optimize away causing code bloat and slower performance. 

Oh.  Well, no one seems to care much about performance and memory, and the hardware vendors that I mentioned solve the problem by designing faster hardware.  Adafruit, who I'd put pretty close to the top of the list of vendors "trying to push the envelope" is pushing Python interpreters :-(  Even the chip vendor libraries are infamous for their bloat and inefficiency :-(

digitalIo<13, LOW> led;

digitalIoAvr<B,5, LOW> led; /* Pin 13 is AVR port B5 */

Somewhat cynically:

1. I cringe at the idea of explaining template instantiations (is that the right term) to the Arduino target audience.
2. The abstraction of ports and bits of io ports to board "pin numbers" is probably the single most important thing that the Arduino framework as done.  Please don't undo it, especially in a way that is CPU specific.
3. Similarly, you probably shouldn't bother unless you're willing to do AVR, SAMD, and ESP implementations all at the same time.  One of the best current aspects of the Arduino environment is its portability between architectures whose vendors probably couldn't come close to agreeing to library APIs.
4. Oh swell, another implementation of fast digital write.  This one looks a lot like the one Bill Greiman did back in 2013 ( https://github.com/greiman/Digit... )  None of the faster digitalWrite()s have really caught on much (possible exception is PJRC's version in the "teensy" core.)

Still cynically, and in keeping with the "partner with HW vendors", you might be better off implementing more explicitly named after peripherals.  For example, instead of a "digitalSonar" class, have an "HCSR04" class (that's a sparkfun ultrasonic module part number, originally, I think.)  You can have a more abstracted class underneath, and go ahead and be promiscuous with vendor part numbers as well.  "I just want to read how far away things are; I don't want to know which chip my XYZR04 module uses!"

The repository you found is the the "tinycore."  MegaTinyCore ( https://github.com/SpenceKonde/m... )is more fertile ground (IMO) because:

1. new chip family with less legacy.
2. despite that, the current Arduino code is SLOWER than the normal ATmega core. :-(
3. PROGMEM isn't needed.

I managed to get my digitalWriteFast() into MegaCoreX quoting similar logic:  https://github.com/MCUdude/MegaC...
https://github.com/WestfW/Duino-...

You might want to look into things like "__attribute__ (( error("") ))" and "#pragma gcc poison" as alternatives to "using a non-existent port writes to PORTB."

If your software is easy to use, works well and is filling a niche where little or no worthy competition exists, it will promote itself to Arduino in time.

IDK if westfw had to promote optiboot for it to become used in Arduino.

I didn't really promote jtag2updi yet it ended up in Arduino in a modified form.

Wiring (the origin of Arduino) had fast digitalWrite for compile-time constants ~10 years ago.

https://github.com/WiringProject...

 The first mentions I can find of using __builtin_constant_p() to implement a faster digital write were back in 2007, and they reference "earlier messages" which I can't find. 

AFAICT Wiring incorporated some of Paul Stoffregen's code via Michael Margolis.  If you look at the older versions of Wiring you'll find:

/*
 * Michael Margolis
 * this version is based on Paul Stoffregen's Nov13 2009 submission to the
 * Arduino developers list
 */
//inline void digitalWrite(uint8_t, uint8_t) __attribute__((always_inline, unused));
/*inline void digitalWrite(uint8_t P, uint8_t V)
{
       (__builtin_constant_p(P) && __builtin_constant_p(V))
       
       :

But strangely for someone who is so bent out-of-shape about not getting proper attribution, there's no such credit in the Wiring 1.0 code.  While PJRC continued onward with highly optimized digital IO code (which I'm glad I don't have to maintain!), Arduino apparently decided they weren't interested.

(also, based on file/directory layout, it looks a lot like Wiring 1.0 started as a fork of Arduino rather than an expansion of the earlier Wiring code, even if Arduino started with the Wiring Code at its beginning.)

Remember that Arduino displaced things like the Basic Stamp and BASIC51 boards that were incredibly slow compared even with the Arduino digitalWrite()  (and yet still considered very useful.)

>You'll have to ask curtvm, he wrote it

> Big problem, arduino stretches from AVR,ARM and ESP, so how do you create highly portable libraries between micros? Now you understand why this stuff ain't easy... My answer is to create more modular libraries and drivers, adopt a layered approach which is hard to implement because there are thousands of MCUs, it's a ton of work with no real pay off.

Taking you're encoder library for example

main <- programmer interacts at this  layer

encoder <- provides all the functionality required

mcu architecture <- read/writes to the architecture specific registers (i.e AVR = PORT / ARM = ODR)

mcu specifics <- what pins exists

IMO making object libraries that are lightly coupled to their driver library is more important because the functionality required is 90% of the work.

#ifdef UNO
enum PINS : uint8_t  { 
	D8,D9,D10,D11,D13
	A0,A1,A2,A3,A4,A5	
	D0,D1,D2,D3,D4,D5,D6,D7
};

#elif ATMEGA328P
enum PINS : uint8_t  { 
    B0=0,B1,B2,B3,B4,B5,B6,B7,   //B6,7 usually used by the crystal, do not use with arduino 
    C0,C1,C2,C3,C4,C5,C6,C7,    //C6,7 are analog input only, only usable when using TQFP-32 packages
    D0,D1,D2,D3,D4,D5,D6,D7	
};

#elif MEGA
enum PINS : uint8_t  { 
	D8,D9,D10,D11,D13
	A0,A1,A2,A3,A4,A5	
	D0,D1,D2,D3,D4,D5,D6,D7
	//tons of other IO
};

#endif

or

//uno specific
enum PINS : uint8_t  { 
    PB0=0,PB1,PB2,PB3,PB4,PB5, 
    PC0=8,PC1,PC2,PC3,PC4,PC5,  
    PD0=16,PD1,PD2,PD3,PD4,PD5,PD6,PD7,
	
    D8=0,D9,D10,D11,D13
    A0=8,A1,A2,A3,A4,A5	
    D0=16,D1,D2,D3,D4,D5,D6,D7
};

>yes, "hacking" 

Even this little code has inefficiencies, for example, if you actually need to left shift, then ROL instructions get introduced, which means it's treating the data as 16 bits even when it's 8 bits. However that seems to be a common problem with C++ on AVR, no matter how hard you try it'll treat some stuff as 16 bits. I've seen a few threads regarding this. If you're working on the lower or higher 4 bits though it's a real godsend. 

I'm talking about what happens when you're waiting on I2C/Serial to finish sending a byte

I2C is normally 400KHz, 1/400KHz * 8 bits = 20uS 

Uno normal speed is 16MHz so, 20uS / (1/16MHz) = 320 cycles you're wasting waiting for the i2c to finish

A) implement callbacks?

B) go to sleep? If you do go to sleep you need make sure the user doesn't go into too deep a sleep mode otherwise multiple peripherals will stop and not trigger their respective wake up interrupts.

These are questions for future you, I thought you already knew all the internals and just wrote a new GPIO library to get started on this new quest.

Uno has 2000 bytes, do you think using 1 byte will change anything? Even on an attiny85, you'll have more problems with the limited amount of pins you have than ram usage.