Development of a commercial electronic device from scratch

Greetings!

I want to share my own experience in developing an electronic device. First, I’ll tell you a little background so that it is clear why I needed this, in fact.

How it all started


Initially, we were engaged in the development of software for chip tuning. One of the main tasks of which is to read the firmware from the computer (electronic engine control unit) and write it back. It is clear that for these purposes you need to somehow connect the computer and the computer using the adapter. When before the vast majority of ECUs used the simplest method of receiving and transmitting data, it was enough to use the simplest adapter on transistors or a specialized chip. However, today most cars use the CAN bus to “communicate” their components with the environment. You can’t assemble the adapter for the CAN bus on transistors, and here you definitely need a processor that will control everything according to a specific program.
So the first problem arose - how to overcome the CAN bus. In order not to reinvent the wheel, the choice was made on the use of a ready-made adapter that works according to the J2534 standard. For those who are not in the know, the J2534 standard is a standard that describes the hardware and software parts of the device, with which you can connect to the computer using a computer. It was developed by the Americans. The main reason for its development was the legislative consolidation of the possibility of updating the ECU firmware not by a specialized dealer service, but by anyone who wishes. Actually, if everyone can update the firmware on his phone, then why can't he do it with his car.

The most affordable imported counterpart costs around $ 200. As it later turned out, two identical devices that meet the J2534 standard can work differently with the same software. Therefore, initially I had to get attached to a specific manufacturer and its device.

The experiments


Those functions that we needed in the hardware were present in the common adapter for diagnosing ELM327. It remains only to write the J2534 driver (in fact, this is a DLL, which serves as a layer between the program on the computer and the device itself). Preliminarily contacted the developers of ELM327, however, they reported that they had no plans to write such a driver, however, they were ready to provide free flashed chips for ELM327. Previously, I wrote such a driver that supported only the ISO 11898 protocol (raw CAN). However, disappointment awaited me here. At a CAN speed of 1 Mb / s, the ELM327 simply does not manage to receive such a large number of packets, constantly knocking out an error overflowing the internal message buffer. Moreover, The exchange protocol between the computer and ELM327 is organized as an ASCII message exchange (so that it is convenient to work in the terminal). Accordingly, instead of transmitting one byte of data, three are transmitted (two bytes - character mapping plus a separating space). It turned out that most of the USB traffic was wasted. And considering that the maximum speed of working with ELM327 via USB is 3 Mb / s, it is not possible to accept 1 Mb / s via CAN bus with such an exchange organization.

I never liked to depend on anyone, therefore, the idea of ​​creating my own J2534 adapter did not leave me.

First steps


It should be said here that before developing my J2534 adapter I did not have any development experience using a processor, but I had a lot of programming experience. Initially, there were attempts to find artists who could create such a “turnkey” device, but they were unsuccessful. Therefore, it was decided to start doing this on their own. First of all, it was necessary to decide on the processor. The choice fell on the ARM processor from ST - STM32F105. The criteria for choosing a processor were prevalence, price, and the presence of third-party specialists who would help solve the problems as soon as possible. As a breadboard, a breadboard from Olimex was purchased. With its help, "laboratory work" was successfully completed for the development of the processor: flashing LED, beeping sound, display on the LCD screen, working with UART.



Loved the CooCox IDE. There were also samples with Keil, but as they say - “it didn’t go”.

The working process


As I wrote above, there were attempts to find artists who will do everything on a turnkey basis, but they were unsuccessful. I did not want to stretch the development for a long time and understand everything myself. Therefore, it was decided to divide the task into independent parts, and some of them should be entrusted to developers who had experience in such things. Such a developer was found using the freelance exchange. Actually, the freelancer was required to create a program that controls the processor. The rest of the work related to the development of the final circuit, a printed circuit board and an order for production was already to be entrusted to someone. For those who follow my path, I’ll say that the freelancer in this whole process is not a panacea, and after that I’ll still have to optimize the code so that this code does not just work, but is quality and extensible.

