Dumidan
for Windows optimal https://drive.google.com/file/d/1DL5--2RUFIncdO8PmW87Bz9DzwPw5ms0/view?usp=sharing
It seems that mikrocontroller.net is migrating from SVN to git. So the new main repository is https://github.com/Mikrocontroller-net/transistortester which makes downloading much simpler.
The system cannot find the path specified.
rm -rf ../Obj/mega328_st7108
process_begin: CreateProcess(NULL, rm -rf ../Obj/mega328_st7108, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [../finish.mk:112: deleteobj] Error 2
../lcd_hw_4_bit.S:8:0: fatal error: opening dependency file ../Obj/mega328_st7108/dep/lcd_hw_4_bit.o.d: No such file or directory
compilation terminated.
make: *** [../finish.mk:14: ../Obj/mega328_st7108/lcd_hw_4_bit.o] Error 1
Program: 30304 bytes (92.5% Full)
(.text + .data + .bootloader)
Data: 190 bytes (9.3% Full)
(.data + .bss + .noinit)
EEPROM: 841 bytes (82.1% Full)
(.eeprom)
Hi,
It had a strange lcd module, with additional unknown chip between buffer and controller, white silicone around the controller, module was mounted on pins on the left side (not on screws). On picture "LCD modules.jpg", on left side is my lcd module from the DIY GM328 red kit.
When the firmware compiles without errors it should be fine. The version in the 'trunk' directory is the current k-firmware under development, similar to a beta version. With git the changes are referenced by the commit IDs. The finished versions are in 'tags'.
The best option would be to program the original firmware and use a logic analyzer to capture the LCD's initialization commands after power-on.
ldi r24, 0x36 ; MEM ADDRESS CONTROL
rcall lcd_command
ldi r22, 0x6C
ldi r24, 1
rcall lcd_write_data ; 6C = flipx + rotate + bgr, modded by someone, originally is 3C or 1C
-Is the 1.42m version better than the 1.13k?
-Do precompiled binaries of it exist? If not, how do i get started to compiling them?
Since the LCD module is actually 128x160 the output needs to be rotated for 160x128. After you've added the additional /CS cycle to LCD_Data2(), have you noticed the orientation of the display output? If it was correct, then MADCTL should work. Otherwise it would be the default orientation (upright, like an old mobile phone). Have you tried to enable LCD_BGR for the ST7735 driver to reverse the color order?
... 1.12k OF
I have the sneaky feeling that the unknown IC on the GM328A's LCD module might be an MCU translating ST7735 commands for some other LCD controller.
Maybe the other LCD controller plus MCU are cheaper than an ST7735?
This additional functions are a part of m1.38 or higher, is it now a new SW-mix from the Chinese clones?
just for fun, i flashed your "Original Firmwarefiles" to my "GeekTeches GM328A" with a LCD 128X160p SPI Color TFT Module and ST7735 Controller:
It runs.
1.) The function >DS18B20 (1-Wire Digital Thermometer Sensor) works fine
2.) The function >IR_Decoder fails
3.) The function >IR_Encoder fails
4.) The function >DHT11 fails
This additional functions are a part of m1.38 or higher, is it now a new SW-mix from the Chinese clones?
Now as i wondering about this cheapish thing on my desk, question just from pure curiosity, why LCD_BGR flag is even implemented? Is this used in some cases at all? If the software works in RGB, woudn't be better to have LCD_RGB flag and implement it by the software, in some similar way i did it?
Edit:
Nah... My logic is broken now, woudn't be better to still have flag LCD_BGR, but implemented by the software?