jfpoilpret / fast-arduino-lib Goto Github PK

Today FastArduino relies on the rather old AVR8 GNU toolchain 3.5.4 (gcc 4.9.2), used with C++11 standard.

New toolchains have been released recently and provide support for more recent C++ standards.

As of today, the latest toolchain seems to be 3.6.1 (gcc 5.4.0). It would be nice to install it and check if:

• FastArduino make system still works with it (probably some options need to be adapted)
• FastArduino examples all compile with all targets
• Examples run on each target
• Code size is not larger than before
• Some new options may be used for further FastArduino optimization
• C++14 could be the C++ standard for FastArduino)

Dear developer,
this library is something I was looking for a long time. What is the project status, is it still alive?
Best regards, Susnicek

@jfpoilpret After reading a fair amount of the code I see that much is directly copied from the Cosa repository and then slightly updated, e.g. file name, inheritance/template, etc. In most cases the original Cosa copyright notice has been removed.

This device can be useful when using ATtinyX4 and ATtinyX5 MCU with limited nuber of pins.

Some AVR MCU have PWM pins that may be attached to more than one timer (only one at a time of course).
Currently, FastArduino supports only one PWM Timer for a given pin, hence an arbitrary choice is made when support is added for an MCU.

It would be nice to allow timer selection for those PWM pins that are linkable to several timers.

The current Queue implementation only supports powers of 2 for its buffer size, for performance (code size and speed) reasons.
But this may force usage of a buffer much bigger than needed (e.g. 64 items when you need maximum 40).
In addition, the actual queue size is 1 less than the real buffer size, which adds to the wasted SRAM space.

Investigate if allowing ANY size would impact performance a lot or not really much.
If impact is too important, study the possibility to have 2 distinct implementations for Queue, one optimized and the other not.

Hi @jfpoilpret,
it would be nice that fast-arduino-libs were compatible with standard avr Libc libraries (e.g. avr/io.h etc.). This compatibility is preserved with arduino libraries (avr headers can be normally used), however, concurrent use of fast-arduino-libs and avr headers ends with errors.

Best regards, S.

Today, FastArduino core API is mostly documented with doxygen and doc made available here.

However, there are still a few header files without API documentation:

• pulse_timer.h
• soft_uart.h
• square_wave.h

Current SPI support in FastArduino only supports the running MCU to act as the SPI master.

There are some occasions where we might need Arduino to be an SPI slave, e.g. when using SPI to connect 2 Arduinos together.

Bug initially reported by @urdh through PR #53

There are too many files in the root directory:

• make files & utility scripts
• documentation and examples sizes

Some of these files would better be located in a specific sub directory, so that the root directory contains only important files (e.g README, licenses...)

FastArduino currently supports several boards and Atmel AVR MCU, but makers may use other AVR-based boards or other MCUs.

Documenting how to add support for new a new board or MCU would ease FastArduino adoption by covering more possible configurations.

Documentation would explain:

• which header files to create and how
• what header files should be modified
• how to modify FastArduino makefiles
• how to adapt examples for a new board

Although already well filled with most common API, FastArduino tutorial is still missing coverage of some advanced topics such as:

• SPI usage & devices
• I2C usage & devices
• EEPROM handling

Hi,

The ArduinoDevSetup.docx. link in the readme gives 404 error.
Could not find it on the site either.

Dear developer,
I would like to ask if it is possible to add a support for user-selectable crystal frequencies. Maybe F_CPU macro will work, I do not know.
My point is to use your library for general code development for processors ATmega, ATtiny and their families. And I do not want to be bound to a specific board platform with pre-soldered crystals etc. Will be your library also aimed this way?

Best regards, Susnicek

The current way Toneplay and QTonePlay structs are defined only allows to specify notes durations as milliseconds.
This has the following impact:

• hard to transpose a musical score
• impossible to change tempo at play time

A better way would use normal musical notation for notes duration:

• whole note
• half note
• quarter
• eighth
• sixteenth
• thirty-second

