Multi-tool for electronics developer

The company where I work is developing several things in parallel, so very often the necessary equipment is busy, and I really want to test my hardware. In this case, I assembled a temporary test stand on a breadboard from loose parts and modules, but I didn’t like their appearance and limited functionality. Over time, I noticed that I often needed the same thing, so I decided to design a device for myself that would contain the most necessary things, allowing me to test my developments. This will free me from being tied to several devices and free up space on my desktop.

The idea is simple – to replace frequency generators, RS-485 and CAN terminals with one self-sufficient device, a kind of multi-tool for a developer. In this article I will tell you about the device I assembled.

Previous versions

The very first version was a breadboard with two 555 timers that controlled transistors (to power/to ground). I used this board periodically for half a year until it broke. Jumpers and variable resistors (a constant one is shown on the diagram) allowed changing the PWM frequency. The board did its job, but it was a temporary solution. This board simulated a signal from a generator and a Hall sensor. There are ready-made similar modules, but they did not suit me in terms of frequency range.

The second attempt was based on bluepill (STM32F103), contained three transistors, a relay and RS-485. The presence of a microcontroller allowed to precisely set the parameters of the PWM operation and conduct polls via RS-485, but to change the parameters it was necessary to rewrite the code, and this is not convenient.

The third version is in many ways close to the last one. It has a touch screen for control, a plastic case, a printed circuit board and most of the pins that I needed. However, the squareness of the fake, the electronics on the outside and the inconvenient location of the terminals prompted further research.

Technical task

Based on the desired functionality and the shortcomings of previous attempts, I wrote down all my wishes, which I will implement in the next device:

• Two PWM with voltage up to 24 V, up to 10 kHz. Power will be supplied from external sources. I usually use these pins to check the operation of counters, frequency capture mechanisms, etc.

• Two PWM with pull-up to ground (imitation of limit switches, Hall sensors), up to 10 kHz

• Availability of RS-485. A simple terminal must be implemented that allows sending and receiving a message at a given speed.

• Similar for CAN

• Ability to easily adjust PWM parameters

• Tablet form factor, touch display.

Definition of design

After scratching my head and drinking a liter of tea, I started selecting components. For control, I decided to use a 7-inch DWIN touchscreen display (specifically DMG80480C070_04WTC). The reason for the choice is the ease of use: the firmware is assembled in a special program from the manufacturer, communication with the microcontroller occurs via UART. Minimum time spent on obtaining the result.

As transistors, I decided to use smart keys from Infineon (BSP76E6433HUMA1 and BTS462T). They have a built-in control and protection driver. I have already successfully worked with keys from this series in another project and I liked them. The only nuance is that a minimum load is needed, you will not be able to simply connect the output to an oscilloscope and see what PWM frequency.

I didn't have to think long about the microcontroller either. Last year I tried the STM32G0 series, which I really liked, so I decided to use a bigger stone in this device – STM32G4. I've long wanted to get acquainted with this family and the pet project is perfect for this.

The device will operate from a 12V power supply (LP-340). I often use these in my stationary projects.

Case for 3D printing.

Design of printed circuit board

Let's take a closer look at the board's contents:

The power converter based on SCM1301ATA from MORNSUN reduces the input 12V to 5V, which goes to the display. Then 5V is converted to 3.3V using LDO (LDK130M33R). There is a self-restoring fuse at the power input.

Communication interfaces are represented by ADM3485EARZ and MCP2551T-I/SN microcircuits. Protective diodes and terminal resistors are added to them.

I took the microcontroller binding from “Getting started with STM32G4 Series”. I hung the BOOT pin on pls, the functionality of which I did not use in the end. Now it is simply pulled up to GND.

The display is connected to the microcontroller via a 3.3V – 5V level matcher based on 2x nmosfet and several resistors. Most likely, it was possible to do without them, but I decided to play it safe.

Two keys for power and the same number for ground. 4 banana pins on the case for the PWM output and 2 more (marked IN) for the power supply input.

The diagram has a connector for blinking LEDs in case of active transmission via CAN and RS485, but they are almost invisible, since everything happens too quickly, so I stopped using this part.

The board turned out to be 60×50 mm in size, which is quite large for such a small number of components. The dimensions are mainly determined by the connectors on three sides. It was planned that one side of the board with terminal blocks would be accessible for connection from the outside of the device, and the others would be used for internal connections (display, banana pins and LED indication).

Frame

What I spent the most time on was the case. I made it using the fdm 3d printing method. My printers were the trusted Ender 3 Pro, on which I printed the nameplates, and the Creality K1, on which I printed all the main elements of the case.

Initially I wanted to print the case from ABS, then sand and paint it, but small elongated elements were difficult to obtain. PLA turned out better than ABS or PETG, so I decided to use it (PLA FDplast).

The case consists of two halves – a thin front part with a display and a massive back part to which everything else is attached. The elements of the case are connected using screws and fused nuts. The case has many grooves for gluing nameplates into them, which I will talk about below.

