Showing posts with label Protocol. Show all posts
Showing posts with label Protocol. Show all posts

Wednesday, August 8, 2018

Espressif ESP32 Tutorial - IR Remote Control using Microsoft Azure




The Project


This tutorial will outline how to create an IR Remote using the ESP32 and then control it from the IoT hub on Microsoft Azure.

Driving an IR remote transmitter using an Arduino is simple, as there is a library, called IRremote.h which does all the hard work. You just need to connect your IR transmitter module signal pin to the appropriate Arduino pin, via a current limiting resistor and you are done. Connecting an Arduino to the cloud takes a bit more work (depending on the model you are using), which is why we wanted to use the ESP32.

Unfortunately, the standard IRRemote.h Arduino library only supports receiving IR signals on the ESP32 not transmitting them. Fortunately, Andreas Spiess has forked the standard library and added ESP32 transmission capability. You will need to download the ESP32-IRremote library, so we can use it with the ESP32. Andreas did this by using ledC PWM. You can now select any pin to use with IRsend(pin). Note this is only for the ESP32, the other board types have defined pins you have to use due to the assigned timers.

The Duinotech Infrared Transmitter Module


The IR transmitting module which I used is the one from Jaycar (branded Duinotech). There is a data sheet available on the Jaycar site but it is fairly sparse and doesn't clearly define the pins on the module.

It appears that this module is based on the KY-005 INFRARED TRANSMITTER MODULE. The specifications for which are:


Operating Voltage 5V
Forward Current 20 ~ 60 mA
Power Consumption 90mW
Operating Temperature -25°C to 80°C [-13°F to 176°F]
Dimensions  18.5mm x 15mm [0.728in x 0.591in]

This being the case, the pin out is as follows:



The signal pin is clearly labeled with an S, the middle pin is GND via a resistor (* which you have to fit yourself to the module) and GND is connected to the third pin (with the "-" adjacent to it). This module is just an infrared diode (which emits at a wavelength of 940 nm).

Thus, we can drive it like any other diode via a current limiting resistor. The value of the resistor depends on what voltage your micro controller digital outputs (DO) are switching, the desired diode forward current and the forward voltage drop characteristic of the diode. So for our design:

VDO = 3.3V
If = 20 mA
Vf = 1.2V (nominally 1.1V but I measured this using my LCR meter)

Then, R = (VDO - Vf) / If
              = (3.3 - 1.2) / 0.02
              = 105 Ω



We will use a 100 Ω resistor in our circuit.



The CIR (Commercial Infrared) Transmission Protocol


As there are usually other sources of infrared radiation (e.g. sunlight and incandescent or LED lights), the 940nm IR transmitter is modulated by a carrier frequency in the 32-40 kHz range. CIR receivers incorporate a bandpass filter tuned to this carrier frequency. This allows the receiver to discriminate between the modulated IR signal and any ambient, unmodulated IR. In effect, the IR receiver is double tuned both to the wavelength of the IR radiation and to the carrier frequency.



Three factors influence CIR range. In order of decreasing importance they are: the power level of the IR emitter, the IR wavelength, and the carrier frequency. An IR emitter's output is proportional to the current through the emitter. Increasing the current will increase the power. Because the duty cycle is usually 50% or less, the emitter can be driven with quite high currents. For optimal range, the IR wavelength of the emitter and receiver should match.



A similar protocol to CIR is IrDA. IrDA was popular in the late 1990's but has largely been replaced by Bluetooth and WiFi. IrDA was designed to be very short range (< 1 m). It does not use any secondary carrier but directly modulates the 850nm IR with the data. Because of this, it is susceptible to interference from ambient IR. In addition, the IrDA transmitter is usually lower power than a CIR transmitter.

An IrDA transmitter with a CIR receiver is a mismatch as is a CIR transmitter with a IrDA receiver. They operate on a different wavelength (940 nm vs 850 nm), IrDA isn't modulated, and the beam angles are different (IrDA limits the beam angle to ±15° while most CIR emitters are ±40° or greater). Such mismatches have major effects on range and reliability.

We will use CIR in our design.

For RF control, both the transmitter and receiver need to be tuned to the same carrier frequency and need to use the same type of modulation. Most RF remotes use ASK (Amplitude Shift Keying) or OOK (On-Off Keying). OOK is really just a special case of ASK. OOK is also called CPCA (Carrier Present, Carrier Absent). You can have a look at the IRremote library to see how this coding is achieved.

Microsoft Azure