And it shall also include dotted notes (not sure double-dots are needed, I haven' seen a lot of scores using them).

In addition, it should be possible to support slurs and ties (concretely that would mean no internote delay).

Improve build automation to:

• generate a sheet with all sizes of all examples in all supported targets
• trigger alarms in case of important size variation between 2 builds (size increase may mean bad code optimization or refactoring, size decrease may be triggered by a new bug in code)
• directly integrate snippets and their sizes in tutorial (both Arduino IDE and FastArduino)

Not sure how far we can go on the third point, that will depend a lot on doxygen facilities.

Review all classes and implement (or forbid) the following:

• copy constructor
• move constructor
• assignment
  This is not of absolute priority of course, but we all love perfectly clean code.

Currently, EXT and PCI pins are just listed, for each board, as namespaces (ExternalInterruptPin and InterruptPin) with constant DigitalPin values.
This means that any API requiring an EXT or PCI pin as argument, actually defines the argument type as DigitalPin and the adds static_assert calls to check the actual pin.
This is fine but this prevents proper code completion in an IDE.

A much better way would be to replace the 2 namespaces with 2 strong enum types.
This will have an impact on all API, and examples, using EXT and PCI pins.

Currentl, doxygen generation seems to "forget" some namespaces (or more precisely, namespaces inside namespaces) in some of the generated files:

In the example above, as we can see, we have the following issues:

• the description of namespace devices is incorrect (that's the description for namespace devices::rtc)
• the following devices sub-namespaces are missing: audio, magneto, rf...)

The problem might be due to doxygen comments directly set before declarations like:

namespace devices::rtc 
{
...
}

Dear @jfpoilpret,

I followed the documentation and tried to compile the fast-arduino-lib package using the command 'make CONF=UNO build'. However, the command yielded the following error:

avr-g++ -MT build/ARDUINO_UNO-16MHz/cores/fastarduino/soft_uart.o -MMD -MP -MF deps/ARDUINO_UNO-16MHz/cores/fastarduino/soft_uart.Td -mmcu=atmega328p -DF_CPU=16000000UL -DARDUINO_UNO -DNO_ABI -fno-exceptions -Wextra -flto -felide-constructors -Os -ffunction-sections -fdata-sections -mcall-prologues -g -Wall -I /media/data/Documents/Elektro/FastArduino/fast-arduino-lib-master/cores -std=c++17 -c -o build/ARDUINO_UNO-16MHz/cores/fastarduino/soft_uart.o /media/data/Documents/Elektro/FastArduino/fast-arduino-lib-master/cores/fastarduino/soft_uart.cpp In file included from /media/data/Documents/Elektro/FastArduino/fast-arduino-lib-master/cores/fastarduino/soft_uart.cpp:15:0: /media/data/Documents/Elektro/FastArduino/fast-arduino-lib-master/cores/fastarduino/soft_uart.h:67:17: error: expected '{' before '::' token namespace serial::soft ^ /media/data/Documents/Elektro/FastArduino/fast-arduino-lib-master/cores/fastarduino/soft_uart.h:67:19: error: 'soft' in namespace '::' does not name a type namespace serial::soft ^ /media/data/Documents/Elektro/FastArduino/fast-arduino-lib-master/cores/fastarduino/soft_uart.h:176:39: error: expected '}' before end of line /media/data/Documents/Elektro/FastArduino/fast-arduino-lib-master/cores/fastarduino/soft_uart.h:176:39: error: expected declaration before end of line make: *** [/media/data/Documents/Elektro/FastArduino/fast-arduino-lib-master/Makefile-common.mk:131: build/ARDUINO_UNO-16MHz/cores/fastarduino/soft_uart.o] Error 1

My compilation attempt was performed under the Debian Linux 4.19.37-5 (Sid), version of my avr-g++ is 5.4.0. Any advice on this issue?

Best regards, Susnicek

FastArduino currently supports Input Capture on timers with this feature.
But this specific timer feature on AVR also includes an optional Input Capture Noise Canceler.
FastArduino Timer API should also support this option.

I do not (yet) have a github fork from your repository so this as an issue.

I am not experienced in c++ templates but looking thru your code and a lot of reading :
When you add :

	template<board::DigitalPin DPIN_>
	using FastDigitalPin = typename FastPinType<DPIN_>::TYPE;
	/// @endcond

}
#endif /* FASTIO_HH */
/// @endcond 

