Hi, I have built this clock (http://www.avr-tutorials.com/pro...) and it works but there is a strange issue, all 3 units digits are significantly less bright than tens digits, against day light I can hardly read them. Can somebody help me to resolve this issue? Thank you!
units digits less bright than tens digits
The Displays are being multiplexed & each one is only active for a short period my guess is that the bright display is being enabled for a longer period than the others.
Why this should be would depend on the exact structure of the program driving them
Love the lack of any current limiting on the AVR outputs.
I am gobsmacked by the poor quality of "tutorials". There are SERIOUS electrical errors with the schematic.
.
The sofrware is fairly crap too. You would normally multiplex the display with a Timer ISR() from a digit buffer. In fact you would probably use the same Timer as the clock.
.
Your software relies on the time to calculate each segment for a digit. In fact the brightness depends on how long the next digit calculation takes.
.
David.
I am gobsmacked by the poor quality of "tutorials".
But David, it clearly states at the top of the site...
Love the lack of any current limiting on the AVR outputs.
That goes right back through their general 7-seg "tutorial": http://www.avr-tutorials.com/int...
To their LED "tutorial": http://www.avr-tutorials.com/int...
They clearly have misunderstood the AVR datasheet:
AVR microcontrollers such as the ATMega8515 only supply a current of about 20mA and so we can drive an LED directly from the microcontroller port eliminating the resistor.
Also, each whole digit is driven from one Port C pin - so the brightness is going to vary with how many segments are ON ...
The LEDs aren't specified - are they identical?
Even if they are identical, there will be variations ...
Look at the other "projects" on their website. They are so full of errors that it is difficult to know where to start.
.
@V1047,
I suggest that you look for another website. We are happy to help with problems. But it is cruel for a "AVR Tutorial" site to provide such crap to beginners.
.
David.
I would start by adding a series resistor to each of the port B (B0-B6) pins, start with 330 ohm resistors, you may have damaged your MPU.
Then do as David suggested and re-write the program to use a timer interrupt for display mux timing so it is independent from the main loop timing.
Ask questions if you get stuck.
Jim
I think the most important step is : Find a better Tutorial site.
Yes, I/we could go through all the errors in this project. But it is best to learn from a good tutorial first. You can always shoot yourself in the foot later.
Google for "clock 7-segment". The schematic will contain resistors and capacitors. Post a link if you want any "approval".
David.
Look at the other "projects" on their website. They are so full of errors that it is difficult to know where to start.
.
@V1047,
I suggest that you look for another website. We are happy to help with problems. But it is cruel for a "AVR Tutorial" site to provide such crap to beginners.
I agree , these tutorials are awful
.
The disclaimer :
...therefore strictly at your own risk.
How about one like this!
feel free to substitute any AVR of your choice.
Jim
How about one like this!
Full article: http://members.ziggo.nl/electro1/avr/avrclock.htm
Note the segment resistors : 7 x 180 Ohm.
Any 7-segment display must have segment resistors.
You can avoid the BC327 transistors because the 180R resistors limit the current to about 14mA per segment. The AVR is able to drive an "8" quite safely directly from the PORTA "segment" pins. An "8" has all 7 segments lit at once i.e. 7 x 14mA = 98mA. The transistors are needed for the "digit" pins because 98mA is too much for one AVR pin.
David.
Edit. Massive brain-fart. I have corrected my original post.
The RES original uses white LEDs - which tend to have a relatively high forward voltage.
Other LEDs, with lower forward voltage, could use a higher series resistor - such as the 330 ohm mentioned earlier ...
My 14mA calculation was for Vf = 2.5V with VCC = 5V. i.e. (5 - 2.5) / 180R = 14mA
14mA peak segment current means 3.5mA average current with a 4-digit multiplex. Should be bright enough for indoor use.
@V1047,
Don't worry about the technical details for white, red, blue, ... LED 7-seg..
Just find a good tutorial site. And build the exact schematic. Resistors from 180R to 330R are fine without transistors.
If the schematic has transistors, resistors from 47R to 330R would be fine.
David.
Edit. Corrected the same brain-fart as in my earlier message.
If I were building that circuit today, I would use one of the "logic transistors with built in bias resistors", fewer parts to mess with and lower BOM cost possibly.
Jim
Holy crap, this has got to be a joke. No resistors on the segments or LEDs on any of the projects, as noted, and:
- no bypass caps
- VCC pin connected to +5V through a resistor (who needs LED resistors? I've already got one on VCC!)
- RESET connected to VCC pin (but to +5V through that resistor!)
- Only one GND pin connected
- AVCC not connected
Astonishing.
I think the most important step is : Find a better Tutorial site.
+1000
That site should be held up as an example. In fact, someone should mirror it before the owner takes it down out of shame.
That circuit had a liberal amount of 'muntzing' done to it. Google that one!
I just posted about a Charlieplexing demo board I built which was the result of a bit of muntzing ;-)
The OP was gone with the wind while you guys discussing it. lol
MG
The OP was gone with the wind while you guys discussing it. lol
MG
Off course, because people can find these threads in a google search, so the answers are not just for the OP.
I will add that the AVR pins have some impedance, I think about 20-30 ohms, that should be taken into account when choosing current limiting resistors.
DNS lookup on that site says:
Domain Name: AVR-TUTORIALS.COM Registry Domain ID: 1636747517_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.enom.com Registrar URL: www.enom.com Updated Date: 2017-01-10T05:06:34.00Z Creation Date: 2011-01-25T00:39:00.00Z Registrar Registration Expiration Date: 2020-01-25T00:39:43.00Z Registrar: ENOM, INC. Registrar IANA ID: 48 Reseller: NAMECHEAP.COM Domain Status: ok https://www.icann.org/epp#ok Registry Registrant ID: Registrant Name: LEONARDO CLARKE Registrant Organization: Registrant Street: 19 SEIVWRIGHT DRIVE Registrant City: KINGSTON 11 Registrant State/Province: P Registrant Postal Code: KNG 11 Registrant Country: JM Registrant Phone: +1.8768878545 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email: email@YAHOO.COM Registry Admin ID: Admin Name: CLARKE Admin Organization: Admin Street: 19 SEIVWRIGHT DRIVE Admin City: KINGSTON 11 Admin State/Province: P Admin Postal Code: KNG 11 Admin Country: JM Admin Phone: +1.8768878545 Admin Phone Ext: Admin Fax: Admin Fax Ext: Admin Email: email@YAHOO.COM Registry Tech ID: Tech Name: LEONARDO CLARKE Tech Organization: Tech Street: 19 SEIVWRIGHT DRIVE Tech City: KINGSTON 11 Tech State/Province: P Tech Postal Code: KNG 11 Tech Country: JM Tech Phone: +1.8768878545 Tech Phone Ext: Tech Fax: Tech Fax Ext: Tech Email: email@YAHOO.COM Name Server: NS1.BLUEHOST.COM Name Server: NS2.BLUEHOST.COM
<mildly racist comment avoided>
I think about 20-30 ohms
Correct. If you look at the figures for pin driver strength, the voltage drop at VCC=5V and ISOURCE=20mA is about 0.5V. E = IR, R = E/I, R = 0.5/0.02 = 25. This is temperature dependent, and also VCC dependent.
My 14mA calculation was for Vf = 2.5V with VCC = 5V. i.e. (5 - 2.5) / 180R = 14mA
14mA peak segment current means 3.5mA average current with a 4-digit multiplex. Should be bright enough for indoor use.
Wouldn't segment current be less? Vce isn't zero.
(5 - 2.5 - 1.2) / 180R = 7 mA
These are always rule-of-thumb calculations. e.g.
Vf = 2.5V for a Red LED
Vce(sat) = 0.2V
VCC = 5V
A regular junction transistor is unlikely to have a Saturation voltage more than 0.5V
White and Blue LEDs probably have higher Vf.
Quite honestly, the 180R is a very reasonable value. And the calculation will be good enough.
It gets more critical with VCC = 3.3V and Vf = 3.0V. Ohms Law gives a small value for the Resistor. (3.3 - 3.0)/0.014 = 21R
Change the Blue LED to a Red LED and the current increases substantially.
I suggested that a beginner should find a proven schematic and use exactly the same components.
The original designer would have selected appropriate LEDs, transistors, resistors, ...
David.
Thanks for replying. To be clear, I'm just trying to understand the circuit. I'm not trying to second guess the design or the advice given in this thread (which I agree with).
I don't believe the transistor will be in saturation. The collector being tied to ground ensures base voltage will always be >= collector voltage and the junction won't be forward biased.
Vce in this circuit seems to be set by Vbe (0.7V or so) plus voltage across the 6.8k resistor (somewhere around 0.25V).
That circuit had a liberal amount of 'muntzing' done to it. Google that one!
Let's see what happens if I clip out this part...
I don't believe the transistor will be in saturation. The collector being tied to ground ensures base voltage will always be >= collector voltage and the junction won't be forward biased.
Vce in this circuit seems to be set by Vbe (0.7V or so) plus voltage across the 6.8k resistor (somewhere around 0.25V).
It actually seems even worse than this. If we start with a guess of Vce = 1V, that gives a segment current of about 8mA. If all 8 segments are on, that's 64mA through the transistor. Assuming a beta of 100, that's 0.64mA of base current, across the 6.8k base resistor. That means the base will actually be over 4V above ground (assuming the AVR output is driving all the way down to 0V). Of course, the emitter will be even higher. The end result is that the digit current will be limited (because of those base resistors) to an extremely low value. Somebody let me know if my analysis is wrong. At the very least, the base resistors need to be removed, but really, get rid of the emitter follower digit transistors and just put in NPN transistors (which WOULD need base resistors).
You're talking about the circuit in #12? Yes, it doesn't make sense to use PNP transistors like that. Must be a mistake and they meant NPN.
The schematic says "Common Cathode" for the display. So the schematic should be:
NPN transistor e.g. BC337. Emitter = GND. Collector = COMMON_CATHODE. Base = 6k8 resistor. Segments active-high. Digit select active-high.
If you choose a Common Anode display:
PNP transistor e.g. BC327. Emitter = VCC. Collector = COMMON_ANODE. Base = 6k8 resistor. Segments active-low. Digit select active-low.
Common Anode displays are used with an 8051 (because it can only sink current i.e. active-low)
AVRs can work with both styles of Display. You simply XOR with 0xFF if you need to invert the logic.
NPN transistors are generally cheaper. And more likely to be in your spares box.
The moral of the story is : Don't trust every schematic that you find on the Internet.
I always choose to copy a proven design e.g. from a commercial dev board.
David.
A friend once built a digital clock & complained that the readout was quite dim...he asked me if I had any ideas. I took a look & told him the issue was he didn't use any LED resistors...it took him a while to figure out how lack of resistors made the readout dim & (getting dimmer).
You're talking about the circuit in #12? Yes, it doesn't make sense to use PNP transistors like that. Must be a mistake and they meant NPN.
It's reasonable to use PNP like that but the base resistor should be very low to reach full saturation. 6k8 is too high. The PNP will sweat.
But look at the very low current draw of leds then 6k8 is still acceptable.
.
Yes usually NPN is use for current sink but if the driver is active low then PNP is the choice to eliminate the inverter.
.
MG
The actual configuration in #12 is an "Emitter Follower". You would normally have no Base resistor at all. kk6gm's explanation in #29 shows the problem with the Base resistor.
My guess is that the schematic in #12 intended to use a NPN.
MicroGyro's reason for digit active-low looks like a hardware approach to a software problem.
Changing from active-high to active-low in software is one C statement. There is no need for a hardware inverter.
You can even alter the invert / non-invert behaviour at runtime with software. e.g. with segments or digits.
David.
You are right mr David. I absolutely agreed.
I'm trying to understand the author's reason while designing the circuit. We can't see the code so we don't know if the author do that on purpose or don't know how to invert the output. Or maybe a 8051 guy trying Tiny?
.
MG
No, actually a PNP in that configuration will never reach saturation even without a base resistor. When you connect the base to ground, that is, to the collector, it will become a diode.
BJTs in diode configuration do not become saturated.
Hi, thank you for replies. I know that digits connected this way cannot work very well, agree that transistors should be used for digits and resistors on segments, I was expecting to not have a constant brightness of each digit because of this kind of connection, I tested this only to learn about programing AVR and this version was easier to set on a breadboard. The AVR is still alive, each LED receives low voltage due to fast multiplexing so the current drawn from AVR is low too. What I wanted to understand is why there is so much difference in the time to calculate units and tens digits, as I read on many sites this is the most used way to display 2 digits (see below), of course I used same type of display for all digits.
SegDataPort = DigitTo7SegEncoder(seconds%10,1);
SegDataPort = DigitTo7SegEncoder(seconds/10,1);
I have another problem, hope you can help, sorry if this is not the best topic for it. I am also looking to learn more about using graphic LCDs, I use one based on RA8835 and it works, I can initialise it and print some text or draw lines or other things. I am looking now to use bigger fonts but what I could do until now was not successful. Please take a look and let me know what is wrong, using this I get only random pixels on the display in the defined area 16x24 pixels. I took this BITMAP function from the libraries for my type of display, others (draw lines for example) works well but not this one.
int main(void)
{
INIT();
CLEARTEXT();
CLEARGRAPHIC();
TEXTGOTO(2,2);
WRITESTRING("Font Test");
while(1)
{
char Bitmap_2[] =
{
// @0 '2' (16 pixels wide)
0x03, 0xF0, // ######
0x0F, 0xFC, // ##########
0x1C, 0x1E, // ### ####
0x38, 0x0E, // ### ###
0x38, 0x07, // ### ###
0x70, 0x07, // ### ###
0x70, 0x07, // ### ###
0x00, 0x07, // ###
0x00, 0x0F, // ####
0x00, 0x0E, // ###
0x00, 0x1E, // ####
0x00, 0x3C, // ####
0x00, 0x78, // ####
0x00, 0xF0, // ####
0x03, 0xE0, // #####
0x07, 0xC0, // #####
0x0F, 0x80, // #####
0x1F, 0x00, // #####
0x3C, 0x00, // ####
0x78, 0x00, // ####
0xF0, 0x00, // ####
0xFF, 0xFF, // ################
0xFF, 0xFF, // ################
};
BITMAP(Bitmap_2,40,40,16,24);
}
}
void BITMAP(char * bmp, int x, int y, int width, int height)
{
unsigned int i, j;
for(i = 0; i < height ; i++)
{
GRAPHICGOTO(x, y+i);
WRITECOMMAND(MWRITE);
for(j = 0; j < width/8; j++)
{
WRITEDATA(READBYTEFROMROMMEMORY(bmp+j+(40*i)));
}
}
}
PNPs do my head in. Look at a regular NPN Emitter Follower. Collector to VCC, Emitter to GND via 50R load. Base to Vin.
.
If Vin < 0.6V there is no base current. Vload = 0V.
If Vin >= 0.6V, there is sufficient Vbe for base current to flow and Collector current will be hFE × Ibase.
Vload will track the Vin voltage less the Vbe drop. e.g. when Vin = 5V, Vload will be about 4.3V
.
Yes, I quite agree. The transistor will never saturate. It will simply draw as much Base current as required. i.e. Iload ÷ hFE
I would have to check the BC337 datasheet, but I guess that @ 100mA collector current, hFE >= 100 and Vbe is about 0.7V
.
If you have followed my logic for NPN, you just invert everything for PNP. Transistors are happier when driven hard into saturation or turned off completely. The BC337 / BC327 has a reasonable power dissipation and reasonable hFE. So it should "work" (with no Base resistor).
.
With the 6k8 Base resistor, you will have a bigger drop between Vin and Vload
.
Untested. I can't be bothered to dig out my 40year old scope.
.
David.
As explained by everyone. Your "tutorial schematic" is pants.
.
Normally, you only calculate the actual segments when you write to the 4-byte segment buffer e.g. once a second.
The multiplex ISR() will be every 5ms. There is no point in doing 200 lookup calculations every second.
.
David.
Thanks again David for advises. Can you please take a look in my previous post, I edited and added another problem I have. Wish you All a nice Sunday!
Life is much easier with an Arduino. You can install proven libraries with the Library Manager.
You can run the examples supplied with a library.
You can just quote the library name (if recognised by the Library Manager)
Or post a link to the actual code you are using.
.
I do not know what AVR, what library, ... you are using.
Please ZIP up the complete buildable AS7 project and attach the ZIP file.
.
If you have a small question, paste your code into a CODE window. It makes it easier to read.
.
As a general rule, you find a ready made font that is compatible with your library code.
Your data is reasonably easy to edit by hand. It does not suit your controller hardware.
.
David.
I am using now an Atmega16, please see the attachment. Yes, I think you are right about arduino, I learned this much later after reading many things about micro controllers but I have already started on this path. In the past it took me tens of hours, first to initialize my GLCD, then to display something on it, I am sure finally I will manage to do this too, each new step brings me more knowledges. That bitmap I use as example was produced with a free tool, The Dot Factory.
Attachment(s):
I don't have a RA8835.
Your project would normally have a RA8835_INIT.c and a RA8835.h file.
It is NOT good practice to put executable code in an H file.
All the same. I do it sometimes (with fonts).
What result do you see?
Your "2" is 16x23 (W x H)
The BITMAP() function looks wrong to me.
Where did you get this file?
What does WRITESTRING("Font Test"); do?
David.
Please see the picture. This is the source for that function http://en.radzio.dxp.pl/sed1335/
Attachment(s):
Hi, in the meantime I made my big digit "manually" so I can understand better how should be the BITMAP() function but still cannot get it done. Maybe somebody can advise.
#include "RA8835_INIT.h" #define F_CPU 4000000UL #include <util/delay.h> #include <avr/io.h> #include <string.h> #include <avr/interrupt.h> #include <avr/pgmspace.h> int main(void) { INIT(); CLEARTEXT(); CLEARGRAPHIC(); TEXTGOTO(2,2); WRITESTRING("Font Test"); GRAPHICGOTO(40,70); WRITECOMMAND(MWRITE); WRITEDATA(0x03); GRAPHICGOTO(49,70); WRITECOMMAND(MWRITE); WRITEDATA(0xF0); GRAPHICGOTO(40,71); WRITECOMMAND(MWRITE); WRITEDATA(0x0F); GRAPHICGOTO(49,71); WRITECOMMAND(MWRITE); WRITEDATA(0XFC); GRAPHICGOTO(40,72); WRITECOMMAND(MWRITE); WRITEDATA(0x1C); GRAPHICGOTO(49,72); WRITECOMMAND(MWRITE); WRITEDATA(0x1E); GRAPHICGOTO(40,73); WRITECOMMAND(MWRITE); WRITEDATA(0x38); GRAPHICGOTO(49,73); WRITECOMMAND(MWRITE); WRITEDATA(0x0E); GRAPHICGOTO(40,74); WRITECOMMAND(MWRITE); WRITEDATA(0x38); GRAPHICGOTO(49,74); WRITECOMMAND(MWRITE); WRITEDATA(0X07); GRAPHICGOTO(40,75); WRITECOMMAND(MWRITE); WRITEDATA(0x70); GRAPHICGOTO(49,75); WRITECOMMAND(MWRITE); WRITEDATA(0x07); GRAPHICGOTO(40,76); WRITECOMMAND(MWRITE); WRITEDATA(0x70); GRAPHICGOTO(49,76); WRITECOMMAND(MWRITE); WRITEDATA(0x07); GRAPHICGOTO(40,77); WRITECOMMAND(MWRITE); WRITEDATA(0x00); GRAPHICGOTO(49,77); WRITECOMMAND(MWRITE); WRITEDATA(0X07); GRAPHICGOTO(40,78); WRITECOMMAND(MWRITE); WRITEDATA(0x00); GRAPHICGOTO(49,78); WRITECOMMAND(MWRITE); WRITEDATA(0x0F); GRAPHICGOTO(40,79); WRITECOMMAND(MWRITE); WRITEDATA(0x00); GRAPHICGOTO(49,79); WRITECOMMAND(MWRITE); WRITEDATA(0x0E); GRAPHICGOTO(40,80); WRITECOMMAND(MWRITE); WRITEDATA(0x00); GRAPHICGOTO(49,80); WRITECOMMAND(MWRITE); WRITEDATA(0X1E); GRAPHICGOTO(40,81); WRITECOMMAND(MWRITE); WRITEDATA(0x00); GRAPHICGOTO(49,81); WRITECOMMAND(MWRITE); WRITEDATA(0x3C); GRAPHICGOTO(40,82); WRITECOMMAND(MWRITE); WRITEDATA(0x00); GRAPHICGOTO(49,82); WRITECOMMAND(MWRITE); WRITEDATA(0x78); GRAPHICGOTO(40,83); WRITECOMMAND(MWRITE); WRITEDATA(0x00); GRAPHICGOTO(49,83); WRITECOMMAND(MWRITE); WRITEDATA(0XF0); GRAPHICGOTO(40,84); WRITECOMMAND(MWRITE); WRITEDATA(0x03); GRAPHICGOTO(49,84); WRITECOMMAND(MWRITE); WRITEDATA(0xE0); GRAPHICGOTO(40,85); WRITECOMMAND(MWRITE); WRITEDATA(0x07); GRAPHICGOTO(49,85); WRITECOMMAND(MWRITE); WRITEDATA(0xC0); GRAPHICGOTO(40,86); WRITECOMMAND(MWRITE); WRITEDATA(0x0F); GRAPHICGOTO(49,86); WRITECOMMAND(MWRITE); WRITEDATA(0X80); GRAPHICGOTO(40,87); WRITECOMMAND(MWRITE); WRITEDATA(0x1F); GRAPHICGOTO(49,87); WRITECOMMAND(MWRITE); WRITEDATA(0X00); GRAPHICGOTO(40,88); WRITECOMMAND(MWRITE); WRITEDATA(0x3C); GRAPHICGOTO(49,88); WRITECOMMAND(MWRITE); WRITEDATA(0x00); GRAPHICGOTO(40,89); WRITECOMMAND(MWRITE); WRITEDATA(0x78); GRAPHICGOTO(49,89); WRITECOMMAND(MWRITE); WRITEDATA(0x00); GRAPHICGOTO(40,90); WRITECOMMAND(MWRITE); WRITEDATA(0xF0); GRAPHICGOTO(49,90); WRITECOMMAND(MWRITE); WRITEDATA(0X00); GRAPHICGOTO(40,91); WRITECOMMAND(MWRITE); WRITEDATA(0xFF); GRAPHICGOTO(49,91); WRITECOMMAND(MWRITE); WRITEDATA(0xFF); GRAPHICGOTO(40,92); WRITECOMMAND(MWRITE); WRITEDATA(0xFF); GRAPHICGOTO(49,92); WRITECOMMAND(MWRITE); WRITEDATA(0XFF); while(1) { char Bitmap_2[] = { // @0 '2' (16 pixels wide) 0x03, 0xF0, // ###### 0x0F, 0xFC, // ########## 0x1C, 0x1E, // ### #### 0x38, 0x0E, // ### ### 0x38, 0x07, // ### ### 0x70, 0x07, // ### ### 0x70, 0x07, // ### ### 0x00, 0x07, // ### 0x00, 0x0F, // #### 0x00, 0x0E, // ### 0x00, 0x1E, // #### 0x00, 0x3C, // #### 0x00, 0x78, // #### 0x00, 0xF0, // #### 0x03, 0xE0, // ##### 0x07, 0xC0, // ##### 0x0F, 0x80, // ##### 0x1F, 0x00, // ##### 0x3C, 0x00, // #### 0x78, 0x00, // #### 0xF0, 0x00, // #### 0xFF, 0xFF, // ################ 0xFF, 0xFF, // ################ }; BITMAP(Bitmap_2,40,40,16,23); } } void BITMAP(char * bmp, int x, int y, int width, int height) { unsigned int i, j; for(i = 0; i < height ; i++) { GRAPHICGOTO(x, y+i); WRITECOMMAND(MWRITE); for(j = 0; j < width/8; j++) { WRITEDATA(READBYTEFROMROMMEMORY(bmp + j + (2*i+1))); } } }
Attachment(s):
Your BITMAP() function is expecting data in Flash.
void BITMAP(char * bmp, int x, int y, int width, int height) { unsigned int i, j; for(i = 0; i < height ; i++) { GRAPHICGOTO(x, y+i); WRITECOMMAND(MWRITE); for(j = 0; j < width/8; j++) { WRITEDATA(READBYTEFROMROMMEMORY(bmp+j+(40*i))); } } }
Since you are writing your "2" from SRAM, you would have:
WRITEDATA(*(bmp+j+(40*i)));
In practice, any new font or icon would be stored in Flash memory.
First off, I would get the project structure correct.
David.
Thank you David, this is it indeed. The function still needs a correction to work for me, that "40*i" does not work, it works with "2*i" because I have a 16 pixels width so most probably it should be "(width/8)*i", I will test this with another font. Once I will understand how it works will get to the correct project structure too.
WRITEDATA(*(bmp+j+((width/8)*i)));
it is cruel for a "AVR Tutorial" site to provide such crap to beginners
Another one here: https://www.avrfreaks.net/comment...
Perhaps we need a sticky somewhere on "Tutorial Sites To Avoid" ... ?
Maybe also "Libraries To Avoid"; eg, https://www.avrfreaks.net/comment...
#StuffToAvoid