The contractor immediately suggested that I use RTOS in this project instead of the standard library from STM32. Honestly, I was puzzled. I never dealt with RTOS, and my companion was categorically against using RTOS for this project. In the end, I still agreed to use RTOS and later did not regret it.



At first, there were no particular problems and separate “bricks” were made safely, which are responsible for exchanging between the adapter and the computer via USB, working with UART, developing their own bootloader, with which you can update the firmware of the device via USB.

Problems started with CAN. The standard drivers for working with CAN ChibiOS (it was on this RTOS that I stopped) use the processor hardware slots to store received messages. There are only three of them, therefore, if you do not have time to choose messages from there, they will simply be lost. And so it happened. While the messages went "slowly" - they were safely received, but as soon as the number of CAN messages per second exceeded thousands - problems began. “Overclocking” or optimizing the reception on the standard driver did not work, so it was decided to completely rewrite it. Those. make a software CAN message buffer instead of a hardware one. The size of such a software buffer was 256 CAN messages, and this turned out to be quite enough.

I had to deal with the writing of this driver myself, because the contractor did not have the technical ability to generate an avalanche-like stream from CAN packets, and there was no desire to search for a new artist and re-enter him in the course of things. But all that is not being done is being done for the better, and thanks to the independent development of the driver for ChibiOS, it was possible to immerse ourselves in its study. After that, it was decided to do a number of parts of the project on their own, without involving a third-party contractor.

Part of the time was spent studying the protocols ISO 15765-4 (CAN), ISO 9141-2. I must say that real ECUs helped to quickly deal with them - it was enough to “listen” to the ECU exchange.

First sample


The first model of the device existed in the form of a breadboard with STM32F105 and a breadboard with interface L9637D and TJA1050. This is what the first laboratory sample looked like.



And so on the other hand:



In the laboratory, on the given test programs, everything worked perfectly. However, before creating the board already for mass production, it was decided to make test non-commercial samples, which will be distributed to people who are ready to take part in testing. Initially, they wanted to make boards using LUT, but later they ordered 10 boards at the factory.

Such testing certainly paid off. Not even so many bugs were found in the firmware of the device itself, but how much it was necessary to adapt the device to programs of various manufacturers that use the device as an adapter J2534.

Final stages


Based on the test results, a decision was already made to create a board that will go into series. The final circuit of the device was made by my companion, the wiring was entrusted to a third-party contractor. The devices were not initially saved on the circuit diagram - everything that could be protected and made as fault-tolerant as possible was done.

A separate topic can highlight the case of the device. This is a topic for a separate topic. Therefore, I will say that at the moment I settled on the factory manufacturing of an acrylic case, and we are planning to complete our devices with this case the other day.



Initially, we delivered the device in a covered transparent cambric, and the board itself was varnished.

Summary


Let me give you a little chronology so that you can understand what it was worth.

  1. March 2013 - first acquaintance with STM32
  2. June 2013 - start of work
  3. October 2013 - the first test sample
  4. January 2014 - official sales launch


It should also be said that this is not the only project that was done within this time frame.

What was used to create the project:

  1. RTOS ChibiOS
  2. Sublime text2
  3. GCC (CodeSourcery)


Auxiliary iron for creating a project:

  1. CAN Hacker
  2. Saleae Logic Analyzers
  3. USB-UART converter


As a result, we got a J2534 device that supports the following list of protocols:

Support for the following protocols:

  1. ISO 11898 (raw CAN) up to 1Mb / s
  2. ISO 15765-4 (CAN)
  3. ISO 14230-4 (Keyword Protocol 2000)
  4. ISO 9141-2




Due to the fact that a number of functions described in the J2534 standard are not used in the programs with which it was planned to use the device, it was decided to exclude them. In particular, it supports J1850 protocols (PWM / VPW). Perhaps when there is time, I will pull these protocols into the device to get 100% coverage of the J2534 protocol.

Also popular now: