Hands-on review Synergy S7 starter kit – First look
Embedded software developers face many challenges in their efforts to develop robust, internet-connected devices within budget- and time-constrained environments. The recently released Renesas Synergy S7 starter kit specifically targets helping developers accelerate, innovate, and differentiate their internet-connected embedded systems. With the buzz around the release of the Synergy platform, I had to try it out for myself to see if the platform could live up to the expectations or if it was nothing more than marketing smoke.
Before diving into my first impressions, let’s examine the kit. The Renesas Synergy S7 starter kit is based on an ARM Cortex-M4 processor with a Floating Point Unit (FPU) and the ability to process DSP instructions. The microcontroller is quite impressive, clocking in at up to 240 MHz with as much as 4 MB of flash code space and 640 KB of onboard SRAM. The S7 also has a plethora of on-board connectivity peripherals ranging from the typical serial communication interfaces (SCI), serial peripheral interface (SPI), and I2C bus up through advanced peripherals such as controller area network (CAN), USB high speed, and Ethernet.
This is not the typical, low cost development kit that many developers have gotten used to over the past several years. The basic S7 starter kit costs approximately $84 dollars, far above the under $30 development kits many of us are used to. But as with anything in life, you get what you pay for.
The S7 starter kit comes with fully populated expansion headers and microcontroller headers, including an Arduino compatible expansion header. The kit also includes expansion devices that would make nearly any engineer happy. The on-board color QVGA allows for graphical user interface development while the onboard Ethernet allows developers to get a jump start on connecting the development kit to a network. The development kit also includes an onboard Bluetooth Low Energy (BLE) device, a resistive touch layer, and a touch slider. The final piece of the puzzle is a SEGGER J-Link for programming and debugging the S7 microcontroller.
Setting up the development environment for the S7 is relatively straight forward. The Renesas e2 studio is the primary development environment and is based on Eclipse. which made installing and getting a workspace and project setup pretty run-of-mill. The caveat to the setup was the need to download and install the Synergy Software Package (SSP). The SSP contains much of the jump-starting software that can get a developer up and running quickly. For example, the SSP includes the ThreadX RTOS, Hardware Abstraction Layer (HAL), Board Support Packages (BSP), and application framework among other things. The SSP is provided free of charge for prototyping and development but requires a production license. That license presumably has some sort of royalty or yearly renewal process, but those details so far have been immune to my efforts at discovery.
Once the development environment is set up, a great first step with any development kit is to create and test an LED blink program. Testing of an LED, while elementary, provides verification that the development environment is well understood, the hardware can be controlled, and (most importantly) the development kit can be programmed. The e2 studio project creation wizard provides a LED blinky project that it can automatically generate for the S7 development kit, saving a developer from having to dig too deep into microcontroller documentation. With the press of a single button the initialization and HAL creation is all done behind the scenes, without any need for the developer to think much about it.
Unfortunately, my blinky LED program initially did not want to cooperate. The program generated and built perfectly well, but it refused to successfully communicate with my development kit. Now, I did have the toolchain installed on a virtual machine running on my Macbook Pro, which could have something to do with the connection issue. But after some investigation, some setting tweaks, and the like, I was still unable to get the development kit to communicate. There may still be a setting that I overlooked but for now the only way for me to really test the toolchain and development kit was to install it on a machine natively running Windows. After repeating the installation process and creating a new blinky project, I was able to compile and load the auto-generated blinky program without any issues.
The next step was to download some examples on how to use the USB. The Renesas Gallery, a repository for application code, tools and 3rd party components, contained a USBX-Mass Storage Device project example for the S7 kit. This appeared to be a perfect way to test provided example code. After downloading the USBX-Mass Storage Device project, though, I was surprised to discover that the project didn’t contain any large amount of source code. Instead, the project consisted of an xml file that contained the component dependencies and a linker file.
Importing the project into e2 I discovered that the code generator uses the xml file to generate all of the project's source. Pretty cool! With this approach, transferring projects around between developers or delivering them to an end client becomes nothing more than providing non-SSP code and the configuration xml file, at least in theory.
As it turned out, though, after generating the USB project there were over 25 warnings and a few errors. Yikes!
A close examination of the associated documentation (Yes, mark it on a calendar -- I read the directions) revealed that this result was expected. Importing projects requires a developer to update project paths in addition to ensuring that the SSP license was in the correct path. Once these two updates were completed. the project compiled and USB was up and running!
My first impressions so far of the Synergy S7 development kit have thus been quite good. The development environment was easy to set up and would be familiar to many developers. Creating a test project was simple and even included advanced options for including and configuring ThreadX RTOS. There were a few bumps along the way, but in all honesty they undoubtedly were due to a configuration setting.
My exploration of the S7 has only begun. Many questions remain, such as how well written is the underlying code? Has the code been checked against static code analyzers? Are the API and HAL clean and easy to remember and use? Perhaps most importantly, can a platform such as Synergy really save time and cost to market or are developers simply making yet another trade-off in the development cycle? These are just a few of the questions that I hope to investigate over the coming months.
What are your questions?
Jacob Beningo is principal consultant at Beningo Engineering, an embedded software consulting company. Jacob has experience developing, reviewing and critiquing drivers, frameworks and application code for companies requiring robust and scalable firmware. Jacob is actively involved in improving the general understanding of embedded software development through workshops, webinars and blogging. Feel free to contact him at firstname.lastname@example.org, at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter here.