3 Volts, 20 MHz, DIL -- I can has?

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Most peripherals these days are 3.3V.

Meanwhile, I really like the robustness of the Atmega family, and I have a fair amount of code developed for it.

I can run the AVRs at 10 MHz and 3.3 volts, but when talking to things like displays, that makes screen clears painfully slow -- 20 MHz is better (and 50 MHz would be even more so :-)

I am kind-of tired of soldering up level translators -- either resistive dividers, or extra chips -- for every little project.

So, are there AVR parts that run at 20 Mhz, at 3.3V? And, because I haven't taken the jump to reflow soldering (I tried once and it was a disaster,) are those available in DIL packages if so?

I'm wondering whether I need to go to a new architecture to get this. All those Cortex-M0/3/4 devices from different vendors look sweet, except I have to re-do all my code!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, Xmegas run at 3.3V and 32MHz.

Most modern controllers run at 3.3V and lower.

Personally, I think that Atmel are crazy to specify different speeds for > 3.3V. They should simply redesign for 3.3V. I would be very surprised if the 'A' chips could not made for '20MHz @ 3.3V'.

However, given the current spec, wouldn't you be better off running at 12MHz and 3.3V with no level translation?

I think that DIP is a lost cause. You can use an adapter pcb for breadboarding SMD chips.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you want the new features and speed of the Xmega lineup, but do not want to do the SMD soldering, an option would be to purchase one of the smaller "development" boards and solder that to your main PCB.

Xmega Development Boards

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I can run the AVRs at 10 MHz and 3.3 volts, but when talking to things like displays, that makes screen clears painfully slow

OK, I'll bite--

What kind(s) of "displays" are we referring to here?

Are you saying that my 4x20 character LCD with HD44780-compatible controller is slower if the issuer of the Clear screen command runs at 10MHz vs. 20MHz?

Are you saying the same thing with my graphics display with T6963-compatible controller?

Or is the LCD one of the 7-segment type that might be attached to a Mega169?

How slow exactly is "painful"?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
What kind(s) of "displays" are we referring to here?
Possibly colour GLCDs??

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Possibly colour GLCDs??


Why would processor speed affect clear speed?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Because you are writing lots of data to the LCD to "clear" the screen, say ~154K for a 3.2" 240x320 display.

The screen is "cleared" by writing the colour to each pixel.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John,

Perhaps it should be put more bluntly:

You can write to a GLCD faster than any human can read it.
Even an 8MHz AVR writes faster than the GLCD can respond.

So most peripherals can be serviced quite adequately with 8MHz or 20MHz. Ok, 1MHz might be noticeable.

Regular display of information on a GLCD is easy. If you want to redraw a whole screen at 50 frames per second, you need to program with care. (and faster F_CPU is needed)

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, but when clearing a GLCD one can see a "tear" across the screen because of the lack of sync between writing and displaying. This is my experience, anyway, even using a 32MHz XMega. It would help if the LCD "packagers" would make the V sync output available, but they tend not to.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Look at "clear screen" (black) on the 2 Kentec 7 inch videos https://vimeo.com/user2128302 one is for a M128 at 8MHz and the other for a Cortex M0 at 48Mhz.

The M0 suffers from not having continous 8 bit ports (1 port is 12 bits the other 4bits) so there is a lot of bit shifting for every 2 bytes written (1 pixel) it is however faster.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not wanting to drift too far off-topic, but it's a shame, IMO, that the GLCD controllers don't offer an 8 bit data interface that accesses a palette of pre-defined colours. Or some sort of internally latched colour data, for fill purposes.
On the other hand, maybe some do. Not the ones I've looked at, though.

John

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds like what you're wishing for is the VGA video cards :-) I miss those good ol' days too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for all the answers!

Yes, I'm talking about $15, 320x240, TFT color LCDs, running in 16-bit color mode. From an Atmega, you have to write them in 8-bit mode, which means you write two bytes per pixel, which means bus-out, lower write, raise write, bus-out, lower write, raise write, loop to next pixel, which means that you're over a million cycles by the time the whole screen is cleared. This is significantly slower than screen refresh, and thus you will see an actual "filling" effect rather than the screen just "clearing." This is at 20 Mhz -- at 8 Mhz, it may actually be slow enough to impact the usability of the device.

Nevermind actually trying to paint the screen with real data -- reading fonts from PROGMEM to display various texts and graphics is going to be a lot slower. Luckily, you usually have to update less than the entire screen. But something big, like a clock that covers the screen, will not be smooth in update. These LCDs also only allow you to overwrite entire square areas, so anything diagonal will be extremely inefficient, as you have to rewrite the entire bounding box, or spend lots of cycles setting up small parts of it. There's not enough space on the Atmega to store the entire framebuffer in pixel format.

Personally, I think the real shame is that the LCD controller vendors don't include a few simple blit commands. "Fill the current write window with color X" ought to be a few hundred gates, and would significantly increase the value/capability of the controller.

Using faster controllers that are SMD is significantly more expensive than buying 328p devices in bulk. Sure, I could write everything on a Raspberry Pi, but then each little thing that I want to keep starts at $35 + connectors, plus the RPi can't actually do real-time as well as the Atmega, so I probably end up adding an Atmega TOO. And I have a lot of code already written for the Atmegas.

12 MHz at 3.3V, or porting to Xmega and sucking up the SMD cost, huh? I may just have to do one of those. Perhaps I should whip up a small proto/breakout board with space for an Xmega in the center, and have it made in China for $25 per 10... But then what do I do with my tube of 328s still left? :-)

There are lots of nice devices if I want to switch architectures. Cortex-es galore, plus that Cypress hybrid CPU / FPGA thing with "soft defined peripherals." Too bad that most of them use Windows IDEs -- can anyone recommend something in particular that has good GCC, make, and Linux support?