TX and RX LEDs

Hardware Arduino Zero
#1

The Arduino Zero's current build, 1.6.6, activates the Tx and Rx LEDs to indicate activity on the native USB port.

In previous builds these Tx and Rx LEDs remained unused by the Arduino core code, but could be activated in your sketch. If like me you decided to take advantage of these former unused the Tx and Rx LEDs for your own purposes, then it's necessary to deactivate the Tx and Rx pins on the USB native port.

Fortunately Arduino have wrapped the Tx and Rx LED's code in #ifdef directives in the native USB file. This means that if you comment out the PIN_LED_TXL and PIN_LED_RXL definitions in the Zero's "variant.h" file, it'll deactivate the Tx and Rx LEDs on the native USB port and your free to use them in your sketch oncemore.

Code snippet from "variant.h":

// LEDs
#define PIN_LED_13           (13u)
//#define PIN_LED_RXL          (25u)
//#define PIN_LED_TXL          (26u)
#define PIN_LED              PIN_LED_13
#define PIN_LED2             PIN_LED_RXL
#define PIN_LED3             PIN_LED_TXL
#define LED_BUILTIN          PIN_LED_13
#2

Hi Martin,

Thanks for the info. I've been looking for ways to regain some of the "lost" pins on the ATSAMD21G18. I would like to use the Feather m0 or the SAMD21 Mini Breakout as templates for a board I will spin. Do you have any experience using PA05, PA12, PA13, PB02, PB10, PB11, PB22 or PB23?

This will be my first exploration into the ATSAM parts, so I'm not sure about some of the pin idiosyncrasies. I'm planning on flashing the bootloader via the 10 pin interface, but won't be using the SWCLK and SWDIO pins for anything after flashing. I'd really like to use them as a serial port. Is that possible?

Any thoughts or personal experience would be most appreciated.

John

#3

Hi John,

Yes, it's possible to reassign these "lost" pins to other functions in you own board design.

If you're looking to make your own board then table 6.1: "PORT Function Multiplexing" in the SAMD21 datasheet (pages 20-22) is really useful, especially if you plan to deviate in any way from the Feather M0/SAMD21 Mini Breakout pin assignments. It describes which peripheral functions, for example external interrupts, ADC, SERCOMs, timers etc.. are assigned to each pin.

Another major advantage is that having the flexibility to multiplex a given peripheral to other alternative pins can greatly simplify the board layout, but it really depends how far you wish to deviate from your "template" board.

The mapping between you the SAMD21G's port pin numbers (PA00, PA01,...) and the Arduino/Feather M0 pins definitions (D0, D1,...) are held in your board's "variant.cpp" file.

Using an external 32.768kHz crystal on PA00 and PA01 like the Arduino Zero, Feather M0, etc..., will save you the trouble of having to mess around with the start-up registers to use another oscillator. I use an Abracon ABS07-32.768KHZ-T crystal with 22pF capacitors.

Regarding the 10 pin interface, I haven't multiplexed it with other functions in my designs, but it's certainly possible. Looking at the datasheet, the external debugger pulls the SWCLK low during reset to put the SAMD21 into debug/programming mode. Otherwise, in the absence of the debugger SWCLK should remain high during this time. Although, if you do decide to multiplex these lines, I imagine you have to be careful which device you connect to them to ensure there's no conflict.

If your design's running short of pins, it's also possible to use the larger 64-pin SAMD21J18A with the Arduino Zero bootloader. The SAMD21J has 14 more IO pins and two extra timers TC6 and TC7. To get it working you just need to add the extra pins to the "variant.cpp" file. Internally though, it's just the same as the SAMD21G18A.

Martin

#4

Martin,

Thanks so much for taking the time to answer and share your experience!

Excellent, that's good to hear. I'm trying to convince myself now, that the extra effort porting existing code to the new hardware will be possible/worth it. It looks like I'm using some hardware specific code that will take some effort to get working on the SAMD part. I will have some hardware to play with tomorrow.

