My experience with the $1 Pro Mini "clones" (BTE17-14)

They appear to be currently active on AliEx as "BAITE Components Modules" with 2100 followers and 100% FB.

So maybe not gone? I just placed an order with them last night.

It works the same for AVR based boards (and possibly your clone). With Arduino AVR boards, it either finds the bootloader there or it finds the uploaded sketch (in case you upload using programmer). The address is 0x0000 (if not mistaken).

This is a no go here. When I try to build the LarduinoISP sketch for the Arduino Uno target, it errors on the SERIAL RX BUFFER SIZE:

LarduinoISP:62:2: error: #error : Please change the macro SERIAL_RX_BUFFER_SIZE to 250 (In the menu: Tools/Arduino as ISP/SERIAL_RX_BUFFER_SIZE)
#error : Please change the macro SERIAL_RX_BUFFER_SIZE to 250 (In the menu: Tools/Arduino as ISP/SERIAL_RX_BUFFER_SIZE)
^~~~~
exit status 1
#error : Please change the macro SERIAL_RX_BUFFER_SIZE to 250 (In the menu: Tools/Arduino as ISP/SERIAL_RX_BUFFER_SIZE)

But I have no "Tools/Arduino as ISP/SERIAL_RX_BUFFER_SIZE)" in my Tools menu. This option only appears if I set the board target to Larduino Uno.. (which my board is not, it's a generic Atmega 328P Uno clone, SMT type). This is why I was asking if I must use an LGT board as the Master / ISP Programmer.. as the sketch won't build for the genuine Atmega board.

I just checked and you are right. Let me check later today where to change that buffer size in the Arduino IDE. Two years ago the option did not exist in the tools menu and I had to change it somewhere in the IDE source.

On the ATmega328p, it consists mainly of being able to change the exception vectors' address (especially the program start address) to somewhere in high memory (controlled by fuses), instead of 0x0.
That way you put the bootloader at the high start address and it runs after reset, and the application can sit at its normal location (0x0) and not care whether a bootloader is present.

You can implement a bootloader without this capability, using what Optiboot calls a "Virtual Boot Partition.", and this is done for the ATtiny chips. But it takes a little bit more code to do so, and code space is quantized into "pages", so 20 bytes of code to the bootloader will end up causing it to use an extra full page of memory. (actually, it looks like pages are 1k on the LGT parts anyway, so it's not so much that the bootloader is bigger, but that the bootloader MUST occupy at least 1k, instead of only 512bytes on an ATmega328.)

I finally got it to work again, using an UNO.
First I looked where SERIAL_RX_BUFFER_SIZE is defined and it is in the file HardwareSerial.h

so I changed both 16 and 64 to 250 in this part of that file.

#if !defined(SERIAL_RX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_RX_BUFFER_SIZE 250 //16
#else
#define SERIAL_RX_BUFFER_SIZE 250 // 64
#endif
#endif

And it did not work .. :rage:
Still that error that the buffer size was too small.
Reopening the IDE, deleting all the temporary files did not help me, so I suspected the compiler is using a precompiled object for HardwareSerial over and over again and ignored I changed it's source. Even opening a new sketch, did not get what I wanted.

So I decided to install a completely new portable version of IDE 1.8.19 and first change the HardwareSerial.h file before I compile anything.
on my PC this is the path to HardwareSerial.h :

E:\Arduino\arduino-1.8.19\hardware\arduino\avr\cores\arduino

Now the LarduinoISP sketch would compile and upload to my Arduino UNO without problems. No more error message about the buffer.

I went back to my other Arduino IDE (with the LGT core) and after adding a 10uF capacitor between reset en gnd on my UNO I could burn the bootloader onto my "LGT pro mini clone"

Now my own question is "how do I force the IDE to compile everything again, and not re-using precompiled objects?" Is there a smarter way than installing a fresh portable IDE? Or is there another reason my edits in HardwareSerial.h did not get picked up?

Something is not right here. What you are saying is that the compiler is simply ignoring changes you make to the source code.. and that should absolutely never happen.

Not to mention that what you ultimately did is a very ugly hack! I cannot imagine that anything like that should be necessary in the first place.. I mean, deleting the entire IDE install?

(Don't take me wrong here. You really went after it and got it to work and that is admirable. It's just what you had to do along the way to get there..)

Unfortunately I do not know C/++ so I'm not really sure how .h(eader) files function. But my suspicion is that the reason your changes are not picked up relates to the fact that you are changing a header file.

Or that's my first guess!

Well, it was not the first time it happened to me, but normally, selecting another board, deleting the temporary files or creating a completely new sketch got me out of the woods. Not this time.
I am sure there is a reason for this and a better way to avoid the ugly hack of installing the IDE for just one sketch and then deleting it again after it's uploaded.
maybe there are more temp directories I would need to clear than the one I did

C:\Users\Hans\AppData\Local\Temp

Hence my question.

Speaking of questions, another one is presenting itself.

IF the bootloader is written to the top of memory AND the bootloader may be of varying length THEN how does the boot process know where to begin execution?

Does the bootloader install process calculate the address and write it to some fixed location, like the last two bytes of memory (like $7FFE/7FFF)?

I found the answer to my own question.
There are two folders in my Arduino portable installation, where the sources of the core files are present.

This location
E:\Arduino\arduino-1.8.19\hardware\arduino\avr\cores\arduino

but also this one
E:\Arduino\arduino-1.8.19\portable\packages\arduino\hardware\avr\1.8.6\cores\arduino

Apparently the second location is the one the compiler is using, as when I make changes there they get noticed right away.

A clean IDE installation does not have the packages folder yet. On my PC it shows up after I add another core via boards manager.

Looking carefully at the verbose output during compilation hinted me to the other location of core files, so that's something to remember for future hacking of the sourcecode.

What is the significance of the 1.8.6 branch? Is this something from an earlier IDE install that the 1.8.19 installer incorporated into the new install tree?

1.8.6 is the boards version, not the IDE version.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.