HIL Test-Device Candidates

Owned by Aryan Kashem
Dec 16, 2024
3 min read

2 main candidates for HIL interface boards. Likely going with RPI4, prototyping can be done on a breadboard with a logic analyzer.

Binho Pulsar https://binho.io/products/binho-pulsar

image-20241216-011252.png

As of 15/12/2024
Key Features

  • USB High Speed 480Mbps Connection to Host PC

  • Support for SPI protocol

    • SPI Controller

    • All 4 SPI Modes Supported

    • Up to 50 MHz max clock speed

    • Up to 4 x CS signals

    • Configurable MSB/LSB

    • SPI Peripheral (coming soon)

    • Voltage range from 1.2V to 3.3V

  • Support for I2C protocol

    • I2C Controller

    • 1 MHz max clock speed

    • 7-bit Addressing, Clock Stretching

    • Configurable Pull-up Resistors

    • 10-bit Addressing (coming soon)

    • I2C Peripheral (coming soon)

    • Voltage range from 1.2V to 3.3V

  • Support for UART protocol

    • 115200 max baud

    • Support for Hardware Flow Control

    • Voltage range from 1.2V to 3.3V

  • Support for RS-485

    • -7V to +12V Common-Mode Input

    • Half-Duplex

  • Support for CAN-FD Protocol (coming soon)

    • Optimized for use in 12V systems

    • Up to 5 Mbps data rate

  • Support for 1-Wire Protocol (coming soon)

    • Standard and Overdrive speeds

    • 3.3V and 5V operation

  • GPIO pins

    • 6 x Digital IO pins

    • Voltage range from 1.2V to 3.3V

    • Configurable as Interrupts

    • PWM Support (coming soon)

  • Provides downstream power to DUT

    • Programmable from 1.2V to 3.3V

  • Robust Machined Aluminum Enclosure

    • 5 x RGB Status LEDS

    • Integrated mounting holes

    • Silent, Fanless design

  • All cables and accessories included

    • Stored in custom zippered case

  • Full-featured Software Support

    • Point-and-Click GUI

    • Cross-Platform:  Windows, Mac, Linux

    • Python, C/C#/C++ SDKs

    • Field-Upgradeable Device Firmware

Pros

  • Plans to support CAN, I2C-Slave, and SPI-Slave and already supports UART and GPIO (even plans PWM)

  • Python scripting is easy (I have made an automation test package for this at work).

  • Configurable voltage levels that will allow us to mock ADCs (1.8V → 3.3V logic levels)

Cons

  • Not an established product, I have only used it through work. It has been very good.

  • Expensive $500

  • It has been a while since they updated the product (the last update I recall was October 2024). I have emailed and not gotten a reply for a month now, unsure of the company’s state.

  • Only has 1 SPI and 1 I2C port. We need at least 2 considering BMS requires 2 SPI interfaces now.

  • Does not have enough GPIOs; it only has 8.

Hardware Design for Pulsar:

  • Use the included 30-pin breakout to connect to the controller board.

  • Must figure out multiplexing; maybe we can use the different voltage levels. Or we can buy 2 pulsars but that would be close to $1000

Raspberry Pi 4/5 (Preferred)

image-20241216-011435.png

Pros

  • Easy to use, Linux kernel. Can easily be integrated into the CI/CD pipeline

  • Supports CAN dongle USB connection

  • Has HDMI to maybe display test status?

  • Hardware design is fairly simple; it will be an RPI hat which is very modular.

  • We can use Python scripting.

  • Cheap + We have so many; in fact, we could hook up 2 RPI4s if we don’t have enough pins.

Cons

  • Does not support slave mode I2C/SPI, so we cannot mock sensors (easily).

    • This is very crucial for operation, the only reason we aren’t going with this

    • The workaround is bit-banging everything.

      • Feasibility must be tested, but it is probably very doable lol

  • Does not support DACs; would require an external one controlled by maybe the master I2C interface.

  • Might not have enough GPIO for everything if we end up reserving 2 SPI ports and 2 I2C port (worst-case scenario trying to mock BMS)

Hardware Design for RPI:

  • RPI Hat that will hold the controller board

  • The hat will have DAC ICs that can be controlled from the RPI via master I2C/SPI

  • The hat must break every pin out. Consider the following picture of the PRI pins:

     

DESIGN IMPROVEMENTS/THOUGHTS

  1. Maybe we can use another device with the RPI? This could solve the need for a DAC, and running out of GPIO pins. Thoughts for other boards:

    1. RESEARCH THIS LATER