Yes, I had seen a version of the muxing table on Adafruit's tutorial on their Feather m0. Your mention of it's location in the datasheet got me reading. Now that I've installed the board definitions for the Sparkfun and Adafruit boards, I'll look at the variant files for the boards. I'm sure your suggestion to reassign pins to simplify layout will keep me busy, now that I know I can have a nice, neat board with a little work :slight_smile:

I plan on sticking with the 32.768 crystal to keep things simple. I had spec'd: ABS07AIG-32.768KHZ-1-T with a +/-10ppm accuracy with the same cost and characteristics as the one you are using. I would like to delete a battery backed RTC from my current design. Have you had any experience with backing up the SAMD with a coin cell to hold the time? I saw in the datasheet the RTC oscillator is powered from the VDDANA pin.

It looks like I've got plenty of pins if I can use TX/RX LED pins and the others that aren't brought out on the Zero based boards. I don't think I'll need to use the SWCLK or SWDIO at this point. I'd be in tall corn if I could eliminate the I2C RTC and get those pins back as well. Plus, save some cost on the extra parts for the external RTC and supporting parts it requires.

Thanks again,

John

#5

Hi Martin,

Well, I've got the new hardware and I'm working on porting the 328P code over. I ended up using the PIN_LED_TXL as the LCD backlight control pin. It took me a while to figure out why I couldn't get the backlight to stay off. It finally hit me what pin I was using.

Unfortunately, just commenting out the defines like you had done in your OP prevented the sketch from compiling. Luckily, pin (25u) was unused so I just defined both LEDs as (25u) in the Variant file.

But, enough about the background leading up to the question...

I was trying to find some way to achieve the same result without modifying the Variant.h file. I'd like to not get myself into "custom" files at that low of level. Is there any way to achieve the same result without altering the Variant.h file?

I tried:

#ifdef PIN_LED3
  #undef PIN_LED3
#endif
#define PIN_LED3 (25u)

But, it didn't work. I would assume the Variant.h file gets handled way too early in the compile process for that to work?

Thanks,

John

#6

Hi John,

If you're using your own custom boards with the Arduino IDE, then creating your own board entry in the IDE's "Boards Manager", is probably the best way to avoid having to edit your Zero's "variant.h" and "variant.cpp" files.

It uses a JSON file, whose specification is described here: Arduino IDE 1.6.x package_index.json format specification · arduino/Arduino Wiki · GitHub

It's something that I'm going to look into this week, as I've got two Zero based custom boards and it's becoming a pain to edit the "variant" files each and everytime I need to switch between them. I'll post the solution here once I've got a working example.

Martin

#7

Hi Martin,

Ahhh, that's a nifty way to tackle the issue! That would also work well for users that I have that may need to re-flash the boards. I'll look forward to hearing how it goes for you. Thanks for all the work you do on the Zero.

John

#8

See also GitHub - WestfW/ArduinoZero-PMUX-report: Generate a user-readable report of the current state of the pins (what they're doing) on Arduino Zero and other SAMD21 based systems which will eventually be a library for reporting on the pin status of various arduino pins. (right now it's not quite arranged in "library" form.) You can give it code like:

  pinmux_report(PIN_LED_RXL, buffer, "RXL");
  mySerial.println(buffer);
  pinmux_report(PIN_LED_TXL, buffer, "TXL");
  mySerial.println(buffer);

And get output like:

25 [RXL] PB03  GPIO O
26 [TXL] PA27  GPIO O
#9

Where is the header file in window directory?

Blink example change to RX or TX led.

#10

@siebchen On my Windows machine the directory for the TX and RX LED pins for the SAMD21 boards can be found in the "variant.h" file here:

C:\Users\Computer\AppData\Local\Arduino15\packages\arduino\hardware\samd\1.8.11\variants

Each board's "variant.h" file, is stored in the folder bearing its name.

#11

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.