My first assumption from the symptom is that you have a single cathode resistor, which would explain everything. However, you say this is not the case and that you have individual 100 Ω resistors on each anode line.
The answer then must be that whatever is driving the cathode can't handle the combined current. Apparently you are driving the cathode with just a microcontroller output, which has insufficient current sink capability. Do the math. You want 10 mA thru each of 7 segments. That means whatever is holding the cathodes low has to be able to handle 70 mA. A microcontroller pin is very very unlikely to do that. See the datasheet.
The solution is to add a transistor that can sink the current from each of the cathode connections:
70 mA is easy for any discrete transistor you will be able to get. Let's say the transistor has a minimum guaranteed gain of 50. That means the base current needs to be 70mA / 50 = 1.4 mA. Figure the B-E junction drops 700 mV. With 3.3 V drive from the micro, that leaves 3.3 V - 700 mV = 2.6 V accross the base resistor. 2.6 V / 1.4 mA = 1.9 kΩ, which is the absolute maximum allowed base resistor. Given that, I'd use 1 kΩ between the digital output and the base.
Note that this will invert the common cathode logic from what you had. The microcontroller output now has to go high to enable a digit.
Since the display includes the Ilitek ILI9320 controller, then your interface requirements are much lower, as the microcontroller no longer has to interface directly with the TFT and instead only talks to the controller chip via a simple interface: either SPI, which takes six wires: RS, CS, CLK, MOSI, MISO and RESET. Or you can use an 8080-compatible parallel interface which takes 13 wires: an 8-bit data bus, and RS, CS, WR, RD and RESET. (There are options to use larger data-buses, up to 18 bits, but I don't recommend that for a low end microcontroller.)
There are two optional interfaces in which the microcontroller generates all of the clock signals (VSYNC, HSYNC and DOTCLK); you don't want to do that since it would require a high-end controller.
So just about any microcontroller will do, however you need to have enough flash memory to hold whatever static items you want to display; for example if you are going to be displaying text then you will need to allocate arrays to store bitmaps for whatever fonts you will use. Even a small font can take 60KB.
One of the advantages of this controller is that includes 172,800 bytes of RAM, which is enough to store 320*240*18 bits. However it is not double-buffered, meaning that when you write to the RAM, it will immediately show up on the screen, and if you updating a lot of the screen, it will be noticeable.
Best Answer
How secure do you want this thing to be, and what are your code size versus space trade-offs? Are you going to be needing sequential numbers only, or values in arbitrary sequence?
Two simple hash-generation approaches are: // Get a random bit via linear congruential generator: int random_bit1(void) { static unsigned long seed; seed = seed*magicConstant + 12345; return (seed >> 31); // Use upper bit--not lower bit! }
To generate a four digit number, use something like the following:
Note that both of the above bit-generation algorithms can be adapted to return the nth value for any arbitrary n in a reasonable amount of time, though the code to do that will be a fair bit more complicated. On the other hand, neither algorithm will be hard to reverse-engineer.
If you're only going to need values in sequence (meaning that after you've outputted the nth thing, you'll never need to output any lower-numbered thing, and you won't mind if computing a higher-numbered thing requires computing all intervening values) it is possible to build up some security by using six or so independent pseudo-random-bit generators (perhaps shift registers with different periods), and then use something like:
Note that for good results there should be some mixing of how random generators get used (note that random3 is used in two different places) but one should avoid feedback paths (none of the random generators affects the shifting of anything which would affect it) unless one has the tools to fully analyze them.