to the end of gpio.h
You add the functionality to use

     FastDigitalPin<DigitalPin::LED> led{PinMode::FASTOUTPUT};

as alternative for

     FastPinType<DigitalPin::LED>::TYPE led2(PinMode::FASTOUTPUT);

Leading to more readable an understandable code

Currently analog::AnalogInput allows ADC on-demand (just by calling sample()).

AVR MCU ADC circuitry offers more interesting features, in particular "auto trigger" which allows repeated sampling on an analog input pin.

It would be nice to support this feature and propose a callback notification when e.g. latest sample has changed.

This may require refactoring of analog namespace because auto-trigger mode can work with only one analog input and shall prevent on-demand sampling while active.

Bug reported by @urdh through PR #54
2 affected methods in utilities namespace.

Currently, FastArduino ATtiny85 support enables only 2 PWM pins, both based on Timer0.

Event though currently FastArduino does not allow support for PWM pins linked to more than 1 timer, that still leaves room for pin PB4 (OC1B).

Latest SonarQube scan shows a lot of issues.
It is important to either:

• fix issues that deserve fixing
• change SonarQube rules settings for rules that need it
  Find if it is possible to define false positive on issues (normally available with SonarQube, but it does not seem to work on cloud instance?)

FastArduino provides a "framework" for building I2C and SPI devices more easily.
Although this API is already documented, it would be nice to have a dedicated tutorial part describing how to create new devices (SPI or I2C) for FastArduino, with practical examples and best practice.

Many FastArduino API classes define a public register_xxx_handler() method when it has callback methods to be called by an ISR (itself registered with one REGISTER_XXX macro).

In most cases currently, calling this method is the responsibility of the application developer, but it is easy to forget and in this case, it may take time to understand why the program does not seem to work at all!

The purpose of this issue is to review all FastArduino classes with a public register_xxx_handler() method, check if that method should rather be called at construction time, and if so, simply move its code to the constructor(s).

Currently FastArduino provides specific support to several external devices (e.g. SIPO chips, Buzzers, Servo, Magnetometer, Accelerometers...)

Since support of these devices is part of FastArduino project, all relevant API should be documented with doxygen, the same way as FastArduino core API.

Still to be defined: format(s) to support (FAT16, FAT32, others...)
File API shall be integrated to iostream API (for text files).

Using the following snippet:

devices::magneto::Sensor3D accel;
accelgyro.accel_measures(accel);

devices::magneto::Sensor3D gyro;
accelgyro.gyro_measures(gyro);

devices::magneto::AllSensors sensors;
accelgyro.all_measures(sensors);

output << streams::setw(6) << "var"   << " |" << streams::setw(8) << "sep."  << " |" << streams::setw(8) << "comb."         << "\r\n";
output << streams::setw(6) << "ACC_X" << " |" << streams::setw(8) << accel.x << " |" << streams::setw(8) << sensors.accel.x << "\r\n";
output << streams::setw(6) << "ACC_Y" << " |" << streams::setw(8) << accel.y << " |" << streams::setw(8) << sensors.accel.y << "\r\n";
output << streams::setw(6) << "ACC_Z" << " |" << streams::setw(8) << accel.z << " |" << streams::setw(8) << sensors.accel.z << "\r\n";
output << streams::setw(6) << "GYR_X" << " |" << streams::setw(8) << gyro.x  << " |" << streams::setw(8) << sensors.gyro.x  << "\r\n";
output << streams::setw(6) << "GYR_Y" << " |" << streams::setw(8) << gyro.y  << " |" << streams::setw(8) << sensors.gyro.y  << "\r\n";
output << streams::setw(6) << "GYR_Z" << " |" << streams::setw(8) << gyro.z  << " |" << streams::setw(8) << sensors.gyro.z  << "\r\n";

