"Please define board in avrpins.h" error compiling for board Arduino NANO 33 IoT.

[bsperryn]

How should I go about defining the pins for the Arduino Nano BLE IOT? I have the pinout diagram for the board, but how to map the pin variables in your library to the pins on the board?

[Lauszus]

Closing this, as it is a duplicate of #541.

[Lauszus]

Sorry I was too quick. It's a different chip. I'll reopen :)

[Lauszus]

Please see how it was done for example for the Teensy 4: https://github.com/felis/USB_Host_Shield_2.0/pull/564/files and do something similar.

When you are done, then please send a pull request, so others can benefit form it as well.

[bsperryn]

Thanks, I will do, I just need to understand the relevance of the pin mapping? Is it just a case of listing all pins or do different pin variables have different functions that I need to be aware of?

How do I define which pins are for SS and Int?

Miso, Mosi and Sck seem to be predefined on the board so will these be automatically picked up?

On Thu, 11 Mar 2021 at 09:55, Kristian Sloth Lauszus < @.***> wrote:

Please see how it was done for example for the Teensy 4: https://github.com/felis/USB_Host_Shield_2.0/pull/564/files and do something similar.

When you are done, then please send a pull request, so others can benefit form it as well.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/felis/USB_Host_Shield_2.0/issues/608#issuecomment-796613899, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOKXLCBFOD4DG62QUJHM6LTDCHPZANCNFSM4Y65U63Q .

[Lauszus]

It was done for historical reasons, as this library was written long before everything was Arduino compatible.

By default it will use pin 10 and 9 for SS and INT, but that is not practically for some boards like the ESP32, so it can be remapped: https://github.com/felis/USB_Host_Shield_2.0/pull/341/files?w=1#diff-2ca4a0615d630f42243567cff4688ac5ef789dd193655916f1545c07e5968126R45, but in your case the default should be fine.

Yes the MISO, MOSI and SCK pins will get picked up by this crazy macro I wrote: https://github.com/felis/USB_Host_Shield_2.0/blob/master/usbhost.h#L95-L106

[Lauszus]

Also check out the ESP8266 chip for more inspiration: https://github.com/felis/USB_Host_Shield_2.0/pull/263/files

[bsperryn]

Thanks for all your help!

I was having a problem with UsbDevice also being defined in SPI.h, so I've had to rename the UsbDevice Struct to UsbDeviceStruct.

I've done it like this:

        #ifdef ARDUINO_SAMD_NANO_33_IOT
            UsbDeviceStruct *p = NULL;
        #else
            UsbDevice *p = NULL;
        #endif

Let me know if you'd like me to change the way I've done it, I could just rename the class name across all files and remove the extra ifdef.

I'm now getting the following error that I haven't been able to work out:

`usbhost.h:103:25: error: 'P13u' was not declared in this scope

define APPEND_PIN(pin) P ## pin // Appends the pin to 'P', e.g. 1 becomes P1`

The code I added to Avrpins looks like this:

#elif defined(ARDUINO_SAMD_NANO_33_IOT)
// Arduino nano BLE 33 IOT

#define MAKE_PIN(className, pin) \
class className { \
public: \
  static void Set() { \
    digitalWrite(pin, HIGH);\
  } \
  static void Clear() { \
    digitalWrite(pin, LOW); \
  } \
  static void SetDirRead() { \
    pinMode(pin, INPUT); \
  } \
  static void SetDirWrite() { \
    pinMode(pin, OUTPUT); \
  } \
  static uint8_t IsSet() { \
    return digitalRead(pin); \
  } \
};

MAKE_PIN(P2, 2);
MAKE_PIN(P3, 3);
MAKE_PIN(P4, 4);
MAKE_PIN(P5, 5);
MAKE_PIN(P6, 6);
MAKE_PIN(P7, 7);
MAKE_PIN(P8, 8);
MAKE_PIN(P9, 9);
MAKE_PIN(P10, 10);
MAKE_PIN(P11, 11); //MOSI
MAKE_PIN(P12, 12); //MISO
MAKE_PIN(P13, 13); //SCK

#undef MAKE_PIN

Any help would be much appreciated.

[bsperryn]

It's the same for P12u, P11u, P10u. I can see this is because they're the pins for SCK(13), MISO(12), MOSI(11), SS(10), but I can't work out where the 'u' is coming from.

I've done the following to remove the errors:

#define P10u  P10
#define P11u  P11
#define P12u  P12
#define P13u  P13

but I'm not sure whether the library will work with these set like this?

I'm also getting more errors such as this one:

Library/Arduino15/packages/arduino/tools/CMSIS-Atmel/1.2.0/CMSIS/Device/ATMEL/samd21/include/samd21g18a.h:516:27: error: expected identifier before '(' token
 #define USB               ((Usb      *)0x41005000UL) /**< \brief (USB) APB Base Address */

[bsperryn]

Turns out that the #define USB ((Usb *)0x41005000UL)was also a naming conflict... I've had to rename the USB class...

[Lauszus]

Yeah UsbDevice and USB was probably the best names to use. The Arduino Zero port had the same problem: https://github.com/felis/USB_Host_Shield_2.0/pull/202 and for that reason I never merged it...

[bsperryn]

Is it worth having these names refactored so that the library can work on more boards in the future or do you think there's just too much dependance on the naming as it is?

Maybe a fork is needed?