I've always printed rectangular boxes before, and the first versions of this device were like that, but the right angles are awkward to hold and the device itself looked like it was cut with an axe, so I added some rounding. Now it has a lot of smoothing and angled surfaces, which is not very good for a printed part, as it complicates the manufacturing process. I printed the panels face up, so that all the curves of the surfaces were unsupported, sacrificing quality inside. In order to hide the layering of the model on the inclined edges, I set the layer height to 0.12 mm for the front panel, and cut the back to the standard 0.2 mm.

For convenience, I added two legs to the back of the case, like on keyboards, which allows you to put the “Ray” at an angle of about 35 degrees. Initially, I made one large handle, as shown in the picture below, but it turned out to be inconvenient. In addition, this leg ate up a lot of space inside the case and did not provide reliable fixation.

To output the PWM and IN contacts I used BANANA PL2493 sockets, which I placed on top of the device. They are held in place by the included nuts and thread lock.

The funniest part of the project for me is the nameplates. I wrote earlier that I have two single-extruder printers that can only print with one material, but there is nothing stopping me from changing the plastic during printing. At first, I printed a plate, on top of which I printed letters with a different color filament, but they were too small and fragile. After that, I tried this: first, I print a model with thin letters (0.4 mm in height), and on top of it, a model with grooves for the letters. At first, it turned out well, but then, when I started trying other nameplates, I noticed that the letters were smeared by random movements of the nozzle.

Here I seriously started thinking about purchasing a dual-extruder printer, which is great for such tasks. Brief explanation: this is a printer with two independent extruders, allowing you to print a part from two different plastics. The simplest example is to make letters of a different color right inside the part. (like, for example, on the panels on the terminals for buying tickets for the Moscow train). But my colleague suggested an obvious and working idea – to print not the letters, but the cutouts for them, and it worked.

How to make such a panel? It's simple, I drew a 1.6 mm thick plate, cut out the words I needed in it. After that, during cutting the model in prusa slicer, I found the first layer, which should be printed in a different color, and put a plastic change marker on it, this is the “+” button next to the layer number. This function is also available in other slicers.

With this setting I set it to print, after finishing the first half of the model the printer will ask to change the plastic, after which it will finish the second part. Easy!

One of the nuances is that for small inscriptions it is better to use a smaller nozzle (I had 0.2 mm), but even this does not always save from defects and threads on the model. The panel with PMW inscriptions did not turn out to be of excellent quality due to the very small size of the letters, I had to finish it with tweezers. There was also an issue with colors: after the black filament, you need to squeeze out a lot of plastic to get a non-dark color. From the photos you can see that all the nameplates are darker than the body. I think that in the future it will be necessary to use a different color as a base, or change the colors between themselves.

I tried painting the nameplates, but due to the layered nature of the panels, the paint often flowed into the wrong places, so I discarded this option almost immediately.

Conclusions on the case: after several kilograms of plastic, there is a strong feeling that it would be better to print a rougher version of ABS, which I would then sand and paint. Next time I will try to do so. Another idea is to print the case from a simple composite (I was advised Carbex MF, but have not tried it yet) to get a nice rough surface. Judging by the description, a small percentage of additives in this plastic allows the case to remain non-abrasive for the user's hands. You also need to make a thicker front cover, the thin one bends very easily.

In terms of nameplate production, it would be great to get a dual-extruder printer or an ams system to get good nameplates right away. Or come up with another way to apply the inscriptions.

P.S. The slight curvature of the base of the case halves is due to the automatic bed leveling, which bends the first layer so that it prints well, so the two parts did not fit together perfectly. You can adjust the bed by placing some Kapton tape underneath, which I will do in the future.

Working with the DWIN display

The display is a full-fledged device with its own microcontroller on board. This allows not to load the main controller with image and menu processing. When the user enters something on the display, a message is sent via UART to the main controller about what and where was changed.

The firmware for DWIN is created in the DGUS program and loaded into the display using an SD card. I will not go into detail about this, since there is a lot of information on this topic in on the internet.

When creating a new project in the DGUS environment, you need to select the display resolution, generate a font and load background images drawn in advance in the graphics editor. Each image is a separate working field. The prepared elements should already have all the necessary fields and inscriptions. Of course, you can add them in this program, but there are few tools here. I prepared 3 images with fields for PWM, CAN and RS-485 and two pictures with keyboards.

Having created a project with background images, we begin to add a control interface over the drawing. For each drawn button there are two fields – the first field displays a variable (Data variables), and the second field calls the keyboard for input (Data Input).

Each menu item stores its value in a variable allocated to it, the location and volume of which is specified by the user. The address VP(0x) is the location in the display memory where the value of this field will be written, for user variables it starts with 0x5000. The settings also allow you to set the minimum and maximum value of the variable and point to the keyboard for input. You can read more about the settings here.

The keyboard is a separate background image (in my case 3 and 4). You can't get to these areas directly, but when you press the “Data Input” field, the keyboard appears on the screen. The “Keyboard settings” field is responsible for where the keyboard will be called from and to which part of the screen. I use two keyboards – for entering numbers and text. The first is used for PWM and enters a numeric value. The second enters characters from 0 to f. There are also buttons to exit the keyboard and delete the previous character.

