Universal I/O C++ classes that should work with all 8bit AVRs

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been working on 2 classes to abstract how I/O pins are accessed and to be able to work on any 8bit AVR device (even the atmega128 with odd port addresses).

 

The project is available here: http://community.atmel.com/projects/universal-io-c-classes-should-work-all-8bit-avrs

 

Comments are welcome.

Last Edited: Sun. Apr 24, 2016 - 11:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Shame you made it GPLv2 which means it can never be used in anything commercial - but perhaps that's what you intended?

 

Also how efficient is the generated code? If I use your example:

int main() {
    Pin led(Port::B, 5, OUTPUT);
    
    while(true) {
        led.high();
        delay(1000);
        led.low();
        delay(1000);
    }
}

then do the .high/.low's really equate to single opcode SBIs and CBIs ? (I'm not in a position to build/test this myself right now).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GPLv2 doesn't prevent commercial use. It merely puts some restrictions on how the s/w can be used.

While I'll agree that commercial entities that create products with closed source hate GPL licensing because it effectively shuts down its use in those types of products,

having a GPL license does not preclude using the s/w in commercial products.

It merely means that only products that are based on open source can use it.

 

All that said, even with GPL 2.0 there are still some creative ways to legally use it with closed source components as well.

 

--- bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GPLv2 doesn't prevent commercial use. It merely puts some restrictions on how the s/w can be used.

Theoretically.  Being legally literal, i can't see how any of the Gnu licenses (even LGPL) are practical in (not open-source) embedded systems.  ("Provide for re-linking with a newer version of the library."  Right.)

 

do the .high/.low's really equate to single opcode SBIs and CBIs ?

No, the code produced seems particularly verbose and convoluted.  More of a simple demonstration of how to make a pin into an "object" rather than a serious attempt at an efficient replacement for C code. :-(

Which is a bit of a shame, since I've seen template-based implementations of similar classes that DO result in single-instruction set/clear operations.

 

I *do* like "PORT::C" as a way of using A/B/C/etc as names without "polluting" the global namespace.  I wonder if you can do that without actually instantiating objects that take up space?