[Lauszus]

Hmm maybe we could rename them and just make some defines:

#if !defined(ARDUINO_SAMD_NANO_33_IOT)
#define USB USBHost
#define UsbDevice UsbDeviceDefinition
#endif

And then update all examples to use USBHost instead. This would allow us to add support for more boards, but without breaking all the existing code using this library :)

[bsperryn]

Sounds great, will do.

[bsperryn]

Which class should that be added to?

[sendevent]

Hey there! Nearly at the same time, I faced the same issue (tried to connect the Arduino Nano IoT with a clone of UHS mini using UHS20). Unfortunately, while the nano iot's HW is incredible, its SW support turned out to be not quite good (at least, for my task and by that time: no access to flash; limited/no auth in BLE; this particular thing with UHS20, etc). Considering it's my first experience with Arduino… I just gave it up and switched to another board :) So now I have no code to share, nor I do see reasons to try to provide complete support in UHS20's mainstream. I'm not sure what the @bsperryn 's progress is, probably there is an upcoming PR. But here is a brief description of steps I performed to get things running, for those who want to get it locally. The necessary refactoring is quite similar to the Teensy 4 branch, as @Lauszus said:

1. Set the necessary pins up in the avrpins.h (I don't remember the particular pin numbers, but the ones listed above seem to be correct; If you googled it, just keep in mind that sometimes the shield's MOSI and MISO pin labels are swapped);
2. Resolve all the name conflicts — rename the UHS's *USB* to something different from the names used in nano_iot's Arduino core;
3. (the trickiest thing, I spent way too much time to figure out; not sure why and how it's related, though): Reduce the clock frequency for SPI in usbhost.h to 12MHz:

diff --git a/usbhost.h b/usbhost.h
index de34813b..473f378d 100644
--- a/usbhost.h
+++ b/usbhost.h
@@ -131,6 +131,12 @@ typedef enum {
vbus_off = GPX_VBDET
} VBUS_t;

+#ifdef ARDUINO_SAMD_NANO_33_IOT
+        #define CLOCK_FREQ_HZ 12*1000*1000
+#else
+        #define CLOCK_FREQ_HZ 26*1000*1000
+#endif
+
template< typename SPI_SS, typename INTR > class MAX3421e /* : public spi */ {
static uint8_t vbusState;

@@ -179,7 +185,7 @@ template< typename SPI_SS, typename INTR >
void MAX3421e< SPI_SS, INTR >::regWr(uint8_t reg, uint8_t data) {
XMEM_ACQUIRE_SPI();
#if defined(SPI_HAS_TRANSACTION)
-        USB_SPI.beginTransaction(SPISettings(26000000, MSBFIRST, SPI_MODE0)); // The MAX3421E can handle up to 26MHz, use MSB First and SPI mode 0
+        USB_SPI.beginTransaction(SPISettings(CLOCK_FREQ_HZ, MSBFIRST, SPI_MODE0)); // The MAX3421E can handle up to 26MHz, use MSB First and SPI mode 0
#endif
SPI_SS::Clear();

@@ -222,7 +228,7 @@ template< typename SPI_SS, typename INTR >
uint8_t* MAX3421e< SPI_SS, INTR >::bytesWr(uint8_t reg, uint8_t nbytes, uint8_t* data_p) {
XMEM_ACQUIRE_SPI();
#if defined(SPI_HAS_TRANSACTION)
-        USB_SPI.beginTransaction(SPISettings(26000000, MSBFIRST, SPI_MODE0)); // The MAX3421E can handle up to 26MHz, use MSB First and SPI mode 0
+        USB_SPI.beginTransaction(SPISettings(CLOCK_FREQ_HZ, MSBFIRST, SPI_MODE0)); // The MAX3421E can handle up to 26MHz, use MSB First and SPI mode 0
#endif
SPI_SS::Clear();

@@ -280,7 +286,7 @@ template< typename SPI_SS, typename INTR >
uint8_t MAX3421e< SPI_SS, INTR >::regRd(uint8_t reg) {
XMEM_ACQUIRE_SPI();
#if defined(SPI_HAS_TRANSACTION)
-        USB_SPI.beginTransaction(SPISettings(26000000, MSBFIRST, SPI_MODE0)); // The MAX3421E can handle up to 26MHz, use MSB First and SPI mode 0
+        USB_SPI.beginTransaction(SPISettings(CLOCK_FREQ_HZ, MSBFIRST, SPI_MODE0)); // The MAX3421E can handle up to 26MHz, use MSB First and SPI mode 0
#endif
SPI_SS::Clear();

@@ -319,7 +325,7 @@ template< typename SPI_SS, typename INTR >
uint8_t* MAX3421e< SPI_SS, INTR >::bytesRd(uint8_t reg, uint8_t nbytes, uint8_t* data_p) {
XMEM_ACQUIRE_SPI();
#if defined(SPI_HAS_TRANSACTION)
-        USB_SPI.beginTransaction(SPISettings(26000000, MSBFIRST, SPI_MODE0)); // The MAX3421E can handle up to 26MHz, use MSB First and SPI mode 0
+        USB_SPI.beginTransaction(SPISettings(CLOCK_FREQ_HZ, MSBFIRST, SPI_MODE0)); // The MAX3421E can handle up to 26MHz, use MSB First and SPI mode 0
#endif
SPI_SS::Clear();

4. You're awesome! :)