To display the entered value, the “Data variables” field is used, which shows the content of the specified address. I place this field on top of the previous one to display the value inside the input button.

On the right side of the screen, above Gadget, is a page turn button. They only turn in one direction, which is acceptable in the case of only three pages.

DGUS has a “Data auto-uploading” function, by enabling which we will receive a message every time the user changes the state of a memory cell. This allows us not to poll the display constantly, but simply wait for the corresponding command from it, which will indicate where and what the user wrote.

The rest of the display pages are made in a similar way, the only difference is that in some places you can enter text (input in hex).

Overall, developing such a simple program for DWIN was not very difficult, but there were some nuances that need to be mentioned:

1. A file with fonts must be generated for the project, otherwise the preview will not work, but the firmware works on the display itself. You can see how to create fonts here (from 11 minutes)

2. The beep is very annoying. It can be turned off with a command from the controller, which I will show below

3. The display needs time to turn on, so there is a delay of one and a half seconds at the start of the stm32 firmware

4. The display simulation mode in DGUS works differently than the same project on the display. The text looks different (I think it uses a standard font) and the character limit works differently. It was very confusing at first, so I recommend using it sparingly.

Working with a microcontroller

I made the firmware for STM32G4 in STM32IDE, HAL library. The project uses two UARTs, CAN, several timers and GPIO.

First of all, let's look at the display initialization, which consists of waiting 1.5 seconds and sending a command to turn off the buzzer:

void sound_off (void)
{
	uint8_t data_tx[10];
	data_tx[0] = FRAME_HEADER_H;
	data_tx[1] = FRAME_HEADER_L;
	data_tx[2] = 0x07;
	data_tx[3] = DWIN_WRITE_VAR;
	data_tx[4] = 0x00;
	data_tx[5] = 0x80;
	data_tx[6] = 0x5A;
	data_tx[7] = 0x00;
	data_tx[8] = 0x00;
	data_tx[9] = 0x30;
	HAL_UART_Transmit(&huart3, data_tx, 10, 0xFFF);
}

Globally, the controller's task looks like this – it receives a command via UART, then processes it and does something with PWM, RS-485 or CAN. The controller can also receive a message via interfaces and will have to send them to the display. It turns out that there are only 3 tasks: receive a message via UART (display), via RS-485 or via CAN.

For these three tasks I created ring buffers, each for its own task. A ring buffer allows you to conveniently process received messages (a good example is here https://istarik.ru/blog/stm32/151.html). Messages to the ring buffer are received in the corresponding interrupts.

The main program loop looks pretty simple – the controller hangs waiting for some kind of message:

while (1)
 {
	  if (byte_available(2) > 1)
		  receiveCAN();
	  if (byte_available(1) > 5)        // минимальная посылка 6 байт
		  analysisMessage();
	  if (byte_available(0) > 1)
		  receiveRS485();
}

If messages come from the display, it is necessary to disassemble it and extract useful information from it. The transmission from DWIN looks like this: 0x 5A A5 06 83 50 24 01 01 90

Where are the bytes number:

• 0.1 – standard start of message from DWIN

• 2 – number of bytes

• 3 – command type (0x82 – write, 0x83 – read)

• 4,5 – address of the VP (display element) with which the interaction occurs

• 6 – number of VPs addresses (words) to read

• 7.. – data

If you are working with a string, then at the end there will be two or three more 0xFF bytes.

This command means that the user changed the variable written at address 0x5024 (PWM frequency 4) to a value equal to 0x190. It's all quite simple.

The analyzeMessage() function parses the received message and reinitializes the necessary peripherals. The other two functions, receiveCAN and receiveRS485, translate commands received from outside the device into symbols and send them to the display in the appropriate field.

The project code turned out to be quite simple, there is not much to tell about it, and anyone who wants to delve deeper can do so in the repository.

Conclusions

It took me three times longer to work on this device than I planned, and the result was twice as good as I wanted at the beginning. The idea of ​​such a device, which can replace a small test bench, proved to be quite viable.

If we talk about this implementation specifically, I really liked the format of the tablet with a touch screen – it's compact and convenient, if only we could add a battery there and it would be perfect. The plastic printed case made of PLA is acceptable, but I want better – tests with composite are waiting.

DWIN display and DGUS environment. They allow to create an interface that satisfies me now, but how to implement new wishes on it is an open question. Terminals need to be redesigned so that they can show a stream of incoming messages, and not just the most recent.

The project makes me want to add all sorts of things to it, for example, I want to make a series of PBS with digital outputs and standard interfaces, like SPI\I2C\UART. I also dream of implementing the ability to set the order of actions, like “send a message, wait 5 seconds and turn on PWM”. And it wouldn’t hurt to add the ability to save the operating parameters on the display, it’s inconvenient to enter the same RS-485 speed every time.

I really hope that next year I will be able to post an article here about the new version of my device. Thank you all for your attention!

Project repository: https://github.com/FamNuven/Ray

P.s. I didn’t post the PCB file of the board, because it has a couple of errors.

I have a frequency generator and interface converters, but they are not always at hand, and they may even be occupied in someone else’s stand.