PDA (Pocket Travel Computer): Circuitry GPS logger
My hobby project is a GPS logger . In the comments they even suggested calling it “Trip Computer”, as Logging is only a small part of all the device’s capabilities. Much has already been implemented, but most have yet to be done.
In previous articles, I described the transition from arduino to STM32 , STMCube / HAL , talked a bit about the build system , bootloader , built a composite USB device and pumped its speed . All this was done on a breadboard based on the Blue Pill STM32F103CB board and a hedgehog from wires. It's time for the device to take shape, both electronic (circuit) and physical (body).
The issues that I had to solve at this stage are very much interconnected. When choosing components for a project, you need to roughly imagine which housing they can be pushed into. And vice versa, the case must be made for the components that are available and the boards, which, again, need to be done with an eye on the case. In general, a tangle of interconnected issues. You can, of course, take a bigger box and push anything there, but you wanted something compact and light.
Before starting right away I want to note that this is not the final version of the device. Most likely there will be errors in the scheme, something will not work as intended, in the comments they will indicate more correct solutions, some approaches will be rethought. I think that the second or even third version of the device can not be avoided. Therefore, I will be glad to your constructive comments.
Under the cutter is multi-bead, but it will be engineering.
The GPS logger Holux M241 is my faithful companion on all trips. He has been with me for many thousands of kilometers. The track that the logger writes is primarily used for geotagging photos, but the route itself is also of interest. It’s fun to find out how fast you went skiing, what route your plane flew in, what a sight just flashed outside the window of the bus. Here I did a small review of this device.
Unfortunately, the capabilities of this device have long ceased to suit me: I'm tired of messing around with batteries that always sit down at the most inopportune moment. There is also a very low USB speed, a small amount of internal flash, an inconvenient mechanism for merging tracks, little information is available on the display, low accuracy, a very primitive odometer, no information about satellites, and much more.
Yes, one could look for what modern trackers offer - for sure there is already a device on sale that meets my requirements. But this is a hobby, I want to try to do something difficult, interesting, useful and necessary. Let even if I will use it.
The goal of the project as a whole is to make a similar device in something, only stuffed with my Wishlist.In the first article in the series, I detailed my requirements for the device. In short, I would like to do the following:
In addition to technical requirements and Wishlist, there are also non-technical (non-functional) ones. So I would like to pump in creating complex devices from scratch, to figure out how various electronic components work, how to program them, how to breed a board and design a case.
Why do you need a separate device if all modern phones have GPS, a large screen and a lot of memory? Well, first of all, I'm not sure that a phone with GPS on in track recording mode can withstand the whole day. I would not really like to stay in an unfamiliar country without a phone. Also, I personally use a separate device is simply more comfortable.
Perhaps over time, the concept of the device will change. So, for example, now it’s becoming more and more logical to abandon the screen and connect to the phone via bluetooth, and do all the logic trick on the phone. This idea is very robust and tempting. But at this stage, I would still like to have a display - I always have time to abandon it.
For the first year and a half, I developed the device on various kinds of debug boards (first arduino nano, then STM32F103 blue pill, then STM32F407VE). I had to connect peripherals on wiring and purchased modules. As a result, a hedgehog made of wires turned out on the table, which didn’t work out to test GPS reception on the street — sometimes you couldn’t even move the wires without breaking the connection somewhere. And then happy debugging.
Each time, sitting down for writing useful functionality, I came up against the fact that some other part of the system stopped working normally and had to spend hours debugging something completely unrelated. So, for example, the most important component of the system - the GPS receiver - in the end turned out to be the least developed, because I had to head off into debug USB, SD cards, setting up libraries, and so on.
Finally, I got tired of it and I decided to make my debugging board - this will be the topic of today's article. The goals that I set for myself in this part of the project were as follows:
And although the ultimate goal is a compact battery device, today I will not do such things as
I’ll take care of the consumption setting when the board and the main code are ready. By the way, about the code today, too, will not be, but I will definitely return to this question as there will be enough interesting material.
Let's start with the components and peripherals. Along the way, we will estimate the number of legs of the microcontroller that will be required to connect this zoo, as well as the power parameters. Because it’s a hobby project that I chose components from what I can actually buy in stores / ebay / ali, and also from what can be soldered at home (well, also from what was already in my personal stock). Perhaps some specific microcircuits could solve the problem better, but the issue of affordability and price is important to me.
I was always interested in the question of why controllers with a large number of ports are needed, and I easily counted 39 paws needed for my functionality. And that's not counting quartz, reset, and power. And there are ideas for what to do with a dozen more (for example, the display could be connected via an Intel 8080 or Motorola 6800 parallel interface).
You can, of course, screw the I2C port externders to reduce the number of legs used. But firstly, these are additional components on the board, secondly, the software part becomes very complicated, and thirdly, small microcontrollers still have little memory, and where there is enough memory, there are also enough ports. So I don’t see any reason to complicate everything - let there be 39 lines.
With power supply, not everything is so clear. You can probably power all devices from 3.3V and calm down. But we, nevertheless, are going to make a mobile device, which means we need to think about saving energy. So you need to try to choose a smaller supply voltage. Below I’ll estimate what kind of savings you can try to achieve.
Here is the data for all devices in the plate - in this form it is more convenient to choose the power domain to which to connect this or that device.
From the plate it is easy to see that some devices can operate from sufficiently low voltages (from 1.8V). Others can work comfortably from 2.7V. Finally, the remaining devices below 3V cannot work. The squeaker, for good, generally needs 5V, but for me it will be powered by the highest voltage - from the battery, no matter how much it is.
With the power of the display is not yet fully understood. In the description of the display modules with ali, the range is 3 - 5V, while in the datasheet on the matrix controller SSD1309 the range is 1.65 - 3.3V. I assume that 3V is needed to swing the boost converter on the display module board, while 1.65V is enough for the logic. As will be seen from the discussions about the layout, it makes sense to abandon the display module and connect the display directly, which will allow powering the display from the 2B domain.
I have about the same reasoning about GPS - different sources indicate different supply voltages. So far, I don’t have an understanding of which module I will use in the end, so let the receiver hang out in the 2.7V domain.
With an SD card it’s not at all clear. The specification obscurely says that in general the card should be powered from 3.3V, but modern cards are smart enough and can understand that they are stuck in a low-voltage device and can switch to power from 1.8V. But the mechanism for choosing food is not very clear. I will feed the card from 2B and see what happens. It will not work - it will work from 3V.
So, 4 power buses loom - 2V, 2.7V, 3V and a battery. I would like to put all the consumers who are eating and constantly working (and this is the controller and GPS) on the lowest voltage bus, but at the moment I have not yet decided on the GPS module (and therefore its power supply - 2 or 2.7V), which means it will be necessary some kind of universal solution. I’ll try to separate the board so that it is easy to apply one or the other voltage.
Where do you get so many different stresses from? Even in the early stages of the project, I looked at the PT1502 microcircuit and even managed to try it in another project. In addition to the charger for the lithium battery, this microcircuit has as many as 3 power sources - one pulse and 2 line downs. Here, however, the voltage is not regulated on one of them and is 3V - I will try to power the INA219 from it. The remaining 2 power sources are not a problem, because there you can choose the voltage.
Estimating consumption is not very successful. The peak consumption is indicated in the datasheets - this is enough to calculate the power of the key transistors, but not enough to estimate the required battery capacity. So for now, I will select the battery based on the available space in the case, and there I will already measure the actual consumption.
The question may arise, but how to match devices with different operating voltages? Let's get it right.
Finally, a few words about why I am so fighting for lowering the supply voltage. A chip in a pulsed DC-DC converter, which can exchange volts for amperes (if you do not take into account the losses of the converter itself, of course). To be more precise, exchange a higher voltage with a lower current for a lower voltage and a higher current. In this case, we are more interested in the reverse reasoning - if you feed a low-voltage load through DC-DC, then the current consumption of this entire structure together with the converter will be lower than the current consumption of the load itself. Well, since the battery capacity is measured in mAh, then reducing the current consumption will increase the battery life.
I approached the question of choosing a microcontroller thoughtfully - I played with the configurator for a long time, weighing the pros and cons of each option. I really liked the STM32 microcontrollers, so I don’t see the point of looking in the direction of other controllers without special need. Moreover, in the STM32 line there are controllers for every taste and for any periphery. The experience gained in the previous stages of my project allows you to narrow down the choice of controller based on the list of peripherals, already written software bindings, as well as the features that I would like to implement in the future.
So, it is obvious that the 20kb of memory in my STM32F103CB is definitely small - there are not enough decent size buffers for communicating with an SD card and USB. I have not even started to implement much of the planned functionality, but it has already taken more than 19kb. But with the power for processing, as it turned out, this is not particularly necessary. If all communication with peripherals is pushed into DMA, then the share of the central processor remains only a couple of percent.
Having estimated the list of what I need from the controller, I calculated the following:
STMicroelectornics microcontrollers are just a dime a dozen - for every taste, color and wallet. At first I tried to choose a controller to proceed from the series. Rulers L0 and F0 are too weak and not enough memory, S7 and H7, on the contrary, are too fancy, there is no SDIO in L4 (UPD: SDIO is, they just did not mention it on the title page of the series). Among the rest of the series, you can choose something based on my needs, since I have no particularly specific requirements.
The STM32WB series impresses with the presence of Bluetooth, but the VFQFPN68 case somewhat cools the desire to use it in hobby projects. And I did not find such controllers in retail.
I aimed at the LQFP64 case - sufficient in the number of legs, but not very large at the same time and can be soldered at home. It's good that there is a CubeMX configurator where you can select what you need with filters.
I opted for the STM32F103RB controller for three reasons. First, I’ve already studied the F103 series well with the Blue Pill board. In general, the STM32F103CB controller completely suited me, only the memory was not enough. Secondly, I already have a bootloader and a low-level code for this controller, while others will have to be redone. And thirdly, about a year ago, I was already in joy to buy 3pcs STM32F103RB. Then I did not do a detailed study of the available controllers, but simply picked up a thicker controller from the F103 line. Do not throw it away now :)
As I have already noted, I do not have particularly specific peripheral or performance requirements. But if I run into something, then in mind I already have controllers from the F4 line (if something more powerful is needed), or L152RD, if you need to decide something with consumption (UPD: I also looked at L433RC). What pleases, with STM32, almost all pin-to-pin controllers are compatible, and F4 and L1 / L4 can be soldered almost without altering the board. You can even collect and compare consumption with different MKs.
We decided on the details. It's time to draw a diagram, then trace the board, and then try to fit it into the case. Or not? To admit, at first I just went this way, but then I came to the conclusion that everything needs to be done in the reverse order. Well, or at least at the same time.
I would like to get a compact device. And for this you need to accurately understand the size of the available space, in turn, to understand where to place the board and its size, what size battery can fit, where to place the buttons, screen, USB connector and other external components, as well as figure out how to mount the components and you can Is it convenient to lay wires between them. It’s simply pointless to start raising a board without understanding all of these things. So it turns out that you need to first deal with the body and layout, and then move on to the circuit.
Also, in the process of drawing the case, I had to revise the selection of components several times. So initially I thought to use a cheap 128x64 0.96 ”display (working area 21.7 x 11.2mm), but this display looked completely microscopic against the background of a much larger case. Then a 1.3 ”display was ordered (working area 29.4 x 14.7 mm), but it didn’t get much better. Then I got a 1.54 ”display (35 x 17.5 mm) - it looks more or less normal with it. This is currently the main working option.
According to estimates, a 1.8 ”–2” display would have looked better, but these already come in color and higher resolution, and accordingly the screen buffer will be large enough for my controller (35kb instead of 1kb). Well, pushing large displays into the case can also be a problem, because landing brackets for such modules are significantly larger than the active area of the display.
While I was writing this article on ali, monochrome 2.42 ”displays appeared with the same resolution (128x64) and the exact same binding as 1.54”. I ordered this for myself - there is a chance to stick it into my case without a significant increase in the device.
Another significant point at the stage of work on the case was the understanding that the purchased display module takes up too much space and significantly reduces the space for the main board. Therefore, I decided to abandon the finished display module, and instead place the display and its binding to my board. The number of parts in the circuit increased slightly, but the design as a whole was noticeably simplified and became more compact.
I have similar thoughts on the topic of the GPS module. It’s not that big, but no matter how put it or it interferes, or the antenna is closed by some battery. It may be a good idea to place the module’s stuffing on your board, and place the antenna somewhere else.
Work on the case also made it possible to determine the size and capacity of the battery. In the available volume, a 900mAh battery was just found - we will focus on it. I would like my device to work on a 15-20 hour battery, which means that the consumption should be at the level of 45-60mA.
At the moment, I can’t call the work on the hull finished. Firstly, the question of choice for some components (display, GPS) is still open. Secondly, it is not clear whether my circuit will start in principle or whether it will be necessary to radically change anything. And thirdly, the board turns out to be too compact - I’m not sure that I can dissolve, solder and debug it. Therefore, in this article, I will still focus on circuitry issues, I will move in simpler and more understandable steps, and I will talk about the case next time. Here you have a couple of renderings and photos for seed.
Now you can do electronics. I will describe the circuitry solutions in sufficient detail. First of all, for the same newcomers in electronics as I, as well as a synopsis to myself. Experienced electronics engineers can skim through the circuitry and rewind to the next section.
Let's start with nutrition.
The device will be powered by a lithium battery, which means you need a charge controller. Also, some components have an upper voltage limit of about 3.6V, while the battery can easily be more than 4V. So you need a step-down power source. As we have already found out, we will need several different stresses.
I already mentioned that I will use the PT1502 chip. It fits well, because implements a charge controller, 3 power sources, as well as a button switching device circuit. There are several functional blocks in the microcircuit, which I have divided in the diagram for clarity. The circuit itself is a slightly revised datasheet circuit. Here is the lithium battery charge controller.
Resistor R3 sets the charge current. By default, this corresponds to 470mA. Perhaps, according to the test results, I will reduce the value of this resistor to 510 Ohms, which will give a charge current of about 900mA (1C).
The controller can report the current charge mode with the foot CHG_STAT. Moreover, he knows how to give signals as much as 3 - it charges, does not charge, and has already been charged, but is still connected to the outlet. In the first version, the internal transistor presses the foot to the ground and this can easily be recognized by the controller. In the second embodiment, the transistor is completely closed and the leg goes into a high impedance state. Using a power-up, such a signal is also easy to read by the controller.
But with the third state, not everything is so simple. There, the transistor is ajar and a current of 20 μA flows through it. In order to consider such a condition, I was prompted to choose a lift so that about half of the nutrition was on my leg. Then it will be possible using the ADC to easily detect such a state. Using Ohm's law we get R5 = 1V / 20mkA = 50k.
As I said, the PT1502 chip is not just a charger, but also a tricky controller for all power. The microcircuit monitors the voltages in the circuit and with the help of the RESET signal can control the main processor (they say that you still have to start up early, the power has not yet stabilized).
Also, the microcircuit can start the device at the touch of a button (BTN1), and also, upon a signal from the microcontroller (PWR_HOLD), complete the operation and turn off the power. Well, in order to signal the processor that the battery is running out of signal BAT_LOW.
And this is the main power source.
The output voltage is set by the voltage at the BUCKFB terminal and is set to 2V with battery power. But with two-volt power, one problem was discovered - USB will not work. Those. the battery will be charged, but it won’t be able to transmit data - the microcontroller simply will not be able to output signals to a USB bus of sufficient amplitude. Datashit recommends a voltage of at least 2.7V, better than 3.3V.
In order not to block another power source and think how to switch between them, I decided to just adjust the ratio of the divider R1 / R4 + R7. With this inclusion, the impulse operates continuously. As soon as the device is plugged into USB, the transistor opens and shunts R7. The ratio of the driving resistors changes and we get 3.16V at the output (we can still play with the ratings and reach 3.3V).
The PT1502 also has 2 linear controls.
Either low-consuming components (INA219) or short-lived (bluetooth) will be connected to these controllers, so the efficiency of these sources will not be a problem. The LDO2 supply voltage can be adjusted using the LDO2_SETx signals.
Since I still have open questions regarding the supply voltage, I decided to separate the jumpers to select the LDO2_SETx mode. Also, in order to be able to measure real consumption on the corresponding bus, I will also brid jumper JP1 / JP2 / JP3 to the comb.
Finishing the topic of power supplies, we need to mention the power of the display. I wrote a little higher that, in the name of compactness, I had to abandon the purchased display module and pick up the display with the strapping to my board. This display requires a special 7-16V boost converter. Conveniently, this source can be turned on and off using the EN signal. The circuit itself is copied from the datasheet of the booster, exactly the same is used in display modules with ali.
Now a little about the power of the microcontroller. The microcircuit is large and has 6 power lines - 4 for the digital part, 1 analog power supply and one for the clock. According to the datasheet on the STM32F103, on all power lines (maybe, except for the clock), there should be a 100nF capacitor along the capacitor, and one more common at 4.7uF.
But in the datasheet on STM32F4 it is said that although the microcontrollers are practically compatible in terms of outputs, they still have somewhat different power schemes. So on the two terminals there should be 2.2 μF capacitors between the terminal and the ground (and not between the ground and the power, as in F1). Therefore, I had to consider both options and for a specific microcontroller to solder only part of the capacitors.
Continuing the topic of nutrition, you need to figure out how to measure it. You can rely on the BAT_LOW signal and ask the user to quickly curl up if the battery is low. But this is exactly what I did not like in the original Holux M-241, because this signal appeared too late and was easy to miss. I need some sort of more informative indicator of battery power.
Just in case, I put the most ordinary divider for measuring battery voltage. But in the case of lithium batteries, this is only an informative indicator and should not be relied on. For more honest battery readings on the Internet, they suggest using a “pendant”.
This small microchip counts the amount of energy that has passed through it to or from the battery. Measurements are made on the shunt R10. The readings of the microcircuit can be read through I2C. The microcircuit is able to measure the voltage on the battery, the current passing through the resistor, and also multiply one by the other. Unfortunately, she does not know how to accumulate the value of the hours that have passed by Watts *, therefore she will have to do a constant survey.
Let's move on to the digital part. The heart of the entire system is the STM32F103RB microcontroller.
The strapping in the form of two quartz was taken from other circuits found on the Internet (double-checked in the datasheet). I do not need to boot from RAM, but because the signal BOOT1 pulled to the ground. BOOT0 can be selected with a jumper to boot from the main flash memory or the built-in UART bootloader (for example, for the primary firmware of the device)
Next is the LED.
Since the main supply voltage will vary from 2 to 3.3V, LEDs should not be connected to it - the brightness and current consumption will vary greatly. Therefore, the LEDs I will be connected to the 2.7V bus, current-limiting resistors are calculated accordingly. Since the microcontroller will not be able to give out more than 2V on its leg when powered by a battery, the GPIO push-pull mode cannot be used. Only open-drain.
There is nothing special to say about the reset button.
Since a three-volt device (INA219) will be sitting on the I2C bus, you also need to make braces to three volts.
The SWD connector is also standard. A diode is needed to switch the power between the battery and external power from the programmer.
Anticipating the exclamations that they don’t do this and that such a connection does not really disconnect the battery. Yes, it does not turn off, but the diode is not for this. This thing is needed to be able to power the device from the programmer if the battery is not connected. And if connected, then let it work from it. Well, if the battery is connected, then you need to protect the programmer itself from 4.2V on the battery.
But it’s worthwhile to dwell on the buttons in more detail.
The fact is that the first button will not only be a button, but will also work as a device switch - the BTN1 signal is connected to the PT1502 power controller chip. When the device is turned off, power is not supplied to the microcontroller and other consumers. That is why the button is connected not to power (VCC) but to the battery (BAT). By pressing this button, the PT1502 will turn on all power sources and start the microcontroller. After that, the button can work like a regular button. In order not to burn the microcontroller with a high voltage battery, I built a small voltage divider that drives the BTN1 signal into the necessary framework (however, it is possible without this - the microcontroller has inputs that are tolerant to 5V)
The second button is unremarkable. Inside the processor, a pull to the ground will be turned on, and the button will feed a unit to the line ...
Smoothly switch to the heavy periphery. USB
The USB connector will stick out of the device, and static electricity can walk there. It turns out there are special microcircuits (such as STF202-22) that protect microcontrollers from external influences.
But something else is interesting here. A 1.5k resistor is hidden inside the STF202 chip, which is connected between the VBUS foot and the D + line. This resistor is needed according to the USB specification - it tells the host that it is stuck in something. In many circuits, this resistor is always connected between the power and the D + line. As soon as the host sees such a resistor on the D + line, it immediately starts communicating with the device. This is not always appropriate because Some devices may not be immediately ready for communication.
This is just my case. There’s a simple trick for this (spied here) You can turn this resistor on and off using a transistor: we want communication - we turn on the resistor, we just want to be powered by USB - turn it off. When you stick your mobile phone in USB, he usually asks “what will we do? Drain or just charge? ”- in terms of electronics, this is just about connecting a pull-up resistor.
But how do you know if a device is stuck in USB? To do this, I provided the USB_PLUGGED signal, which is removed from the simplest divider.
5V from USB could also be fed directly to the foot of the microcontroller - they are still tolerant to 5V. But let it be already through the divider.
Accelerometer now
The scheme is taken from a datasheet. The module is connected via I2C, but in order to signal to the microcontroller that there is news, an interrupt line is also used. Also, since the three-volt INA219 is still hanging on the same I2C bus, the accelerometer communication legs are also powered from the 3B bus to coordinate levels.
I already mentioned that I would like to save energy and turn off unused appliances. So the accelerometer power is turned on by the transistor.
By the way, I really liked the so-called digital transistors - a transistor complete with two resistors. This saves a little space on the board. It’s only a pity that with two-volt power, I could not pick up a digital transistor with at least some decent current - 20-30 mA maximum. So more voracious consumers had to be connected with MOSFETs.
Go ahead, GPS
GPS is on a separate board and connects via a loopback. Since I have not yet decided on the GPS module, I provided 2 different power supplies. In addition to the power transistor on the side of the processor board, there is nothing more interesting.
I’ll just say a few words about UARTs. Initially, I planned to use all 3 - one for uploading firmware and debug, the second for GPS and the third for Bluetooth. But it turned out that UART3 is on the same pins as I2C No. 2, which I originally planned to use for the display. I had to choose. As a result, I came to the conclusion that I can upload firmware and debug through the same UART that is reserved for GPS (of course, GPS will have to be disabled). Well, if you need to debut the GPS itself, that is, USB CDC (in which you can upload logs) and SWD. A little later, I abandoned the idea of using I2C No. 2, so UART3 got free, but in the name of saving battery, I decided to focus on two UARTs.
Bluetooth
Bluetooth is connected according to the scheme from the datasheet. Pin PIO1 can operate in two modes. In the first, an LED is connected to it and the module blinks with this LED. Different winks mean different status. In another mode, this pin works as a digital one — one when communication is established, and 0 if not. Modes are switched by AT commands during module initialization.
SD card
The SD card connection scheme, although standard, was for some reason very difficult for me. There are too many different connection options on the Internet and it’s not so easy to figure out which one is right.
For the most part, I had questions in bushings. Occasionally there are schemes where they put resistors in 1k. Some circuits put 22 Ohm resistors, apparently as a protection against static. Nevertheless, the majority of circuits do not offer pass-through resistors, and I will probably go the same way. I also will not have statics since The flash drive will live inside the case.
The power transistor, it seems to me, will not be in demand either, I think the card will always work - it's a logger. But since this is a test board, let it be. The same thing about the coil - apparently this inclusion in the original was made paranoid, or the card was used in an environment with poor power or interference. I think to solder there a zero resistor and try without a coil.
Display
I had the opportunity to connect one of the display modules with Ali via SPI and compare with the connection via I2C. There were no particular difficulties, and the code only needed to be slightly wasted. At the same time, the speed of SPI is an order of magnitude higher than that of I2C. Having added the data from the datasheet on consumption (4 mA for SPI versus 10 mA for I2C), the need for pull-up resistors for I2C, I decided to connect the display via SPI.
Unfortunately, the BS0 signal is not output to the display loop, and therefore you cannot select the 3-Wire SPI mode, you can only 4-Wire SPI. The difference in the additional D / C line (data / command), which in the case of 3-Wire mode is transmitted by the ninth bit of the SPI data. However, maybe 4-Wire mode is for the better, because SPI in STM32 can only transmit 8 bits.
The rest of the scheme corresponds to the datasheet.
And finally, the squeaker. Nothing special - just turn on through the transistor.
In case there will be a vibromotor instead of a tweeter, I provided a protective diode. However, I heard the opinion that a protective diode also does not hurt the tweeter.
Above, I described my thoughts on the subject of the corps. In fact, I even tried to breed a board for this case. Unfortunately, the board was too cramped. I had to use two-way installation, switch from components 1206 to 0805, but still the components on the board were very tightly located. Moreover, every change in the scheme was a pain, because I had to re-breed almost half the board.
So I fiddled with her for several weeks, but the board defeated me and I abandoned the project for almost a year. Kick become here this article . But really, this is only a prototype, and the first of several. Why bother with a super compact board where you can’t crawl with a soldering iron or an oscilloscope, if you can debug everything on a large board?
Well, you don’t have to make such a huge board like an iPhone, but it’s quite possible to get into the promotional 100x100mm 2 layers of JLCPCB. You can practically limit yourself. So on the board there was a huge 2.42 ”display, jumpers measuring consumption on all power lines, power capacitors where needed and not needed, and in general a bunch of parts that could not have been installed. There is also a place left.
There is nothing much to tell about wiring. I parted most of the signal and power lines along the upper layer, while the lower one was almost completely buried underground. Unfortunately, the layout still turned out to be quite dense and some signal lines had to be dragged along the lower layer through half the board. Because of this, the land is "torn" in places into several loosely connected islands. I hope this is not a problem.
I didn’t do the earth under the bluetooth antenna, but still I had to drag one of the signal lines through this zone. However, this is the BT_ON line, along which the signals often do not run (it is either turned on or off there), which means that it should not particularly affect the signal.
Summer was coming and I was planning to take the rent with me on vacation. So that maids in hotels are not afraid of a bare debugging board with a fan of wires, it would be nice to hide it in the case. I could not deny myself the pleasure and developed the case and the board at the same time. So there were mounting boards in the case, mounting the display holder.
The GPS module is a sandwich of several boards and an antenna 12 mm thick. I decided not to hook it on top of the board, but to place it on the same level. This reduced the thickness of the case, but bit off one corner of the board.
A couple of photos of the board and the final (at this stage of the project) device.
The battery is successfully placed under the display, but I had to make a small box in order to raise the display closer to the top cover.
A few words on the assembly board. I soldered everything in about 3 evenings, and about a week in the evenings it took me leisurely to debug and check from the software side. To my surprise, there were no fundamental difficulties with setting up the board and almost everything started up as it should.
It turned out that soldering 0805 was not much more difficult to solder than 1206, it is quite edible at home with a magnifying glass. You can even swing at 0603. But with the soldering of the microcontroller and the display connector (they have a 0.5 mm pitch), I had to tinker. On people’s YouTube, it somehow just looks like - I just spent it with a soldering iron and that’s it, but all my conclusions stuck instantly.
Not without minor problems. In some places there was no drinking, somewhere there was a “snot”. The footprint for the USB connector turned out to be wrong - he had a step of conclusions was less than necessary (so trust after that footprints from the Internet!). I had to bend the conclusions a bit so that they became on the tracks. The FPC display connector bought on Ali turned out to be with contacts on the bottom, while I needed it with contacts on the top (I had never suspected such a difference before). I had to “blow off" the connector from the standard display board.
After stuffing the board into the case, it turned out that it was not possible to disconnect the battery simply by pulling out the connector, but I did not want to leave the debugged board under voltage. I had to poke a switch.
When setting up the board, it turned out that there is no ground contact anywhere where the oscilloscope probe could be attached. I had to cling to the USB connector with a crocodile. It will be necessary to provide test sites in the next version of the board.
Circuitry also revealed problems. So it was a completely unexpected fact that the PT1502 chip on the RESET pin generates a voltage of 3V (I was completely sure that there was something like an open collector). As a result, these 3Vs leaked to the power line, even though I planned to have only 2V there.
Here is a simplified diagram of what happened
Thanks to the great mind and the guys with easyelectronics.ru, this joint was decided by adding one diode. After a little surgery, this part worked as it should.
Further, the bluetooth module (powered by 2.5V) I accidentally connected to the main power (2V), instead of the fixed 3V. Now the bluetooth can work for me only when USB is connected, when the voltage of the main power rises to 3.3V.
In principle, you could wave the scalpel and solder the bluetooth to the correct power, but the UART2 to which the bluetooth is connected is not tolerant to 5V (he himself read it in the datasheet at the analysis stage, he himself noted this in the text above, and eventually forgot when wiring the board ) Therefore, connecting the bluetooth to power is higher than the power of the microcontroller is fraught ... In the next version of the board, I just connect the bluetooth to some other UART.
The DC-DC converter with variable voltage also worked as planned - when powered by a battery, it gives out 2V, and when you connect the USB rises to 3.16V (you need to play with the ratings and reach 3.3V). But here one more flaw of the circuit got out: you also need to be able to raise the voltage when powered by the programmer. I think this is being treated by adding another diode. I'll try to play a little later.
Finally, during the work on the board, I still did not understand how to properly power the SD card from undervoltage. A short googling did not lead to anything. Apparently, you need to immerse yourself in reading tight-page specifications (which, in addition, are partially closed). In the meantime, I short-circuited R7 and the board is now powered by a fixed 3.16V (3.3V). I will leave it this way for the next couple of months, while I will be working on the software part.
Speaking of software. Surprisingly (although quite expected), but in general everything started up without problems. Since I switched between microcontrollers of the same series (from F103CB to F103RC), I did not need to alter the software part. Only corrected the pin numbers, but added the inclusion of transistors. Nevertheless, there were 2 non-trivial moments with which I had to tinker.
The first is battery power. I debugged the board using USB power and everything worked fine in general. But the board persistently did not want to turn on the battery. Those. It can work (if you turn it on when the USB is connected, and then pull out the cord), but it does not work to start on a cold one.
According to the design of the PT1502 chip, the board should start like this. The user presses the BTN1 button and after a third of a second the chip turns on all power sources. When everything is fine with power, the PT1502 “releases” the RESET signal, thereby starting the microcontroller. The processor, in turn, sets the signal PWR_HOLD to one, signaling that it has started. Then PT1502 regularly supplies electricity to the circuit until the microcontroller lowers the signal PWR_HOLD to zero.
But this is in theory. In fact, as soon as the processor set the PWR_HOLD signal, the board instantly turned off. I shoveled the entire power circuit, looked at the waveforms of the main signals, shuffled the code in the bootloader back and forth, but I could not understand the problem. I also sinned on the absence of a pull-down resistor on the PWR_HOLD line, which I forgot to install, but it is recommended by a datasheet (and most likely it is still needed). But adding it with a canopy did not solve the problem. And only when I lent a four-channel oscilloscope did everything become clear.
When the user presses the button (orange line), the PT1502 chip turns on the power (purple line). All this happens long (300ms) before the events on this waveform. And then something interesting happens. PT1502 releases RESET (blue line), the processor starts and for some reason lowers the button line to zero. Even though the microcontroller is still trying to raise the POWER_HOLD line (green line) - it's too late, the PT1502 has already turned off all power sources. Then a few more convulsions occur, but the circuit still dies quietly.
The question is, where did the zero on the button come from? The whole point is an inconspicuous mistake in the bootloader , due to which the output mode was set on the BTN1 leg (maybe miracles also occurred on the other legs at that moment) and a low signal appeared there.
What else I had to wrestle with was the SD card. There was simply no SDIO module in the old microcontroller, so I had to study this piece from scratch. I spent almost the whole day trying to get a map, copying pieces of code from examples on the Internet, and what CubeMX generated. Although the card was perfectly readable on a computer, it persistently did not want to start in my circuit. I sinned for poor soldering, incorrectly selected pull-up resistors, clumsy circuitry and incorrectly interpreted datasheet. But to my surprise, another card with the same code and on the same board started up without problems. It will be necessary to study this issue in more detail.
There was another problem with the card. Poking in different lines with an oscilloscope, I saw activity only on the D0 line, while on D1-D3 there was silence - the card worked in a single-bit mode. In HAL, even the HAL_SD_ConfigWideBusOperation () function was found, which can enable 4-bit transfer mode. Unfortunately, when the card was switched to 4-bit mode, the SDIO peripherals went into the deep RX FIFO Overrun and stopped working.
The problem turned out to be very interesting. It turned out that inside the HAL_SD_ReadBlocks () function there is a certain loop that polls the SDIO flags. As new data arrives from the card, this code transfers the bytes from the internal FIFO buffer to user memory. So the card transmitted bytes so fast that the code in HAL_SD_ReadBlocks () simply did not have time to transfer the data. I had to temporarily lower the clock frequency of the card. Well, in the future I will use DMA and such a problem should not arise in principle.
Those who in this place expected to see the finished device I will have to disappoint - only the test board is completed, and even that, only the piece of iron. Now you need to breathe life into it, do the programming, fine-tune the modes and consumption. Well, actually write a logging code - that's why the whole project was started.
Nevertheless, for me personally this stage is a very big and important achievement. Electronics is not my specialty and I am very glad that the device even started up. I managed to pump enough in designing circuits, matching several devices, wiring the board, choosing components and much more.
I’ll talk about the software part another time. As well as about the nuances of the settings. The fact is that this entire filling must first be revived and tested. At the moment, it was possible to start all the devices on the board (well, except for the tweeter), but only in the amount of “it started and somehow responds”. No processing logic has yet been written.
Plans for the near future:
On this, let me take my leave. I would be grateful for constructive comments, ideas and advice on circuit design and PCB layout.
Sources:
Code
Code bootloader
board
housing
In previous articles, I described the transition from arduino to STM32 , STMCube / HAL , talked a bit about the build system , bootloader , built a composite USB device and pumped its speed . All this was done on a breadboard based on the Blue Pill STM32F103CB board and a hedgehog from wires. It's time for the device to take shape, both electronic (circuit) and physical (body).
The issues that I had to solve at this stage are very much interconnected. When choosing components for a project, you need to roughly imagine which housing they can be pushed into. And vice versa, the case must be made for the components that are available and the boards, which, again, need to be done with an eye on the case. In general, a tangle of interconnected issues. You can, of course, take a bigger box and push anything there, but you wanted something compact and light.
Before starting right away I want to note that this is not the final version of the device. Most likely there will be errors in the scheme, something will not work as intended, in the comments they will indicate more correct solutions, some approaches will be rethought. I think that the second or even third version of the device can not be avoided. Therefore, I will be glad to your constructive comments.
Under the cutter is multi-bead, but it will be engineering.
What and why
The GPS logger Holux M241 is my faithful companion on all trips. He has been with me for many thousands of kilometers. The track that the logger writes is primarily used for geotagging photos, but the route itself is also of interest. It’s fun to find out how fast you went skiing, what route your plane flew in, what a sight just flashed outside the window of the bus. Here I did a small review of this device.
Unfortunately, the capabilities of this device have long ceased to suit me: I'm tired of messing around with batteries that always sit down at the most inopportune moment. There is also a very low USB speed, a small amount of internal flash, an inconvenient mechanism for merging tracks, little information is available on the display, low accuracy, a very primitive odometer, no information about satellites, and much more.
Yes, one could look for what modern trackers offer - for sure there is already a device on sale that meets my requirements. But this is a hobby, I want to try to do something difficult, interesting, useful and necessary. Let even if I will use it.
The goal of the project as a whole is to make a similar device in something, only stuffed with my Wishlist.In the first article in the series, I detailed my requirements for the device. In short, I would like to do the following:
- recycle the power system, transfer to a lithium battery
- put a more informative display
- more accurate GPS
- expand flash with SD card
- add compass and accelerometer
- I also want to redesign the logging system to spit out tracks in the format I need.
In addition to technical requirements and Wishlist, there are also non-technical (non-functional) ones. So I would like to pump in creating complex devices from scratch, to figure out how various electronic components work, how to program them, how to breed a board and design a case.
Why do you need a separate device if all modern phones have GPS, a large screen and a lot of memory? Well, first of all, I'm not sure that a phone with GPS on in track recording mode can withstand the whole day. I would not really like to stay in an unfamiliar country without a phone. Also, I personally use a separate device is simply more comfortable.
Perhaps over time, the concept of the device will change. So, for example, now it’s becoming more and more logical to abandon the screen and connect to the phone via bluetooth, and do all the logic trick on the phone. This idea is very robust and tempting. But at this stage, I would still like to have a display - I always have time to abandon it.
For the first year and a half, I developed the device on various kinds of debug boards (first arduino nano, then STM32F103 blue pill, then STM32F407VE). I had to connect peripherals on wiring and purchased modules. As a result, a hedgehog made of wires turned out on the table, which didn’t work out to test GPS reception on the street — sometimes you couldn’t even move the wires without breaking the connection somewhere. And then happy debugging.
Each time, sitting down for writing useful functionality, I came up against the fact that some other part of the system stopped working normally and had to spend hours debugging something completely unrelated. So, for example, the most important component of the system - the GPS receiver - in the end turned out to be the least developed, because I had to head off into debug USB, SD cards, setting up libraries, and so on.
Finally, I got tired of it and I decided to make my debugging board - this will be the topic of today's article. The goals that I set for myself in this part of the project were as follows:
- Make a debug board that will not have problems with non-contact components
- Decide on the main technical and schematic solutions
- Roughly decide on the components that I will use next
- Roughly decide on the layout and body
- The circuit should be general enough to be able to experiment with different components and their modes
And although the ultimate goal is a compact battery device, today I will not do such things as
- fine-tuning power modes
- consumption setting
- sleep modes
I’ll take care of the consumption setting when the board and the main code are ready. By the way, about the code today, too, will not be, but I will definitely return to this question as there will be enough interesting material.
Components
Let's start with the components and peripherals. Along the way, we will estimate the number of legs of the microcontroller that will be required to connect this zoo, as well as the power parameters. Because it’s a hobby project that I chose components from what I can actually buy in stores / ebay / ali, and also from what can be soldered at home (well, also from what was already in my personal stock). Perhaps some specific microcircuits could solve the problem better, but the issue of affordability and price is important to me.
- The main component of a GPS logger, of course, will be a GPS receiver . In my case, this is a pretty tricked out Beitian BN-880 based on the UBlox M8N chip. A compass on the HMC5883L chip is also integrated in the module.
Connection: 2 UART contacts for GPS and 2 I2C contacts for compass
Power supply: from 2.7V
Consumption: 50mA- Also ordered a Beitial BN-220 module . It does not have a compass, but the antenna is more compact (20x20mm versus 30x30). The truth is still unclear how this will affect the quality of the reception. Need to test. But, judging by the datasheet, this module can work from 1.4V, which should have a positive effect on the operating time of the device.
- Here, in fact, everything is somehow muddy. It seems that the BN-880 is based on the UBlox M8N, while the BN-220 is based on the U-blox M8030-KT. But in some sources it slips that it seems to be the same thing. More precisely, the M8N is a module, and the M8030-KT is a chipset inside. I am concerned about the power issue in this confusion - the M8N is announced from 2.7V, while the M8030-KT is from 1.4V.
- As an alternative, I also have a SIM868 module lying around . in which in addition to GPS there is also a GSM / GPRS module and Bluetooth. While scary for its trickery and complexity of connection. You will need to first play with the debug board.
- The main difference between the device and “just a black box” is the presence of a display . In the first prototypes, I connected the display via I2C, but the bus load was about 25%. But the point is not even in the percentage ratio, but in the fact that the transfer of the screen buffer takes about 25ms, during which it is impossible to communicate with other devices on the bus. This can be a problem, so you need to either put the display on a separate I2C bus, or consider connecting via SPI
Connection: 2 I2C wires or 3 SPI wires (write-only display, so the MISO line is not used, but a separate Data / Command signal is used)
Power: 3V;
Consumption: 25mA - To control the device, I will use 2 buttons that occupy 2 legs of the processor, respectively
- In the original device (Holux M241, from which I originally copied the functionality), it was impossible to watch the track at an arbitrary point in time. It was necessary to connect the device to the computer and merge the data with a special program. It seems to me that the ability to watch a track on a mobile phone or tablet at any time will be very popular. For this, I purchased a Bluetooth module HM-13 . This module is selected because it has SPP in addition to BLE.
Connection: 2 UART wires, 1 status wire (connected / not connected)
Power supply: 2.5V - 3.9V
Consumption: 50mA (although the figure 13mA is shown right next to the datasheet. Perhaps this is the peak and average value) - As I was told, it makes no sense to keep the receiver turned on if you just sat down to rest or went to dine in a cafe. Therefore, I decided to add the MMA8452 accelerometer and use it to determine whether the device is at rest or we are moving somewhere.
Connection: 2 wires I2C, 1 wire for interruption
Power supply from 2V to 3.6V with some microscopic consumption - The GPS track will be recorded on the SD card . I have already tried using the card in SPI mode and this is, to put it mildly, slow. Especially on the record. The correct mode for the SD card is SDIO
Connection: 6 wires
Power: from 1.8V
Consumption is unknown, but I think no more than 20mA - To save energy, it makes sense to turn off the power of those devices that are not currently in use. So near each consumer I will put on a transistor , which I will control a separate signal from the microcontroller.
Connection: 5 signals, one foot per consumer (GPS, Bluetooth, accelerometer, SD card, display)
UPD based on comments. Disabling the accelerometer does not make sense - it already has a penny consumption. Some devices will most likely always work (for example, an SD card) - in the future I will be able to remove these transistors. Some devices (such as GPS) are able to disconnect themselves on command from the interface. If according to the test results this part will work well - I will also refuse an external transistor. In the meantime, I’m making the maximum possible total fee, let these transistors be all. Moreover, I have not yet decided on the periphery. - A two-color LED for status display (how about without a blinking LED?). It would be possible to put a tri-color, but so far I do not see the need.
Connection: 2 pins
Consumption: 10mA - In addition to Bluetooth, a more classical mechanism for merging tracks will be implemented - via USB . For this, 4 lines will be involved - a differential pair for data, 1 pin for detecting that the device was plugged into USB, and another pin for logical connection (why I need these 2 pins I will describe below)
- Appetite comes with eating. Since I began to shove everything in my dream device, why not add a tweeter ? Well, or a vibration motor . I have not yet come up with a user case.
Connection: 1 wire - The device will still need to be powered up. While the PT1502 chip is looking at me as a lithium battery charger and power controller . To communicate with the microcircuit, you will need to use 2 wires: one for power management, the other for a signal about a dead battery. For the sake of interest, it will be possible to measure the voltage of the battery using another line.
- Of course, the charge of a lithium battery is incorrect to measure on the basis of voltage. Therefore, I added a special INA219 power meter chip.
Supply voltage: 3-5V, recommend 3.3V
Connection: 2 I2C wires
As you will see below, the 3V supply voltage creates some discomfort in the connection. I would prefer the counter chip to be powered from 2.7V or lower. But after going through several options based on price / case / availability, I still did not find anything at 2.7V. I will be grateful for the help. - It remains only to provide a debugging interface SWD (3 wires) and a debugging UART (2 more wires)
I was always interested in the question of why controllers with a large number of ports are needed, and I easily counted 39 paws needed for my functionality. And that's not counting quartz, reset, and power. And there are ideas for what to do with a dozen more (for example, the display could be connected via an Intel 8080 or Motorola 6800 parallel interface).
You can, of course, screw the I2C port externders to reduce the number of legs used. But firstly, these are additional components on the board, secondly, the software part becomes very complicated, and thirdly, small microcontrollers still have little memory, and where there is enough memory, there are also enough ports. So I don’t see any reason to complicate everything - let there be 39 lines.
Nutrition
With power supply, not everything is so clear. You can probably power all devices from 3.3V and calm down. But we, nevertheless, are going to make a mobile device, which means we need to think about saving energy. So you need to try to choose a smaller supply voltage. Below I’ll estimate what kind of savings you can try to achieve.
Here is the data for all devices in the plate - in this form it is more convenient to choose the power domain to which to connect this or that device.
| Device | Power range | Power Domain | communication |
| CPU | 2 - 3.6V | 2V | |
| Accelerometer | 2 - 3.6V | 2V | I2C |
| Sd card | 1.8V or 3.6V | 2V | SDIO |
| Display | 1.65 - 3.3V or 3 - 5V | 2V | I2C or SPI |
| GPS | 2.7 - 5.5V or from 1.4V | 2.7V | UART |
| Bluetooth | 2.5 - 3.9V | 2.7V | UART |
| Power Meter (INA219) | 3 - 5.5V | 3v | I2C |
| Buzzer | 3V - 5V | Vbat |
From the plate it is easy to see that some devices can operate from sufficiently low voltages (from 1.8V). Others can work comfortably from 2.7V. Finally, the remaining devices below 3V cannot work. The squeaker, for good, generally needs 5V, but for me it will be powered by the highest voltage - from the battery, no matter how much it is.
With the power of the display is not yet fully understood. In the description of the display modules with ali, the range is 3 - 5V, while in the datasheet on the matrix controller SSD1309 the range is 1.65 - 3.3V. I assume that 3V is needed to swing the boost converter on the display module board, while 1.65V is enough for the logic. As will be seen from the discussions about the layout, it makes sense to abandon the display module and connect the display directly, which will allow powering the display from the 2B domain.
I have about the same reasoning about GPS - different sources indicate different supply voltages. So far, I don’t have an understanding of which module I will use in the end, so let the receiver hang out in the 2.7V domain.
With an SD card it’s not at all clear. The specification obscurely says that in general the card should be powered from 3.3V, but modern cards are smart enough and can understand that they are stuck in a low-voltage device and can switch to power from 1.8V. But the mechanism for choosing food is not very clear. I will feed the card from 2B and see what happens. It will not work - it will work from 3V.
So, 4 power buses loom - 2V, 2.7V, 3V and a battery. I would like to put all the consumers who are eating and constantly working (and this is the controller and GPS) on the lowest voltage bus, but at the moment I have not yet decided on the GPS module (and therefore its power supply - 2 or 2.7V), which means it will be necessary some kind of universal solution. I’ll try to separate the board so that it is easy to apply one or the other voltage.
Where do you get so many different stresses from? Even in the early stages of the project, I looked at the PT1502 microcircuit and even managed to try it in another project. In addition to the charger for the lithium battery, this microcircuit has as many as 3 power sources - one pulse and 2 line downs. Here, however, the voltage is not regulated on one of them and is 3V - I will try to power the INA219 from it. The remaining 2 power sources are not a problem, because there you can choose the voltage.
Estimating consumption is not very successful. The peak consumption is indicated in the datasheets - this is enough to calculate the power of the key transistors, but not enough to estimate the required battery capacity. So for now, I will select the battery based on the available space in the case, and there I will already measure the actual consumption.
The question may arise, but how to match devices with different operating voltages? Let's get it right.
- All communication legs of the microcontrollers are marked as Five Volt Tolerant (except for UART2 on the legs of PA2 / PA3), which means that if there appears 3.3V from the highest voltage device, nothing bad will happen
- The accelerometer, although powered by 2V, can potentially be connected in parallel with high-voltage devices on the bus. This problem is easily solved - with the MMA8452Q microcircuit, you can separately power the communication leads from another power supply (via the “high-voltage” device on the bus itself)
- I’ll try to power the SD card from the same voltage as the microcontroller, which means I don’t need to coordinate anything.
- GPS and Bluetooth should eat the “low” voltage from the microcontroller without any problems. The same goes for other “high voltage” devices
Finally, a few words about why I am so fighting for lowering the supply voltage. A chip in a pulsed DC-DC converter, which can exchange volts for amperes (if you do not take into account the losses of the converter itself, of course). To be more precise, exchange a higher voltage with a lower current for a lower voltage and a higher current. In this case, we are more interested in the reverse reasoning - if you feed a low-voltage load through DC-DC, then the current consumption of this entire structure together with the converter will be lower than the current consumption of the load itself. Well, since the battery capacity is measured in mAh, then reducing the current consumption will increase the battery life.
Count?
Один знакомый предположил, что поскольку КПД преобразователя как правило около 90%, то вполне возможно усложнение схемы в виде DC-DC себя не окупит и можно обойтись обычной КРЕНкой. Давайте прикинем. Я провел пару ооочень грубых рассчетов, чтобы понять а действительно ли DC-DC преобразователь тут уместен.
Вот табличка с расчетами. Пускай батарейка 900мАч линейно разряжается с 4.1 до 3.5В (что в общем случае не соответствует истине). КПД DC-DC преобразователя я поставил 90% (среднее значение из даташита). Разряжать будем током 100мА. Я хотел сравнить время работы устройства от линейного источника питания с импульсным.
Очевидно, что линейный источник разрядит батарею 900мАч током 100мА за 9 часов. А вот с импульсным источником устройство протянет гораздо дольше — 9.3 часа при целевом напряжении 3.3В, 11.4 часа при 2.7В, и целых 15 часов при напряжении 2В. Разумеется, расчеты ну оооочень грубые, но даже так видно, что с импульсным источником долгоживучесть аккумулятора существенно возрастает.
Вот табличка с расчетами. Пускай батарейка 900мАч линейно разряжается с 4.1 до 3.5В (что в общем случае не соответствует истине). КПД DC-DC преобразователя я поставил 90% (среднее значение из даташита). Разряжать будем током 100мА. Я хотел сравнить время работы устройства от линейного источника питания с импульсным.
Очевидно, что линейный источник разрядит батарею 900мАч током 100мА за 9 часов. А вот с импульсным источником устройство протянет гораздо дольше — 9.3 часа при целевом напряжении 3.3В, 11.4 часа при 2.7В, и целых 15 часов при напряжении 2В. Разумеется, расчеты ну оооочень грубые, но даже так видно, что с импульсным источником долгоживучесть аккумулятора существенно возрастает.
Microcontroller
I approached the question of choosing a microcontroller thoughtfully - I played with the configurator for a long time, weighing the pros and cons of each option. I really liked the STM32 microcontrollers, so I don’t see the point of looking in the direction of other controllers without special need. Moreover, in the STM32 line there are controllers for every taste and for any periphery. The experience gained in the previous stages of my project allows you to narrow down the choice of controller based on the list of peripherals, already written software bindings, as well as the features that I would like to implement in the future.
So, it is obvious that the 20kb of memory in my STM32F103CB is definitely small - there are not enough decent size buffers for communicating with an SD card and USB. I have not even started to implement much of the planned functionality, but it has already taken more than 19kb. But with the power for processing, as it turned out, this is not particularly necessary. If all communication with peripherals is pushed into DMA, then the share of the central processor remains only a couple of percent.
Having estimated the list of what I need from the controller, I calculated the following:
- > = 128kb flash (now about 50k is taken)
- > = 40 kb of memory (now 19k is taken)
- > = 40 feet GPIO (see reasoning above)
- > = 40MHz (you don’t need much, the main thing is to have less consumption)
- DMA (I really liked it)
- > = 2x I2C,> = 3x UART,> = 1 SPI
- SDIO (flash drive through SPI is very slow)
- Honest USB Full Speed, better High Speed
- Availability (the ability to buy a couple of pieces at the right price)
- Of the wishes, there is still native support for parallel LCD interfaces (usually implemented as an FSMC external memory access module)
STMicroelectornics microcontrollers are just a dime a dozen - for every taste, color and wallet. At first I tried to choose a controller to proceed from the series. Rulers L0 and F0 are too weak and not enough memory, S7 and H7, on the contrary, are too fancy, there is no SDIO in L4 (UPD: SDIO is, they just did not mention it on the title page of the series). Among the rest of the series, you can choose something based on my needs, since I have no particularly specific requirements.
The STM32WB series impresses with the presence of Bluetooth, but the VFQFPN68 case somewhat cools the desire to use it in hobby projects. And I did not find such controllers in retail.
I aimed at the LQFP64 case - sufficient in the number of legs, but not very large at the same time and can be soldered at home. It's good that there is a CubeMX configurator where you can select what you need with filters.
I opted for the STM32F103RB controller for three reasons. First, I’ve already studied the F103 series well with the Blue Pill board. In general, the STM32F103CB controller completely suited me, only the memory was not enough. Secondly, I already have a bootloader and a low-level code for this controller, while others will have to be redone. And thirdly, about a year ago, I was already in joy to buy 3pcs STM32F103RB. Then I did not do a detailed study of the available controllers, but simply picked up a thicker controller from the F103 line. Do not throw it away now :)
As I have already noted, I do not have particularly specific peripheral or performance requirements. But if I run into something, then in mind I already have controllers from the F4 line (if something more powerful is needed), or L152RD, if you need to decide something with consumption (UPD: I also looked at L433RC). What pleases, with STM32, almost all pin-to-pin controllers are compatible, and F4 and L1 / L4 can be soldered almost without altering the board. You can even collect and compare consumption with different MKs.
A few words about the body and layout
We decided on the details. It's time to draw a diagram, then trace the board, and then try to fit it into the case. Or not? To admit, at first I just went this way, but then I came to the conclusion that everything needs to be done in the reverse order. Well, or at least at the same time.
I would like to get a compact device. And for this you need to accurately understand the size of the available space, in turn, to understand where to place the board and its size, what size battery can fit, where to place the buttons, screen, USB connector and other external components, as well as figure out how to mount the components and you can Is it convenient to lay wires between them. It’s simply pointless to start raising a board without understanding all of these things. So it turns out that you need to first deal with the body and layout, and then move on to the circuit.
Also, in the process of drawing the case, I had to revise the selection of components several times. So initially I thought to use a cheap 128x64 0.96 ”display (working area 21.7 x 11.2mm), but this display looked completely microscopic against the background of a much larger case. Then a 1.3 ”display was ordered (working area 29.4 x 14.7 mm), but it didn’t get much better. Then I got a 1.54 ”display (35 x 17.5 mm) - it looks more or less normal with it. This is currently the main working option.
According to estimates, a 1.8 ”–2” display would have looked better, but these already come in color and higher resolution, and accordingly the screen buffer will be large enough for my controller (35kb instead of 1kb). Well, pushing large displays into the case can also be a problem, because landing brackets for such modules are significantly larger than the active area of the display.
While I was writing this article on ali, monochrome 2.42 ”displays appeared with the same resolution (128x64) and the exact same binding as 1.54”. I ordered this for myself - there is a chance to stick it into my case without a significant increase in the device.
Another significant point at the stage of work on the case was the understanding that the purchased display module takes up too much space and significantly reduces the space for the main board. Therefore, I decided to abandon the finished display module, and instead place the display and its binding to my board. The number of parts in the circuit increased slightly, but the design as a whole was noticeably simplified and became more compact.
I have similar thoughts on the topic of the GPS module. It’s not that big, but no matter how put it or it interferes, or the antenna is closed by some battery. It may be a good idea to place the module’s stuffing on your board, and place the antenna somewhere else.
Work on the case also made it possible to determine the size and capacity of the battery. In the available volume, a 900mAh battery was just found - we will focus on it. I would like my device to work on a 15-20 hour battery, which means that the consumption should be at the level of 45-60mA.
At the moment, I can’t call the work on the hull finished. Firstly, the question of choice for some components (display, GPS) is still open. Secondly, it is not clear whether my circuit will start in principle or whether it will be necessary to radically change anything. And thirdly, the board turns out to be too compact - I’m not sure that I can dissolve, solder and debug it. Therefore, in this article, I will still focus on circuitry issues, I will move in simpler and more understandable steps, and I will talk about the case next time. Here you have a couple of renderings and photos for seed.
Scheme
Now you can do electronics. I will describe the circuitry solutions in sufficient detail. First of all, for the same newcomers in electronics as I, as well as a synopsis to myself. Experienced electronics engineers can skim through the circuitry and rewind to the next section.
Let's start with nutrition.
The device will be powered by a lithium battery, which means you need a charge controller. Also, some components have an upper voltage limit of about 3.6V, while the battery can easily be more than 4V. So you need a step-down power source. As we have already found out, we will need several different stresses.
I already mentioned that I will use the PT1502 chip. It fits well, because implements a charge controller, 3 power sources, as well as a button switching device circuit. There are several functional blocks in the microcircuit, which I have divided in the diagram for clarity. The circuit itself is a slightly revised datasheet circuit. Here is the lithium battery charge controller.
Resistor R3 sets the charge current. By default, this corresponds to 470mA. Perhaps, according to the test results, I will reduce the value of this resistor to 510 Ohms, which will give a charge current of about 900mA (1C).
The controller can report the current charge mode with the foot CHG_STAT. Moreover, he knows how to give signals as much as 3 - it charges, does not charge, and has already been charged, but is still connected to the outlet. In the first version, the internal transistor presses the foot to the ground and this can easily be recognized by the controller. In the second embodiment, the transistor is completely closed and the leg goes into a high impedance state. Using a power-up, such a signal is also easy to read by the controller.
But with the third state, not everything is so simple. There, the transistor is ajar and a current of 20 μA flows through it. In order to consider such a condition, I was prompted to choose a lift so that about half of the nutrition was on my leg. Then it will be possible using the ADC to easily detect such a state. Using Ohm's law we get R5 = 1V / 20mkA = 50k.
As I said, the PT1502 chip is not just a charger, but also a tricky controller for all power. The microcircuit monitors the voltages in the circuit and with the help of the RESET signal can control the main processor (they say that you still have to start up early, the power has not yet stabilized).
Also, the microcircuit can start the device at the touch of a button (BTN1), and also, upon a signal from the microcontroller (PWR_HOLD), complete the operation and turn off the power. Well, in order to signal the processor that the battery is running out of signal BAT_LOW.
And this is the main power source.
The output voltage is set by the voltage at the BUCKFB terminal and is set to 2V with battery power. But with two-volt power, one problem was discovered - USB will not work. Those. the battery will be charged, but it won’t be able to transmit data - the microcontroller simply will not be able to output signals to a USB bus of sufficient amplitude. Datashit recommends a voltage of at least 2.7V, better than 3.3V.
In order not to block another power source and think how to switch between them, I decided to just adjust the ratio of the divider R1 / R4 + R7. With this inclusion, the impulse operates continuously. As soon as the device is plugged into USB, the transistor opens and shunts R7. The ratio of the driving resistors changes and we get 3.16V at the output (we can still play with the ratings and reach 3.3V).
The PT1502 also has 2 linear controls.
Either low-consuming components (INA219) or short-lived (bluetooth) will be connected to these controllers, so the efficiency of these sources will not be a problem. The LDO2 supply voltage can be adjusted using the LDO2_SETx signals.
Since I still have open questions regarding the supply voltage, I decided to separate the jumpers to select the LDO2_SETx mode. Also, in order to be able to measure real consumption on the corresponding bus, I will also brid jumper JP1 / JP2 / JP3 to the comb.
Finishing the topic of power supplies, we need to mention the power of the display. I wrote a little higher that, in the name of compactness, I had to abandon the purchased display module and pick up the display with the strapping to my board. This display requires a special 7-16V boost converter. Conveniently, this source can be turned on and off using the EN signal. The circuit itself is copied from the datasheet of the booster, exactly the same is used in display modules with ali.
PT1505
Перерывая интернет в поисках альтернатив на микросхему PT1502 я наткнулся на ее старшую сестру — микросхему PT1505. Это практически такой же контроллер питания, только с дополнительной повышайкой. С таким контроллером можно было бы сократить количество элементов на плате. К сожалению микросхемы PT1505 в продаже не нашел.
Кстати, буду благодарен если Вы знаете аналогичные контроллеры питания от других производителей.
Кстати, буду благодарен если Вы знаете аналогичные контроллеры питания от других производителей.
Now a little about the power of the microcontroller. The microcircuit is large and has 6 power lines - 4 for the digital part, 1 analog power supply and one for the clock. According to the datasheet on the STM32F103, on all power lines (maybe, except for the clock), there should be a 100nF capacitor along the capacitor, and one more common at 4.7uF.
But in the datasheet on STM32F4 it is said that although the microcontrollers are practically compatible in terms of outputs, they still have somewhat different power schemes. So on the two terminals there should be 2.2 μF capacitors between the terminal and the ground (and not between the ground and the power, as in F1). Therefore, I had to consider both options and for a specific microcontroller to solder only part of the capacitors.
Continuing the topic of nutrition, you need to figure out how to measure it. You can rely on the BAT_LOW signal and ask the user to quickly curl up if the battery is low. But this is exactly what I did not like in the original Holux M-241, because this signal appeared too late and was easy to miss. I need some sort of more informative indicator of battery power.
Just in case, I put the most ordinary divider for measuring battery voltage. But in the case of lithium batteries, this is only an informative indicator and should not be relied on. For more honest battery readings on the Internet, they suggest using a “pendant”.
This small microchip counts the amount of energy that has passed through it to or from the battery. Measurements are made on the shunt R10. The readings of the microcircuit can be read through I2C. The microcircuit is able to measure the voltage on the battery, the current passing through the resistor, and also multiply one by the other. Unfortunately, she does not know how to accumulate the value of the hours that have passed by Watts *, therefore she will have to do a constant survey.
Let's move on to the digital part. The heart of the entire system is the STM32F103RB microcontroller.
The strapping in the form of two quartz was taken from other circuits found on the Internet (double-checked in the datasheet). I do not need to boot from RAM, but because the signal BOOT1 pulled to the ground. BOOT0 can be selected with a jumper to boot from the main flash memory or the built-in UART bootloader (for example, for the primary firmware of the device)
Next is the LED.
Since the main supply voltage will vary from 2 to 3.3V, LEDs should not be connected to it - the brightness and current consumption will vary greatly. Therefore, the LEDs I will be connected to the 2.7V bus, current-limiting resistors are calculated accordingly. Since the microcontroller will not be able to give out more than 2V on its leg when powered by a battery, the GPIO push-pull mode cannot be used. Only open-drain.
There is nothing special to say about the reset button.
Since a three-volt device (INA219) will be sitting on the I2C bus, you also need to make braces to three volts.
The SWD connector is also standard. A diode is needed to switch the power between the battery and external power from the programmer.
Anticipating the exclamations that they don’t do this and that such a connection does not really disconnect the battery. Yes, it does not turn off, but the diode is not for this. This thing is needed to be able to power the device from the programmer if the battery is not connected. And if connected, then let it work from it. Well, if the battery is connected, then you need to protect the programmer itself from 4.2V on the battery.
But it’s worthwhile to dwell on the buttons in more detail.
The fact is that the first button will not only be a button, but will also work as a device switch - the BTN1 signal is connected to the PT1502 power controller chip. When the device is turned off, power is not supplied to the microcontroller and other consumers. That is why the button is connected not to power (VCC) but to the battery (BAT). By pressing this button, the PT1502 will turn on all power sources and start the microcontroller. After that, the button can work like a regular button. In order not to burn the microcontroller with a high voltage battery, I built a small voltage divider that drives the BTN1 signal into the necessary framework (however, it is possible without this - the microcontroller has inputs that are tolerant to 5V)
The second button is unremarkable. Inside the processor, a pull to the ground will be turned on, and the button will feed a unit to the line ...
Smoothly switch to the heavy periphery. USB
The USB connector will stick out of the device, and static electricity can walk there. It turns out there are special microcircuits (such as STF202-22) that protect microcontrollers from external influences.
But something else is interesting here. A 1.5k resistor is hidden inside the STF202 chip, which is connected between the VBUS foot and the D + line. This resistor is needed according to the USB specification - it tells the host that it is stuck in something. In many circuits, this resistor is always connected between the power and the D + line. As soon as the host sees such a resistor on the D + line, it immediately starts communicating with the device. This is not always appropriate because Some devices may not be immediately ready for communication.
This is just my case. There’s a simple trick for this (spied here) You can turn this resistor on and off using a transistor: we want communication - we turn on the resistor, we just want to be powered by USB - turn it off. When you stick your mobile phone in USB, he usually asks “what will we do? Drain or just charge? ”- in terms of electronics, this is just about connecting a pull-up resistor.
But how do you know if a device is stuck in USB? To do this, I provided the USB_PLUGGED signal, which is removed from the simplest divider.
5V from USB could also be fed directly to the foot of the microcontroller - they are still tolerant to 5V. But let it be already through the divider.
Accelerometer now
The scheme is taken from a datasheet. The module is connected via I2C, but in order to signal to the microcontroller that there is news, an interrupt line is also used. Also, since the three-volt INA219 is still hanging on the same I2C bus, the accelerometer communication legs are also powered from the 3B bus to coordinate levels.
I already mentioned that I would like to save energy and turn off unused appliances. So the accelerometer power is turned on by the transistor.
By the way, I really liked the so-called digital transistors - a transistor complete with two resistors. This saves a little space on the board. It’s only a pity that with two-volt power, I could not pick up a digital transistor with at least some decent current - 20-30 mA maximum. So more voracious consumers had to be connected with MOSFETs.
Go ahead, GPS
GPS is on a separate board and connects via a loopback. Since I have not yet decided on the GPS module, I provided 2 different power supplies. In addition to the power transistor on the side of the processor board, there is nothing more interesting.
I’ll just say a few words about UARTs. Initially, I planned to use all 3 - one for uploading firmware and debug, the second for GPS and the third for Bluetooth. But it turned out that UART3 is on the same pins as I2C No. 2, which I originally planned to use for the display. I had to choose. As a result, I came to the conclusion that I can upload firmware and debug through the same UART that is reserved for GPS (of course, GPS will have to be disabled). Well, if you need to debut the GPS itself, that is, USB CDC (in which you can upload logs) and SWD. A little later, I abandoned the idea of using I2C No. 2, so UART3 got free, but in the name of saving battery, I decided to focus on two UARTs.
Bluetooth
Bluetooth is connected according to the scheme from the datasheet. Pin PIO1 can operate in two modes. In the first, an LED is connected to it and the module blinks with this LED. Different winks mean different status. In another mode, this pin works as a digital one — one when communication is established, and 0 if not. Modes are switched by AT commands during module initialization.
SD card
The SD card connection scheme, although standard, was for some reason very difficult for me. There are too many different connection options on the Internet and it’s not so easy to figure out which one is right.
For the most part, I had questions in bushings. Occasionally there are schemes where they put resistors in 1k. Some circuits put 22 Ohm resistors, apparently as a protection against static. Nevertheless, the majority of circuits do not offer pass-through resistors, and I will probably go the same way. I also will not have statics since The flash drive will live inside the case.
The power transistor, it seems to me, will not be in demand either, I think the card will always work - it's a logger. But since this is a test board, let it be. The same thing about the coil - apparently this inclusion in the original was made paranoid, or the card was used in an environment with poor power or interference. I think to solder there a zero resistor and try without a coil.
Display
I had the opportunity to connect one of the display modules with Ali via SPI and compare with the connection via I2C. There were no particular difficulties, and the code only needed to be slightly wasted. At the same time, the speed of SPI is an order of magnitude higher than that of I2C. Having added the data from the datasheet on consumption (4 mA for SPI versus 10 mA for I2C), the need for pull-up resistors for I2C, I decided to connect the display via SPI.
Unfortunately, the BS0 signal is not output to the display loop, and therefore you cannot select the 3-Wire SPI mode, you can only 4-Wire SPI. The difference in the additional D / C line (data / command), which in the case of 3-Wire mode is transmitted by the ninth bit of the SPI data. However, maybe 4-Wire mode is for the better, because SPI in STM32 can only transmit 8 bits.
The rest of the scheme corresponds to the datasheet.
And finally, the squeaker. Nothing special - just turn on through the transistor.
In case there will be a vibromotor instead of a tweeter, I provided a protective diode. However, I heard the opinion that a protective diode also does not hurt the tweeter.
In iron
Above, I described my thoughts on the subject of the corps. In fact, I even tried to breed a board for this case. Unfortunately, the board was too cramped. I had to use two-way installation, switch from components 1206 to 0805, but still the components on the board were very tightly located. Moreover, every change in the scheme was a pain, because I had to re-breed almost half the board.
So I fiddled with her for several weeks, but the board defeated me and I abandoned the project for almost a year. Kick become here this article . But really, this is only a prototype, and the first of several. Why bother with a super compact board where you can’t crawl with a soldering iron or an oscilloscope, if you can debug everything on a large board?
Well, you don’t have to make such a huge board like an iPhone, but it’s quite possible to get into the promotional 100x100mm 2 layers of JLCPCB. You can practically limit yourself. So on the board there was a huge 2.42 ”display, jumpers measuring consumption on all power lines, power capacitors where needed and not needed, and in general a bunch of parts that could not have been installed. There is also a place left.
It's in Photo View
There is nothing much to tell about wiring. I parted most of the signal and power lines along the upper layer, while the lower one was almost completely buried underground. Unfortunately, the layout still turned out to be quite dense and some signal lines had to be dragged along the lower layer through half the board. Because of this, the land is "torn" in places into several loosely connected islands. I hope this is not a problem.
I didn’t do the earth under the bluetooth antenna, but still I had to drag one of the signal lines through this zone. However, this is the BT_ON line, along which the signals often do not run (it is either turned on or off there), which means that it should not particularly affect the signal.
Summer was coming and I was planning to take the rent with me on vacation. So that maids in hotels are not afraid of a bare debugging board with a fan of wires, it would be nice to hide it in the case. I could not deny myself the pleasure and developed the case and the board at the same time. So there were mounting boards in the case, mounting the display holder.
The GPS module is a sandwich of several boards and an antenna 12 mm thick. I decided not to hook it on top of the board, but to place it on the same level. This reduced the thickness of the case, but bit off one corner of the board.
A couple of photos of the board and the final (at this stage of the project) device.
The battery is successfully placed under the display, but I had to make a small box in order to raise the display closer to the top cover.
A few words on the assembly board. I soldered everything in about 3 evenings, and about a week in the evenings it took me leisurely to debug and check from the software side. To my surprise, there were no fundamental difficulties with setting up the board and almost everything started up as it should.
It turned out that soldering 0805 was not much more difficult to solder than 1206, it is quite edible at home with a magnifying glass. You can even swing at 0603. But with the soldering of the microcontroller and the display connector (they have a 0.5 mm pitch), I had to tinker. On people’s YouTube, it somehow just looks like - I just spent it with a soldering iron and that’s it, but all my conclusions stuck instantly.
Not without minor problems. In some places there was no drinking, somewhere there was a “snot”. The footprint for the USB connector turned out to be wrong - he had a step of conclusions was less than necessary (so trust after that footprints from the Internet!). I had to bend the conclusions a bit so that they became on the tracks. The FPC display connector bought on Ali turned out to be with contacts on the bottom, while I needed it with contacts on the top (I had never suspected such a difference before). I had to “blow off" the connector from the standard display board.
After stuffing the board into the case, it turned out that it was not possible to disconnect the battery simply by pulling out the connector, but I did not want to leave the debugged board under voltage. I had to poke a switch.
When setting up the board, it turned out that there is no ground contact anywhere where the oscilloscope probe could be attached. I had to cling to the USB connector with a crocodile. It will be necessary to provide test sites in the next version of the board.
Circuitry also revealed problems. So it was a completely unexpected fact that the PT1502 chip on the RESET pin generates a voltage of 3V (I was completely sure that there was something like an open collector). As a result, these 3Vs leaked to the power line, even though I planned to have only 2V there.
Here is a simplified diagram of what happened
Thanks to the great mind and the guys with easyelectronics.ru, this joint was decided by adding one diode. After a little surgery, this part worked as it should.
Further, the bluetooth module (powered by 2.5V) I accidentally connected to the main power (2V), instead of the fixed 3V. Now the bluetooth can work for me only when USB is connected, when the voltage of the main power rises to 3.3V.
In principle, you could wave the scalpel and solder the bluetooth to the correct power, but the UART2 to which the bluetooth is connected is not tolerant to 5V (he himself read it in the datasheet at the analysis stage, he himself noted this in the text above, and eventually forgot when wiring the board ) Therefore, connecting the bluetooth to power is higher than the power of the microcontroller is fraught ... In the next version of the board, I just connect the bluetooth to some other UART.
The DC-DC converter with variable voltage also worked as planned - when powered by a battery, it gives out 2V, and when you connect the USB rises to 3.16V (you need to play with the ratings and reach 3.3V). But here one more flaw of the circuit got out: you also need to be able to raise the voltage when powered by the programmer. I think this is being treated by adding another diode. I'll try to play a little later.
Finally, during the work on the board, I still did not understand how to properly power the SD card from undervoltage. A short googling did not lead to anything. Apparently, you need to immerse yourself in reading tight-page specifications (which, in addition, are partially closed). In the meantime, I short-circuited R7 and the board is now powered by a fixed 3.16V (3.3V). I will leave it this way for the next couple of months, while I will be working on the software part.
Speaking of software. Surprisingly (although quite expected), but in general everything started up without problems. Since I switched between microcontrollers of the same series (from F103CB to F103RC), I did not need to alter the software part. Only corrected the pin numbers, but added the inclusion of transistors. Nevertheless, there were 2 non-trivial moments with which I had to tinker.
The first is battery power. I debugged the board using USB power and everything worked fine in general. But the board persistently did not want to turn on the battery. Those. It can work (if you turn it on when the USB is connected, and then pull out the cord), but it does not work to start on a cold one.
According to the design of the PT1502 chip, the board should start like this. The user presses the BTN1 button and after a third of a second the chip turns on all power sources. When everything is fine with power, the PT1502 “releases” the RESET signal, thereby starting the microcontroller. The processor, in turn, sets the signal PWR_HOLD to one, signaling that it has started. Then PT1502 regularly supplies electricity to the circuit until the microcontroller lowers the signal PWR_HOLD to zero.
But this is in theory. In fact, as soon as the processor set the PWR_HOLD signal, the board instantly turned off. I shoveled the entire power circuit, looked at the waveforms of the main signals, shuffled the code in the bootloader back and forth, but I could not understand the problem. I also sinned on the absence of a pull-down resistor on the PWR_HOLD line, which I forgot to install, but it is recommended by a datasheet (and most likely it is still needed). But adding it with a canopy did not solve the problem. And only when I lent a four-channel oscilloscope did everything become clear.
When the user presses the button (orange line), the PT1502 chip turns on the power (purple line). All this happens long (300ms) before the events on this waveform. And then something interesting happens. PT1502 releases RESET (blue line), the processor starts and for some reason lowers the button line to zero. Even though the microcontroller is still trying to raise the POWER_HOLD line (green line) - it's too late, the PT1502 has already turned off all power sources. Then a few more convulsions occur, but the circuit still dies quietly.
The question is, where did the zero on the button come from? The whole point is an inconspicuous mistake in the bootloader , due to which the output mode was set on the BTN1 leg (maybe miracles also occurred on the other legs at that moment) and a low signal appeared there.
What else I had to wrestle with was the SD card. There was simply no SDIO module in the old microcontroller, so I had to study this piece from scratch. I spent almost the whole day trying to get a map, copying pieces of code from examples on the Internet, and what CubeMX generated. Although the card was perfectly readable on a computer, it persistently did not want to start in my circuit. I sinned for poor soldering, incorrectly selected pull-up resistors, clumsy circuitry and incorrectly interpreted datasheet. But to my surprise, another card with the same code and on the same board started up without problems. It will be necessary to study this issue in more detail.
There was another problem with the card. Poking in different lines with an oscilloscope, I saw activity only on the D0 line, while on D1-D3 there was silence - the card worked in a single-bit mode. In HAL, even the HAL_SD_ConfigWideBusOperation () function was found, which can enable 4-bit transfer mode. Unfortunately, when the card was switched to 4-bit mode, the SDIO peripherals went into the deep RX FIFO Overrun and stopped working.
The problem turned out to be very interesting. It turned out that inside the HAL_SD_ReadBlocks () function there is a certain loop that polls the SDIO flags. As new data arrives from the card, this code transfers the bytes from the internal FIFO buffer to user memory. So the card transmitted bytes so fast that the code in HAL_SD_ReadBlocks () simply did not have time to transfer the data. I had to temporarily lower the clock frequency of the card. Well, in the future I will use DMA and such a problem should not arise in principle.
Conclusion and next steps
Those who in this place expected to see the finished device I will have to disappoint - only the test board is completed, and even that, only the piece of iron. Now you need to breathe life into it, do the programming, fine-tune the modes and consumption. Well, actually write a logging code - that's why the whole project was started.
Nevertheless, for me personally this stage is a very big and important achievement. Electronics is not my specialty and I am very glad that the device even started up. I managed to pump enough in designing circuits, matching several devices, wiring the board, choosing components and much more.
I’ll talk about the software part another time. As well as about the nuances of the settings. The fact is that this entire filling must first be revived and tested. At the moment, it was possible to start all the devices on the board (well, except for the tweeter), but only in the amount of “it started and somehow responds”. No processing logic has yet been written.
Plans for the near future:
- Drive electronics in different modes, check that the circuit still works. Fix jambs in the second version of the board
- Measure consumption of the entire periphery and find ways to optimize consumption.
- Assemble several board options on different microcontrollers (for example, on L152 or L433)
- Thoughtfully read the SD specification and figure out how to properly connect the card in Low Voltage Signaling mode (1.8V)
- Try different GPS modules and finally decide which one I’ll go next
- Order a separate compass chip (for example, HMC5883L or HSCDTD008A) and try to use them somehow
- Make internal code refactoring, upgrade all major libraries, starting with HAL
- Finally, start writing features. Actually implement what the device was intended for
On this, let me take my leave. I would be grateful for constructive comments, ideas and advice on circuit design and PCB layout.
Sources:
Code
Code bootloader
board
housing