Dual port RAM interface debugs NES games

While writing a game for his old-school NES console, Andrew Reitano realized that live debugging on real hardware would definitely be a step up from the usual software-based fare.

The original solution? Firing variable information out the second controller port to serial every NMI. However, Reitano ultimately decided to take a shot at designing a new Atmel-powered PCB to interface with the console.

“The board routes the left port of the dual port RAM (Cypress CY7C136) to the DIP footprint on the NES and the right port to an AVR (ATmega164 MCU), this allows me to read and write any location at runtime without bus conflicts,” Reitano explained in a recent blog post.

“Control is provided through the UART and two additional pins are soldered directly to the 2A03 to control /NMI and /RESET. AVR control code was written mainly in C with some assembly sprinkled across for the memory control portions.”

The ATmega164 – tasked with “waiting” for serial commands – performs a number of functions including:

• Read/write of any memory location
• Quick dump of an entire 256-byte page
• Freezing of memory addresses (rewriting a single value constantly in the busy loop)
• Single frame stepping by controlling the NMI
• Remote reset of console
• Applying auto increment to tables to a single variable (fun for sine waves on x/y positions)

“[I] had pretty great results with using 250000 baud with the Genesis flasher project which is plenty fast for what I’m trying to do here,” he added. “As far as I can tell from the datasheet leaving CE low shouldn’t have an effect on the opposite port but it most certainly does. Next revision could definitely use a few pullups on the AVR side, other than that I’m pretty happy with the layout.”

Interested in learning more? You can check out the project’s official page here.

Designing UL/IEC/EN60730-compliant appliances with Atmel

UL/IEC/EN60730 are a comprehensive set of safety standards for various household appliances, such as washing machines, stoves and refrigerators.

On a hardware level, key design considerations for UL/IEC/EN60730-compliant appliances include POR, BOD, RAM, Flash, EEPROM, WDT, ADC, clock/zero cross detector as well as immunity from noise, EMC and humidity. Software features typically comprise a 60730 code library, spread spectrum and FMEA (Failure Mode and Effects Analysis).

A number of current-gen Atmel components can be used to design UL/IEC/EN60730-compliant appliances, including ATxmega MCUs, AT42QT14811, AT42QT1244/1245, AT42QT2640 and UL/IEC/EN60730 certified touch controllers.

“Simply put, megaAVR and AVR XMEGA – with application notes (AVR998 and AVR1610) – provide proven solutions to address household appliance design requirements,” an Atmel engineering rep told Bits & Pieces.

“An Atmel-powered platform offers developers access to the most efficient 8-bit microcontroller core; POR, BOD and watchdog with an independent oscillator; integrated RC oscillators, RTC, EEPROM, ADC Converter/Comparator; 25×4 and 40×4 segment LCD driver options, as well as certification of the XMEGA code library.”

In terms of electrical performance, Atmel offers a high current sink and source for GPIO, temperature range from 850C up to 1500C and EMC robustness (low emissions). On the touch side, Atmel provides pre-certified capacitive touch controllers and Failure Mode Effects Analysis (FMEA) module for improved safety.

As noted above, devs can access Atmel application notes for AVR998 and certified AVR1610, including safety related code. Last but certainly not least, manufacturers have easy access to Atmel Studio 6 and its Integrated Development Environment (IDE).

Interested in learning more about designing UL/IEC/EN60730-compliant appliances with Atmel? Be sure to check out the following links below:

• Atmel megaAVR Home Page 
• Atmel AVR XMEGA Home Page
• Atmel Button, Sliders and Wheels Home Page
• Atmel Application Note AVR998 – Guide to IEC60730 Class B compliance with AVR
• Atmel Application Note AVR 1610 – Guide to IEC60730 Class B compliance with AVR MEGA microcontrollers 
• Atmel Home Appliances Home Page

An MCU or MPU, that is the question: Part 1

Selecting the most appropriate device (an MCU or MPU) for a new project or design can be somewhat daunting. Indeed, engineers typically analyze a wide range of variables, including price, performance and power consumption.

