When I started to add support for graphic displays, I've renamed the old firmware to "classic" and the new one became "trendy". The classic edition supports ATmega 168/328 and 2x16 HD44780 compatible displays. For the graphic displays I had to add an abstraction layer, which was too much for an 168. So the trendy edition was 328 only at first (now it's 328, 324, 644 & 1284). Of course, it still supports HD44780 based displays, up to 4*20. Since all clones got a 328 meanwhile, I've dropped the parallel releases after a while. So "trendy" is the active one. I was thinking about going back to the former naming (just m-firmware), but I don't know if it might confuse users or not.
Regarding the k-firmware, it's the other way around. The control logic and things like the abstraction layer for displays are quite different, and merging both branches into one would take a huge effort. Anyway, competition creates progress
I think it would be less confusing to remove the "trendy" suffix, and just note somewhere clearly that 1.xx is the last version that supports the 168. BTW, if it's abstracted in the newer versions, can't one conditionally compile with just the segmented display code?
Competition can drive progress, but also hinder it, especially with small dev groups.
Regarding the k-firmware, it's the other way around.
Oh, sorry. I mixed you up with M.F.
What do other users think about dropping the "trendy" suffix?
BTW, if it's abstracted in the newer versions, can't one conditionally compile with just the segmented display code?
The code for driving HD44780 based displays is the smallest anyway, since it doesn't got the character bitmaps, just a few symbols. Adding an #ifdef orgy to allow to skip the display abstraction layer would make the code much more muddled in my opinion. And the abstraction layer also takes care about muli-line displays. Otherwise we would need a second #ifdef orgy for 4*20 displays. Too much trouble for saving about 500-700 bytes, IIRC.
Then we should keep "#define LCD_RES PD0". If LCD_RES is set to PD4, which isn't connected to the LCD module, the pin doesn't contol anything, besides creating some additional heat in the bottom resistor of the frequency counter's input voltage divider. So setting PD0 would increase the run time of the battery
@madires:
The "Clones" file in ComponentTester-trendy-1.25m.tgz is still showing the wrong "white screen" PD4 setting instead of PD0 for LCD_RES.
Ran into the problem today with my AY-AT.
Could you please correct that in the next version?
Of course, it's already fixed in the Clones file for 1.26m, which will be released when I've sorted out the compensation for the inductance measurement.
Too much trouble for saving about 500-700 bytes, IIRC.
I meant the reverse, excluding the pixel-display code to allow supporting the 168. I'm not familiar with the code, so thought it would be something like excluding the pixel-display source file, and maybe ifdefing a few lines in a header file.
But anyway, I was just curious. I don't know if people still need 168 support.
You compile the firmware for a specific display controller anyway. When you choose the HD44780, just the code for that controller will be included, and not any code for graphic LCDs.
I was actually considering modifying the firmware to add a 'serial' option for the display, so that you just send it a command (test component) and it comes back with the results. Part of a test system I was thinking about.
Anyone done anything similar?
Not yet, but for the ATmega 324/644/1284 based circuit the RXD0 and TXD0 pins are reserved for a serial interface. Currently there's only a software UART in the k-firmware.
Hi, I bought
this ESR meter,
-what is his mark ? M328 ? GM328 ?
-somewhere it is possible to download the latest software for 16MHz crystal ?
I bought it in aliexpress from store "All sea Store" and not everything is OK...
a) unpopulated SMD components
(Seller has the pictures already mounted SMD)
b) 1x missing resistor 33 k? (1x more resistor 3.3 k?)
thanks
that's the "AY-AT" colour tft kit.
it has nothing to do with a GM328 which is completely different and does not use a colour display.
@stj & @milamber - thanks
oscilator is in socket and 16MHz is on way
Back to the inductance measurement. It's a can of worms. I've checked several testers with different PCBs and MCU clocks and found some common pattern of deviations. The compensation logic for the high current check is done, I hope. For the low current check I've added a simple compensation, which still needs more investigation (I have to order some inductors above 10mH). The problem with the inductance measurement is that several things got an impact on the results, and some of them are tester specific. I've choosen compensation offsets which work fine with most of my testers. So please don't be surprised if your tester might need some tweaking.
For the new 1.26m we got following changes:
- Added compensation for inductance measurement (more work required).
- Added Spanish texts. Translation provided by pepe10000@EEVblog.
- Changed FrequencyCounter() to support also ATmega 324/644/1284.
- Fixed problem in inductance measurement logic. Reported by indman@EEVblog.
- Fixed error in voltage reference handling for ATmega 324/644/1284.
- Improved detection of turning velocity of rotary encoder to cope with different values of pulses per step or detent.
- Added hardware SPI to all drivers for SPI based displays.
For the new 1.26m we got following changes:
- Added hardware SPI to all drivers for SPI based displays.
Compiled 1.26m for AY-AT 16MHz and the AY-AT settings from Clones.
@madires: BITBANG SPI takes 5 seconds for one screen refresh (about 10 times slower than in 1.25m). Can you confirm that with your displays?
Just trying to get Hardware SPI running. Compiled it with:
#define LCD_SPI_HARDWARE /* bit-bang SPI interface */
#define LCD_SCL PB5 /* port pin used for SCL & SPI HARDWARE @ SCK */
#define LCD_SDA PB3 /* port pin used for SDA & SPI HARDWARE @ MOSI */
instead of
//#define LCD_SPI_BITBANG /* bit-bang SPI interface */
//#define LCD_SCL PD2 /* port pin used for SCL & SPI BITBANG */
//#define LCD_SDA PD3 /* port pin used for SDA & SPI BITBANG */
and rewired the display to PD2&PD3 pins to PB5&PB3 with the 328er@16MHz. Screen still white - maybe mixed something up with the wiring.
I'll check the ST7735, but hardware SPI won't run with an ATmega 328 because of the circuit's pin assignment.
Hi, madires! Thanks for really lot of work in the new version!
Inductance measurement perfectly works, I didn't do any settings in addition.
I received a new kit yesterday to replace an old one I destroyed (rolled over it with a chair).
I picked up one similar to
this.
The kit was missing a few parts, it contained only 1 capacitor for the crystal, but it was missing the crystal, and sent 2 33K resistors, but the board is marked 3K3.
Question is: Which should be right? Kit contents, or board silk screen?. Sadly, no schematic from vendor, no response either (not really expected it).
Since the crystal is missing, would it be worth putting a 16mhz crystal in, instead of 8mhz? (I understand I'd need to load a different firmware.)
Compiled 1.26m for AY-AT 16MHz and the AY-AT settings from Clones.
@madires: BITBANG SPI takes 5 seconds for one screen refresh (about 10 times slower than in 1.25m). Can you confirm that with your displays?
I've checked the ST7735 and haven't seen any difference in display performance between 1.25m and 1.26m.
I didn't note any difference in the display speed of operation 1.25 and 1.26 too
I bought one of these types of devices a few years ago and it helped me test a number of components and fix a TV Power supply. I am not sure how reliable or accurate they are but it was cheap. Here is the video on it. Looks like it fits some of those ready made case designs above. Mine didn't come in a case... Which would have been nice to house the 9V battery and also protection.
https://youtu.be/ZUq6QDuSbfYSent from my iPhone using Tapatalk
would be nice to have a compilation for Example : an 128x64 graphic lcd based on ks0108
they are cheap for 10$ on Ebay
bigger is better loll
I have a old mega 2560 sitting duck in my drawer ...