I would expect the acceleration and gyroscope measurements to be very similar between these three calls (i.e. that sensors.accel.x be very close to accel.x and so on), but instead I get this:

   var |    sep. |   comb.
 ACC_X |    1800 |     -21
 ACC_Y |     -60 |    -164
 ACC_Z |  -16288 |     -20
 GYR_X |     -16 |    1728
 GYR_Y |    -170 |    -148
 GYR_Z |     -30 |  -16364

It looks to me like the driver is reading the gryo and acceleration data in the wrong order.

Currently FastArduino supports several Arduino boards and Atmel MCU:

• Arduino UNO
• Arduino NANO
• Arduino Leonardo
• Arduino MEGA2560
• ATmega328
• ATtinyX4

There are some simple circuits, with few IOs, that do not require using an ATtinyX4, but would perfectly fit a smaller MCU like the ATtinyX5.

Adding support for ATtinyX5 in FastArduino would allow using the library for such simpler circuits.

FastArduino API, although currently well documented through doxygen markup, is not fully documented yet.

Among undocumented important namespaces, there are:

• containers
• events (partly documented)
• eeprom
• spi
• i2c

Also, supported devices have not yet been documented, e.g.:

• DS1307 (RTC)
• MPU6050 (Accelerometer-Gyroscope)
• ...

API documentation is very important to ease use of an API, in particular when an API may be more complex than usual.

FastArduino example iostreams3 demonstrates this issue:
ios.rdstate() is 0 in case of:

• buffer overflow
• maybe other error conditions (to be verified individually)

Note: incorrect input formatting (failbit) is correctly transmitted.

Current I2C support in FastArduino only supports the running MCU to be the I2C bus master.

There are some occasions where we might need Arduino to be a slave on the I2C bus.

FastArduino 1.0 sonar API has the following flaws:

• does not support timeout in asynchronous mode
• requires its own timer
  It should be improved to:
• use RTT instead of Timer (an RTT can be shared across the whole program)
• support timeout in asynchronous mode
• increase performance of ISR callbacks (defer calculation outside ISR)

Currently, when TonePlayer plays a melofy it blocks the main loop until the melody finishes.
In particular, all delays for playing each note are busy loop delays.

Although in latest commits, it can be stopped, it is not enough.
It should be possible to play a melody entirely asynchronously (based only on timer interrupts).

@jfpoilpret This was a nice project you have started. I was looking for some benchmarks to support your claims on the README page. Are there any? Or is this just from "experience"?

Refer to example PinChangeInterrupt1bugMEGA for a demo.
The MEGA has peculiar implementation of PCINT1 registers; these registers group PCI pins from 2 different ports (PE and PJ), leading to a bit shift in these registers.
FastArduino, in its current implementation, takes it for granted that PCINT registers bits map to the corresponding bits of one single port.

The failing API is interrupt::PCISignal<board::Port>:: enable_pin<board::InterruptPin>() (and similar API: disable_pin(), enable_pin_(), disable_pin_()).

The proper correction for this bug would consist in in refactoring FastArduino traits related to PCINT in order to:

1. Allow bit shifts in registers masks
2. Allow more than one port for a single PCINT vector

One possible workaround (ugly) is to use interrupt::PCISignal<board::Port>:: enable_pins(mask) with the proper mask.

I2C is a rather slow protocol (100KHz or 400KHz, depending on connected devices).
Currently, FastArduino support for I2C is completely synchronous, i.e. any read or write is blocking the caller even though it may last several milliseconds (for big payloads).

Adding an asynchronous mode of operation could be useful. API is to be determined for easy use.

Current serial::soft::UATX implementation should be improved to:

• prevent pushing chars to associated queue after end() has been called
• flush all queued characters when end() is called

Both serial::soft::UATX and serial::soft::UARX shall have their code (generated assembly) be reviewed and optimized to be able to support all transfer speeds up to 230400bps (or more).