wovo / hwlib Goto Github PK

demo/arduino-due/
oled graphic demo's cannot be compiled because method: 'channel' does not exist.

#include "hwlib.hpp"

int main( void ){
       
   namespace target = hwlib::target;
   
   auto scl      = hwlib::target::pin_oc{ hwlib::target::pins::scl };
   auto sda      = hwlib::target::pin_oc{ hwlib::target::pins::sda };
   
   auto i2c_bus      = hwlib::i2c_bus_bit_banged_scl_sda( scl, sda );
   
   // i2c_bus channel method does not exist
   //auto oled_channel = i2c_bus.channel( 0x3c );
   //auto oled         = hwlib::glcd_oled_i2c_128x64_direct( oled_channel ); 

   // This works...
   auto oled         = hwlib:: glcd_oled_i2c_128x64_direct(i2c_bus)
   // Constructor glcd_oled_i2c_128x64_direct
   // glcd_oled_i2c_128x64_direct( i2c_bus & bus, uint_fast8_t address = 0x3C ): 
   hwlib::graphics_random_circles( oled );  
   
}

In the 23a38ca commit, it's impossible to call a rectangle/line(from the v1oopc-examples directory) due to an unmatching function call.
Full error:
In file included from /home/vvamp/hwlib/library/hwlib.hpp:75, from line.hpp:7, from rectangle.hpp:7, from rectangle.cpp:4: /home/vvamp/hwlib/library/targets/hwlib-native-sfml.hpp: In constructor ‘hwlib::target::window::window(int, int, int)’: /home/vvamp/hwlib/library/targets/hwlib-native-sfml.hpp:52:61: error: no matching function for call to ‘hwlib::target::window::window(hwlib::xy, int&)’ window( int x, int y, int m = 5 ): window( xy( x, y ), m ){} ^ /home/vvamp/hwlib/library/targets/hwlib-native-sfml.hpp:52:4: note: candidate: ‘hwlib::target::window::window(int, int, int)’ window( int x, int y, int m = 5 ): window( xy( x, y ), m ){} ^~~~~~ /home/vvamp/hwlib/library/targets/hwlib-native-sfml.hpp:52:4: note: no known conversion for argument 1 from ‘hwlib::xy’ to ‘int’ /home/vvamp/hwlib/library/targets/hwlib-native-sfml.hpp:37:4: note: candidate: ‘hwlib::target::window::window(hwlib::xy, hwlib::color, hwlib::color, int)’ window( ^~~~~~ /home/vvamp/hwlib/library/targets/hwlib-native-sfml.hpp:37:4: note: no known conversion for argument 2 from ‘int’ to ‘hwlib::color’
This was on a clean ubuntu 19.04 and 18.04 LTS installation.
Reverting to an earlier commit fixed this issue.

In this commit multiple binaries are pushed upstream. There are also a lot of IDE specific files in the repo.

The documentation tells us this:

/// This constructor sets the pin direction to input.
/// By default, the internal weak pull-up is enabled.

The mode cnf wil be set to 1000.

But as can be seen in above image this depends on the PxODR register. So if it was an output before and it was put low it will be a pull down.

Lately I've ran into an issue where pins are not copyable (which makes sense because you shouldn't have two objects owning the same hardware pin). However C++11 introduced rvalue semantics to improve move semantics.

Now some of my classes use hwlib::target::pin_out, which are constructed separately and provided as a reference with type: hwlib::pin_out&. Now this requires the lifetime of the concrete pin type to be longer than the reference. For factory-like patterns heap usage is usually required, to meet the required object lifetimes.

Providing hwlib::target::pin_out(hwlib::target::pin_out&&) constructors allows for the following pattern (C++17):

class ComplexInterface {
  hwlib::target::pin_out p1;
  hwlib::target::pin_out p2;
  
  ComplexInterface(hwlib::target::pin_out&& p1, hwlib::target::pin_out&& p2) :
    p1(p1),
    p2(p2)
  { }
};

// For the following code no copies are made, which is 
ComplexInterface createComplexInterface(ComplexInterfaceParams) {
  // initialization code
  return { hwlib::target::pin_out(...), hwlib::target::pin_out(...) };
}

If there any cons to this pattern, I would gladly hear them.

Looking at this line should the keyword final not be used? If this is omitted then a vtable would need to be created and the generated code would bloat.

I've made an example of this on godbolt

link to code

static uint_fast16_t abs( uint_fast16_t x ){
      return x >= 0 ? x : -x;
}

the above function is written in the line class, however, it is meaningless as unsigned integers are always an absolute value.

504 is out of range for uint8_t:

FWIW: -Wtype-limits detects this, also via -Wextra.

Why is it that when I only want to say, blink a led with hwlib everything in hwlib ends up in the binary? hwlib is so big now that this is becomming an issue if I use hwlib outside of bmptk, binaries end up so big that I cannot link succesfully if I dont optimize with at least -O1.

https://itz.koon.io/koon/hwlib_hwspi

When trying to cout doubles, the following message appears:

The uart ouput seems to have a strange bug where if you start using the uart to quick it goes on a different baud rate

Compiled program

#include "hwlib.hpp"

int main( void ){
    // kill the watchdog (ATSAM3X8E specific)
    WDT->WDT_MR = WDT_MR_WDDIS;    
    
    hwlib::wait_ms(1); // This looks like it fixes the behaviour of the uart output
    
    for(int i = 0; i < 100; i++){
        hwlib::target::uart_putc('A');
    }
}

Without the wait and CONSOLE_BAUDRATE set to 115200 baud

With the wait and CONSOLE_BAUDRATE set to 115200 baud

Pull request #24 Introduces the use of sam3xa.h, but this is not included in the wovo/installers repo.
compiling with #include "sam3.h" works fine but ```#include sam3xa.h" gives the following error:
https://pastebin.com/1CeMTsDn

link to code

   static constexpr uint8_t clip( uint_fast16_t x, bool transparent = false ){
      return ( transparent )
         ? 0
         : ( x < 0 ) 
            ? 0 
            : ( x > 0xFF ? 0xFF : x ); 
   }  

This is 3 nested ternary operators!

And one of them checks if an unsigned integer x is smaller than 0, this is always false. Could be rewritten this way:

static constexpr uint8_t clip(uint_fast16_t x, bool transparent = false) {    
    if (transparent)
        return 0;
    else if (x > 255)
        x = 255;
    return x;
}

This would do the same thing. Godbolt comparison:
https://godbolt.org/g/lcCYMT
https://godbolt.org/g/fbqGDf

link to code

      uint_fast16_t Dx = x1 - x0; 
      uint_fast16_t Dy = y1 - y0;
   
      uint_fast16_t steep = (abs(Dy) >= abs(Dx));
   
      if( steep ){
         swap( x0, y0 );
         swap( x1, y1 );
      
         // recompute Dx, Dy after swap
         Dx = x1 - x0;
         Dy = y1 - y0;
      }
   
      uint_fast16_t xstep = 1;
      if( Dx < 0 ){
         xstep = -1;
         Dx = -Dx;
      }
   
      uint_fast16_t ystep = 1;
      if( Dy < 0 ){
         ystep = -1;    
         Dy = -Dy; 
      }

First you declare Dx and Dy to be an unsigned integer, then you check if they're smaller than 0. This is always false and does nothing.

The \n in the above line does not do a carriage return in most Linux serial viewers. I think an \r should be added but then it's not a single char anymore.

In hwlib-string.hpp, the find and rfind operators use a while loop that compares an index to a position but the poisition / index never get incremented which causes the program calling these operators to hang in an infinite loop.