DigitalReadFast DigitalWriteFast Library on Uno Wifi Rev 2

Hi,

I’m working a project for the new Uno Wifi Rev2 board that is soon (I hope) to be released. I noticed that the online editor now has the Wifi Rev 2 board in the board pick list, so I tried compiling the code to make sure it was ok, and I got this error from the DigitalRead/WriteFast Library I’m using:

In file included from /tmp/114249633/tower_controller/tower_controller.ino:14:0:
/tmp/114249633/tower_controller/tower_controller.ino: In function ‘void Process_Command()’:
/tmp/114249633/custom/digitalWriteFast/digitalWriteFast.h:26:30:

error: ‘TCCR0A’ was not declared in this scope

(((P) == 6 || (P) == 5) ? &TCCR0A : \

Does this library have to be updated for the new boards? The Wifi Rev2 has a new microchip micro.

I’m using this library to read and write to the I/O pins in an interrupt service routine. I only read one pin in the routine, and then potentially write 1 or 2 pins based on some logic in the ISR. I’m not sure if I need the “fast” library or not. I guess I can try it without and see what happens.

Is direct port access an option? I’m new to Arduino, but I’ve done some embedded programming in my past.

Here is my ISR:

// Interrupt service routines for the encoder
void HandleInterrupt()
{
// Test transition; since the interrupt will only fire on ‘rising’ we don’t need to read pin A
Current_Location += digitalReadFast(EncoderPinB) ? 1 : -1; // Increment/decrement current location

if (Current_Location >= MAX_LOCATION){ // Either overflow or underflow occured.
// Stop all motion

// Write to Relay Ports to stop motor
digitalWriteFast(Forwards_Relay, LOW);
digitalWriteFast(Backwards_Relay, LOW);

// Update indicator variables
Moving_Forwards = false;
Moving_Backwards = false;
}
else if (Moving_Forwards)
{
if (Current_Location >= Target_Location) // Has tower reached (exceeded) target location?
{
// Stop forward motion

// Write to Relay Ports to stop motor
digitalWriteFast(Forwards_Relay, LOW);

// Update indicator variable
Moving_Forwards = false;
}
}
else if (Moving_Backwards)
{
if (Current_Location <= Target_Location) // Has tower reached (exceeded) target location?
{
// Stop backwards motion

// Write to Relay Ports to stop motor
digitalWriteFast(Backwards_Relay, LOW);

// Update indicator variables
Moving_Backwards = false;
}
}
}

Thanks for any help.

If the Arduino WiFi is based one the same ATmega328P as the Arduino UNO then Timer/Counter Control Register 0 A should be defined. If it is based on some other processor it may take a while to get the Fast library updated. You could use a regular digitalWrite() or direct port manipulation, if you really need the speed.

The ATmega4809 used on the Uno WiFi 2018 is quite different from the ATmega328p used in an Uno, and I would not expect any particular "digitalWriteFast" library to work without extensive modifications. In particular, the pin mapping has changed, an the PORTS are different. It looks like the 4809 has some backward-compatibility hacks, but I wouldn't expect them to be "fast."

Which digitalWriteFast library are you using?

Hi All,

Thanks for the responses. I figured the new micro would require updates to any library that trying to directly access the HW.

I'm using this library:https://github.com/NicksonYap/digitalWriteFast

I came across this when researching how to read an encoder, and the code I borrowed for the basis of my ISR used it.

Doing a few calculations for my project( I'm using an encoder to control the position of an A/C powered winch), the pulses/interrupts from the encoder are coming in every ~42ms, so it is questionable if I need a fast read/write to ensure I don't miss a pulse. I will not be using and Serial commands, but will have the position commands coming in from the WiFi interface.

Thanks again for any help or comments.

42 ms is 672,000 instruction cycles. I don't think you need to worry about fast digital I/O.

I’m using this library: GitHub - NicksonYap/digitalWriteFast: Arduino library for faster digitalWrite using port manipulation and macro for ease in pin assignments.

definitely doesn’t support the new chip…