To make the process easier, we will examine some of the primary differences between an MCU (microcontroller) and MPU (microprocessor).

“Typically, an MCU uses on-chip embedded Flash memory in which to store and execute its program,” Frédéric Gaillard, product marketing manager and Andreas Eieland, senior product marketing manager, told Bits & Pieces.

“Storing the program in this way means that the MCU has a very short start-up period and can be executing code very quickly. The only practical limitation to using embedded memory is that the total available memory space is finite. Indeed, most Flash MCU devices available on the market have a maximum of two Mbytes of program memory and, depending on the application, this could prove to be a limiting factor.”

In contrast, MPUs are not limited by memory constraints in quite the same way, as they employ external memory to provide program and data storage. The program – typically stored in non-volatile memory such as NAND or serial Flash – and is loaded into an external DRAM at start-up and subsequently commences execution. On a practical level, this means the MPU will not be up and running as quickly as an MCU, although the amount of DRAM and NVM engineers can connect to the processor is in the range of hundreds of Mbytes and even Gbytes for NAND.

Another notable difference between MPUs and MCUs is power consumption methodology. By embedding its own power supply, an MCU is fine with just one single voltage power rail. However, an MPU typically requires several different voltage rails, prompting the use of additional on-board power ICs/converters. And while MPUs do have low power modes there are not as many or as low as the ones you would find on a typical MCU.

“With the external hardware supporting an MPU has an added factor, putting an MPU into a low power mode might also be slightly more complex,” the two explained. “In addition, the actual consumption of an MCU is magnitudes lower than an MPU, in low power mode for example with SRAM and register retention, you can consider a factor 10 to 100. Obviously this is directly related to the amount of RAM an operating system requires and therefore to be powered to resume operation instantaneously.”

Clearly, design specs are critical when it comes time for an engineer to select an appropriate device for a specific application. For example, is the number of MCU peripheral interface channels sufficient? Do marketing specifications stipulate a user interface (UI) capability that is simply impossible with an MCU due to a lack of on-chip memory and performance?

“When embarking on the first design engineers know it is highly likely there will be many product variations,” said Gaillard and Eieland. “As such, it is very possible a platform-based design approach will be preferred. This would stipulate more ‘headroom’ in terms of processing power and interface capabilities in order to accommodate future feature upgrades.”

Want to learn more about the differences between MPUs and MCUs? Stay tuned to Bits & Pieces for part 2 of “An MCU or MPU, that is the question.”

Embedding touch tech in MCU firmware

Atmel’s comprehensive QTouch Library makes it simple for developers to embed capacitive-touch button, slider and wheel functionality into general-purpose AT91SAM and AVR microcontroller (MCU) applications.

To be sure, Atmel’s royalty-free QTouch Library offers several library files for each device, while supporting various numbers of touch channels – thereby enabling both flexibility and efficiency in touch apps. And by selecting the library file supporting the exact number of channels needed, devs can achieve a more compact and efficient code using less RAM.

Simply put, Atmel’s QTouch Library can be used to develop single-chip solutions for many control applications, or to reduce chip count in more complex applications. Meanwhile, the library offers devs the latitude to implement buttons sliders and wheels in a variety of combinations on a single interface.

There is also broad controller support for Atmel MCUs: AT91SAM, tinyAVR, megaAVR, XMEGA, UC3A and UC3B. Up to 64 sense channels are supported for maximum interface sensitivity ( 256-level sliders and wheels require only three channels), while the QTouch Library supports three patented capacitive touch acquisition methods: QTouch, QTouchADC and QMatrix.

In addition, Atmel Adjacent Key Suppression (AKS) technology enables unambiguous detection of button touches for maximum precision, with full debouncing reports for touch buttons helping to ensure single, clean contacts. And last, but certainly not least, a common API across all library versions simplifies development.

Interested in learning more? Additional information about Atmel’s QTouch library can be found here.