Azure is Microsoft's catch all name for their cloud services. It covers over 100 different services. The service of interest to us is IoT Hub. You can use Azure IoT Hub to securely connect, monitor and manage billions of devices to develop Internet of Things (IoT) applications. To get started we will connect just one device!

You will need to sign up for a free Azure account. Follow the link above and do this. For some reason Microsoft make you provide credit card details, even for the free account. Note that when you sign up, the email address you provide becomes the name of the default active directory (which wouldn't be my first preference).

It will be interesting comparing the Microsoft IoT hub functionality with node-red, which is another dashboard option that we have had experience with. At this stage I suspect that node-red is much cheaper (free) and simpler but Azure is more robust, secure and scalable. The key features of IoT hub are:
  1. Bidirectional communication with LOTS of devices. Use device-to-cloud telemetry data to understand the state of your devices and define message routes to other Azure services without writing any code. In cloud-to-device messages, reliably send commands and notifications to your connected devices – and track message delivery with acknowledgement receipts. Device messages are sent in a durable way to accommodate intermittently connected devices.
  2. Authentication per device. Set up individual identities and credentials for each of your connected devices, and help retain the confidentiality of both cloud-to-device and device-to-cloud messages. To maintain the integrity of your system, selectively revoke access rights for specific devices as needed.
  3. Automated device registration. Speed up your IoT deployment by registering and provisioning devices with zero touch in a secure and scalable way. IoT Hub Device Provisioning Service supports any type of IoT device compatible with IoT Hub.
  4. Use IoT Edge. Take advantage of IoT Edge to make hybrid cloud and edge solutions. IoT Edge provides orchestration between code and services so they flow securely between cloud and edge to distribute intelligence across a range of devices. Enable artificial intelligence and other advanced analytics at the edge.
Once you have signed up for Azure, you will be presented with a dashboard similar to that shown above.

Create an IoT Hub




Microsoft call their menus "blades" in Azure. No idea why, maybe because it sounds cooler than menu? Anyway, click on the + Create a resource link on the blade to the left of the dashboard. This will open the Azure Marketplace.

In the Marketplace, click on Internet of Things. This will provide a new list of menu options to the right.


We want IoT Hub at the top. Click on this to setup your hub. For subscription select Free Trial and for Resource Group, Create new.

The free tier is intended for testing and evaluation. It allows 500 devices to be connected to the IoT hub and up to 8,000 messages per day. Each Azure subscription can create one IoT Hub in the free tier.

A resource group is a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group.

Select the Region closest to your location. In Australia the options are East and Southeast, which I think refer to Sydney and Melbourne respectively.

To create an IoT hub, you must name the IoT hub. This name must be unique across all IoT hubs. The IoT hub will be publicly discoverable as a DNS endpoint, so make sure to avoid any sensitive information while naming it. Once created, the name can't be changed.

Click the button at the bottom labelled - Next: Size and Scale >>



For pricing and scale tier, select F1: Free tier. That is all that you can adjust on this screen. Click Review + create.

When all previous steps are complete, you can create the IoT hub. Click Create to start the back-end process to create and deploy the IoT hub with the options you chose.

It can take a few minutes to create the IoT hub as it takes time for the back-end deployment to run on the appropriate location servers. Once your new IoT resource has been created, you can customise your dashboard.


Add an IoT Device



Before a device or module can connect to your IoT hub, there must be an entry for that device in the IoT hub's identity registry. A device must also authenticate with the IoT hub based on credentials stored in the identity registry. The device or module ID stored in the identity registry is case-sensitive.

To add a new IoT device, click on + Add, and the Add Device blade will be displayed.

  • Device ID: A case-sensitive string (up to 128 characters long) of ASCII 7-bit alphanumeric characters.
  • Authentication Type: Symmetric Key or X.509 Certificate. I used Symmetric Key. The differences are:
    • Symmetric Key: a unique identity key (security tokens) for each device, which can be used by the device to communicate with the IoT Hub.
    • X.509 Certificate: uses an on-device X.509 certificate and private key as a means to authenticate the device to the IoT Hub. This authentication method ensures that the private key on the device is not known outside the device at any time, providing a higher level of security.
  • Auto Generate Keys: tick.
  • Connect device to IoT hub: enable.

Click on Save, and your new device will be added to the hub. Click on the device ID of the newly added device to see the security keys and connection strings. You will need the device ID and a copy of the primary connection string for insertion into your ESP32 sketch. Now onto the ESP32.

ESP32 Software


You can download a copy of my ESP32 sketch from the Reefwing Gist.  You will need to fill in your SSID, password and primary connection string where indicated.



I spent quite a bit of time trying different tool chains to get everything configured and talking. My initial preference was to use Eclipse with the Arduino tool chain. This would give me a proper IDE and a remote control library that I knew was compatible with all the Arduino's out there.

Unfortunately, importing custom libraries is a bit problematic for the two Eclipse Arduino plug-ins available. It is theoretically possible but I ran out of patience trying to get it to work. The ESP-IDF has its own remote control library but it is not as well documented as the Arduino library. I'm also not familiar with coding the ESP32's natively.



While looking for a way to receive the messages sent from the ESP32 to the cloud I discovered a plug in for Visual Studio Code. It so happens that there is also a plug in for Arduino. Since I was already using this to monitor my IoT hub traffic, I decided to give it a crack with programming the ESP32. It just worked - I was astonished! It does use the Arduino IDE tool chain, so that may be why it was so seamless as I had already got everything working with that first. If IntelliSense complains about a missing library, right click on the light build and edit the c_cpp_properties.json file which contains the include path.




The other thing you will probably have to do is add:

"output": "../build",

To the .vscode/arduino.json file, which can be found under the work space for your sketch. The same location as the c_cpp_properties.json file.  If output is not set, Arduino will create a new temporary output folder each time it compiles your sketch, which means it cannot reuse the intermediate result of the previous build, leading to long verify/upload time. So it is recommended to set the field. Arduino requires that the output path should not be the workspace itself or subfolder of the workspace, otherwise, it may not work correctly. By default, this option is not set. Again, no idea why, you will get a warning if it isn't set when you verify.



Whether you use the Arduino IDE or Visual Studio Code, you need to download the Azure IoT library: ESP32_AzureIoT - An Azure IoT Hub library for ESP32 devices in Arduino.  Unzip and copy this to your Arduino libraries folder.

As a first test, load the GetStarted.ino sketch from the examples folder in the library you just downloaded. This sketch will connect to the IoT hub and continuously send messages containing fake data. You will need to fill in the following blanks in the sketch:

  • DEVICE_ID - copy from your IoT registered device;
  • connectionString - copy from the primary connection string;
  • ssid - the displayed name for your WiFi network; and
  • password - for your WiFi network.

Connect to your ESP32, check the port and board type, then compile and upload the sketch. Open up the serial monitor at 115,200 baud so that you can see what is happening. The monitor should be displaying something like the following.


To confirm that the IoT hub is receiving these messages have a look at the Azure dashboard and you should see these messages arriving.


If you have Visual Studio Code, you can use the Azure IoT extension to monitor messages to your IoT hub. Just select your device and then right click and Start monitoring D2C (Device to Cloud) message. You can also send messages from the cloud to your device from here.


Once this was working, I updated the code to just send a heart beat message back to the cloud, letting us know that it was still alive. Every time the ESP32 does this, it broadcasts an IR remote control code three times. This is the usual methodology for remote controls. Currently it is just broadcasting the Sony power code, but we will look at ways we can start/stop the broadcast and change the code via Azure.

Cloud to Device Message Lifecycle




To guarantee at-least-once message delivery, IoT Hub persists cloud-to-device messages in per-device queues. Devices must explicitly acknowledge completion for IoT Hub to remove them from the queue. This approach guarantees resiliency against connectivity and device failures.

When the IoT Hub service sends a message to a device, the service sets the message state to Enqueued. When a device wants to receive a message, IoT Hub locks the message (by setting the state to Invisible), which allows other threads on the device to start receiving other messages. When a device thread completes the processing of a message, it notifies IoT Hub by completing the message. IoT Hub then sets the state to Completed.

The max delivery count property on IoT Hub determines the maximum number of times a message can transition between the Enqueued and Invisible states. After that number of transitions, IoT Hub sets the state of the message to Dead lettered.

The diagram above shows the lifecycle state graph for a cloud-to-device message in IoT Hub. Luckily, sending messages is a lot more straight forward than implementing the message lifecycle.

Controlling the ESP32 via Azure


Now that we have our ESP32 talking to Azure and broadcasting an IR code burst every 10 seconds we want to be able to control this via the cloud. The easiest way to do this is using Visual Studio Code again.


If you right click on the device, shown in Explorer under Azure IOT HUB DEVICES, then the window above is displayed. The two ways we will look at communicating with our device via the cloud is:

  1. Cloud to Device (C2D) Messaging; and
  2. Triggering a defined device method.
You can try out both.

Cloud to Device Messaging


After uploading the sketch to your ESP32, open the serial monitor from the Arduino IDE. I found the serial monitor function in Visual Studio Code was a bit dodgy. Select Send C2D (Cloud to Device) Message to Device, and a message entry window will open. Type in whatever you want and hit return.

In the Azure IoT Toolkit output window you should see:

[C2DMessage] Sending message to [ESP32_IRBeacon_1] ...
[C2DMessage] [Success] Message sent to [ESP32_IRBeacon_1]

A second or so later, the following will appear in the Serial Monitor:

Info: >>>Received Message [1], Size=14 Message test message
Message callback:
test message

The function which handles message handling in the ESP32 code is MessageCallback(const char* payLoad, int size). The call back function is set during setup() using:

Esp32MQTTClient_SetMessageCallback(MessageCallback);


Invoke a Direct Method


This is the way that I chose to control the IR beacon (since that is its purpose). You can define what methods you want to support in your code. Currently we are only handling start and stop but it would be trivial to add another method to set the IR code transmitted.

The process for invoking a method is the same as for sending a C2D message. Right click on your device in Explorer and select "Invoke Direct Method". A text entry window will open, type in your method name (e.g. stop) and hit enter. In the Azure IoT Toolkit output window you should see:

[DirectMethod] Invokeing Direct Method [stop] to [ESP32_IRBeacon_1] ...
[DirectMethod] Invokeing Direct Method [start] to [ESP32_IRBeacon_1] ...

Yes whoever wrote this code couldn't spell invoking! Then in the Serial monitor:

Info: Try to invoke method stop
Info: Stop sending IR burst and heart beat

The function which handles method handling in the ESP32 code is DeviceMethodCallback(). This call back function is set during setup() using:

Esp32MQTTClient_SetDeviceMethodCallback(DeviceMethodCallback);


Conclusion




If all you want is a dashboard for your IoT application then Node-Red is MUCH simpler to implement. If you need an industrial strength solution then you need something like Azure IoT hub.

Actually, using Visual Studio Code (VSC) was a pleasure, and this will be my go to IDE for Arduino from now on. Controlling and Monitoring your IoT devices via VSC was also very easy once you work out how it operates. The user interface is not very discoverable, you need to hit F1 to access most of the Arduino and Azure commands.

I will publish a short follow up article providing a simple PCB to mount the diagnostic LED's, IR transmitting module and the ARM/DEBUG switch. It is a simple enough circuit that you could do it on a breadboard or veroboard. Note that the Duinotech ESP32 doesn't leave any pins free on one side of a standard breadboard, due to its width. See the photo above. This is one reason I decided to use a PCB.


Tuesday, November 7, 2017

Salae Logic & Protocol Analyzer 8 - Review and Tutorial

Overview




My latest acquisition is the Salae Logic Analyzer. I was very tempted to get the top of the line model, the Logic Pro 16, but decided I might as well see how useful it was before splashing out that much more cash. A reasonable compromise seemed to be the Logic 8 model.

What is a Logic / Protocol Analyzer?


A logic analyzer is an instrument that captures and displays multiple signals from a digital system or digital circuit. They are used for testing or debugging digital or logic circuits. The device
connects to a PC over USB and uses the Saleae Logic Software to record and view digital and
analog signals.  It operates by sampling a digital input connected to a device under test
(DUT) at a high sample rate. These samples are recorded to a sample buffer, and at the end of the
capture, the buffer is displayed in the software for review.

The following from the Logic 8 data sheet, explains where you would mostly use the device.

Logic analyzers are great for debugging embedded applications. In the most common case, a developer working on firmware for a microcontroller will write code to communicate with another component, possibly using protocols like serial, I2C, or SPI. To verify the functionality or
to diagnose errors in the firmware, a logic analyzer is connected to the digital IO used for
communication and records the activity during testing. The recording is then shown on the display
so the user can view the actual behavior of the firmware, and compare that with the expected
behavior to narrow down and identity the source of the issue – or verify that the operation is
correct.

Many oscilloscopes can perform a similar function, the advantage of the logic analyzer is that it can simultaneously display multiple signals (8 in my case) and relative timing information. The following from Radio Electronics, provides a good summary of the difference between a Logic Analyzer and an Oscilloscope.

  • Provide a time display of logic states:   Logic analysers possess a horizontal time axis and a vertical axis to indicate a logic high or low states. In this way a picture of the digital lines can be easily displayed.
  • Multiple channels:   Logic analyzers are designed to monitor a large number of digital lines. As logic analyzers are optimised for monitoring a large number of digital circuits, typically they may have anywhere between about 32 and 200+ channels they can monitor, each channel monitoring one digital line. However some specialised logic analyzers are suitably scaled to be able to handle many more lines, and in this way enable tracking and fault finding on much more complex systems.
  • Displays logic states:   The vertical display on the analyser displays the logic state as a high of low state. The signals enter the various channels and are converted into a high or low state for further processing within the analyser. It provides a logic timing diagram of the various lines being monitored.

Most Logic Analyzers don't allow you to analyse analogue data. The Logic 8 allows any of the 8 channels to be used for either analogue or digital analysis. The device expects an input voltage range of 0 to 5V but can handle a maximum of -25 to +25V. This is perfect for the Arduino and Raspberry Pi.

Note however  that although the device wont blow up if you connect 25V, the analog input on Logic 4 and Logic 8 is limited to +0V to +5V, and will saturate (take on minimum or maximum value) outside of this range. Logic Pro 8 and Logic Pro 16 have an analog input limited to -10V to +10V, and will saturate outside of that range. So probably not so good for working with RS 232.

Protocol Analyzers decode data that has been encoded according to a particular protocol, such as SPI or I2C. The Logic software currently offers 23 different protocol analyzers. Each protocol analyzer needs to be set up to tell it what channels to use for what (e.g. SDA = channel 0, SDC = channel 1 for I2C).

Setting Up


Getting the unit working is pretty straight forward. Start by downloading the software from Salae. Then connect the unit via the USB port. One minor irritation is that you have to connect the test clips to the wire harness yourself.


This is just a matter of pushing the lead into the test clip but it requires quite a bit of pressure or it will just fall off again. I used long nose pliers to ensure that the leads stayed put.

Bandwidth vs Sample Rate


In order to accurately record a signal, the sample rate must be sufficiently higher in order to preserve
the information in the signal, as detailed in the Nyquist–Shannon sampling theorem. Digital signals must be sampled at least four times faster than the highest frequency component in the signal.

Analog signals need to be sampled ten times faster than the fastest frequency component in the signal.

Active Channels vs Maximum Sample Rate


The maximum sample rates for digital and analog recordings is limited by the available USB bandwidth.

Because of this, sampling at the maximum rate is not possible on all channels at once. Some example sample rate combinations:

  • 3 channels, digital only, 100 MSPS
  • 2 channels, analog only, 10 MSPS
  • 8 channels, digital only, 25 MSPS
  • 8 channels, analog only, 2.5 MSPS

Using the Logic Analyzer


The big question is what can I do with this kit and is it useful? To answer this question, I will use the Logic Analyzer in a few typical scenarios and see how it goes.

Test 1 - PWM

As a first test I will look at Pulse Width Modulation (PWM) on the Arduino. Actually I will use the STEMTera breadboard for this test, it is an Arduino built into a breadboard and is handy for prototyping and testing.



I've connected an LED across pin 9 and GND, with an appropriate current limiting resistor. The simple sketch below should produce a square wave on pin 9 with a frequency of 500Hz and a 50% duty cycle.

// PWM demo to test Salae Logic 8
// 
// Arduino's PWM frequency is about 500Hz.
// A call to analogWrite() is on a scale of 0 - 255, such that analogWrite(255) 
// requests a 100% duty cycle (always on), and analogWrite(127) is a 50% duty cycle 
// (on half the time).

#define LED9    9

void setup() 
{
  pinMode(LED9, OUTPUT);
  analogWrite(LED9, 127);
}

void loop() 
{
  
}
Using channel 0 on the Logic 8 produces the following when I connect the probes across the LED.


As expected, we get a square wave with a period of 2 ms (1 / 500 Hz = 2 ms) and a 50% duty cycle. As a further check, I changed analogWrite(LED9, 64) to get a 25% duty cycle, and captured:


So for checking PWM duty cycle, this is a handy tool. The other thing that actually measuring the waveforms is good for is to test your assumptions. Initially, I was expecting the square wave to go from 0 - 5V, and if you disconnect the LED and measure from pin 9 to ground that is exactly what you get. However, with the LED in place and with our probes across the LED, the square wave goes from zero to approximately 2V. This is of course the characteristic forward voltage drop across the LED. To check this, I stuck the LED in the LCR tester which measured a Vf = 1.69V.



Test 2 - SPI

Next I will try out an application which uses the SPI protocol. This will test out the functionality of the protocol analyser and is something that you couldn't do as easily on a 2 channel DSO (since we are looking at 3 channels - DIN, CS and CLK).

We will use the Duinotech 8x8 LED Dot Matrix module described in a previous post. This communicates with an Arduino using SPI via the MAX7219 chip.

The Serial Peripheral Interface bus (SPI) is a synchronous serial communication interface specification used for short distance communication, primarily in embedded systems. The interface was developed by Motorola in the late 1980s and has become a de facto standard. Typical applications include Secure Digital cards and liquid crystal displays [Wikipedia].

The SPI bus specifies the following logic signals:

CLK: Serial Clock (output from master).
DIN: Master Output Slave Input, or Master Out Slave In (data output from master).
CS: Slave Select (often active low, output from master).
MISO: Master Input Slave Output, or Master In Slave Out (data output from slave) - not used in our application.

In our example, the Arduino is the Master and the LED Module is the Slave. As we are only connecting using 3 wires, communication is one way, from the Master to the Slave.

To begin communication, the master selects the slave device with a logic level 0 on the select line (CS). During each SPI clock cycle, a full duplex data transmission occurs. The master sends a bit on the DIN line and the slave reads it. For a 4 wire application the slave sends a bit on the MISO line at the same time and the master reads it. This sequence is maintained even when only one-directional data transfer is intended.

As described in our post on the 8x8 Led Matrix Module, we are controlling the module using the LedControl Arduino library. The first thing that we noticed when hooking up the Logic / Protocol Analyzer was that the clock speed appeared to be too slow. As expected, the CS line went low to kick things off.

The hardware SPI CLK on the Arduino is usually running at between 25kHz to 8MHz with a default of 4MHz. As shown in the screen capture below, we are measuring a clock frequency of about 64kHz.


This made me investigate the LedControl library in more detail. It turns out that the Library doesn't use the hardware SPI but emulates the SPI protocol using bit banging. In retrospect this is obvious since you can assign any digital input to the DIN, CS and CLK functions. Using hardware SPI these pins are set (see table 1).

A quick look at the LedControl source code shows that it is using the Arduino shiftOut() function to do most of the control of the logic lines. The syntax of the command is:

shiftOut(dataPin, clockPin, bitOrder, value)

It shifts out a byte of data one bit at a time. Starts from either the most (i.e. the leftmost) or least (rightmost) significant bit - MSB first for LedControl. Each bit is written in turn to a data pin, after which a clock pin is pulsed (taken high, then low) to indicate that the bit is available. So the clock speed will not necessarily be consistent, the pin transition happens when the data is ready - also not what I was expecting.

If you want to, you could trace every byte being transmitted to the LED module. For example the first byte of the "smile" image is 0x3C, you can see this being sent on the MOSI line in the screen shot below. The logic analyzer software allows you to search the decoded protocols which makes it easier to find a particular byte.



Arduino / Genuino BoardMOSIMISOSCKSS (slave)SS (master)
Uno or Duemilanove11 or ICSP-412 or ICSP-113 or ICSP-310-
Mega1280 Mega256051 or ICSP-450 or ICSP-152 or ICSP-353-
LeonardoICSP-4ICSP-1ICSP-3--
DueICSP-4ICSP-1ICSP-3-4, 10, 52
ZeroICSP-4ICSP-1ICSP-3--
10111 or ICSP-412 or ICSP-113 or ICSP-31010
MKR10008109--
Table 1. Arduino H/W SPI Pins

Conclusion


The question at the start was what can we do with a Logic / Protocol Analyser and is it useful? I have tested a couple of examples and based on this I think it will be very useful. If something is not working as expected, it may be because your assumptions were wrong. This was demonstrated very clearly above and I will be measuring my designs a lot more to ensure that the designs are doing what they should be.

Of course it also demonstrates that you don't need to understand how SPI works, to get an Arduino to talk with an 8x8 LED Module.

APPENDIX - Key Specifications - Salae Logic 8


  • Eight Digital Channels
  • 100 MSPS Digital Sampling (max)
  • 25 MHz Max Digital Bandwidth
  • Eight Analog Channels
  • 10 MSPS Analog Sampling (max)
  • 1 MHz Analog Bandwidth
  • Recording Length Limited by Available RAM and Density of Recorded Data
  • RGB LED, Customizable 24 bit Color


APPENDIX - Electrical Characteristics