Dolgin Development Platform (DDP)

 

It is virtually impossible to trace the true origin of any significant achievement as even its creators may not fully understand the source of the inspiration(s) that led to their breakthrough. However, for this gem, I'll pick up the thread in the Spring of 2018...

ACES are introduced to the creation of Printed Circuit Boards (PCBs) in their Grade 11 year. From the outset, they are encouraged to imagine a circuit board that would enhance ALL ACES learning experiences, not just their own. It was in the Spring of 2018, that James Corley (ACES '19, Queen's Comp. Eng. '23) designed a breakout board for AVR's ATtiny'84, perhaps feeling the UNO's ATmega328P was unnecessarily extravagant for many simpler projects. A DirtyPCB rendering of James' breakout board appears to the right and although it proved to be usable, there were a few aspects James would have modified had he revised his design and produced version 2. That never materialized as James moved on to other projects.


Fast forward a year later to the Spring of 2019. Grade 11 student Josh Dolgin (ACES '20), possibly inspired by the potential in what he envisioned in a tiny-based breakout board and/or in James' design, produced a more refined design that was immediately recognized for its potential in providing MCU support for small ACES' devices and for introducing Senior ACES to AVR Assembly language. Again, on its return, Josh soldered up one of his prototypes and it performed as expected. At that point Josh extended permission to have his design modified with the aim of adapting it for use in the ACES III course to introduce students to AVR (mid-level) Register and (low-level) Assembly language programming experiences.

By the time version 5 of the device arrived in the DES in September 2019, we had a platform which could be put into use for the first time in January 2020. As it turned out, the modifications were primarily about tradeoffs between power and ISP access points rather than any deficit of supporting components.

Josh's contribution to the project did not end there. His advanced design skills yielded a specially designed case to support undermounted power and ISP access to the board, thereby decluttering the access to the device from the top. The unique combination of the board and the custom case has justified the rebranding of this insanely useful DES asset as the Dolgin Development Platform.

EAGLE and Fusion 360 design files for this platform (.sch, .brd, and .f3d) can be downloaded for your personal use from,

https://github.com/rsgcaces/AVROptimization/tree/master/DolginDevelopmentBoard

My intent for this repository is to supplement it with your DDP Shield design files coming later this term....


1. DDP: Assembly

Your first (pleasant) task is to prepare the hardware and software environments for the Dolgin Development Platform (DDP). On the hardware side assemble your DDP using the parts supplied to you. See the full Parts Table below, right.

On the software side, within the Arduino IDE, under Tools > Board > Boards Manager, be sure to have installed the latest ATtinyCore library by Spence Konde. You may wish to create a DDP folder within your Work area to hold this term's software investigations. Writing similar high-level code that you have been doing for the UNO, open, modify, save as, and test the Blink sketch to confirm your DPP supports flashing an LED on any of the digital pins available. Uploading code to the DDP is accomplished through the undermounted ISP header using your Sparkfun AVR Pocket Programmer (USBTiny).

Friday's class is a work period to complete these DDP hardware and software preparations as well as allowing DER time for the first stage of the DDP. Submission is due the next day on Saturday January 11.

PARTS TABLE
# DESCRIPTION SUPP.
1 AVR ATtiny84 MCU S
1 IC Socket 14 Pin (CNC Tech) S
1 USB MINI B Connector (Molex) S
1 LM7805 Voltage Regulator S
2 1×8 Female Header S
1 10 μF Electrolytic Capacitor (short) S
1 1 μF Electrolytic Capacitor (short) S
1 2.1 Power Jack (Schurter) S
2 Power (Red) and GND (Black) hookup wire S
1 2×3 Shrouded ISP Header (Wurth) S
1 Dolgin Development Platform Board V5 PCB S
1 Dolgin Development Platform Case with Insets S
4 5mm M3 Black Nylon Mounting Screws S

2. DDP: Testing

With your Dolgin Development Platform environment in place we are now ready to begin exploiting its capabilities. Whereas the Arduino platform has onboard USB to Serial support, our lean DDP relies on ISP programming. For this, you'll use your handy Sparkfun AVR Pocket Programmer, inserting the ISP cable into the under-mounted ISP connector.

Another design feature of the DDP is that once your project is functioning, you can remove the ISP connection, detach the programmer section (pictured to the right) and simply insert its power cable into the Mini B connector on top to power your creation. Very convenient (It's likely clear to you by now that the DDP's access point design decisions that you've encountered already were purposely intended to maintain low headroom on the top of the platform. Hence, you'll have unobstructed access to the ATtiny84's header pins for your future DDP Shield project).

Task.

  1. Click on the image below and familiarize yourself with as much of the ATtiny84's pin arrangement and functionality as possible.

  2. Create a DDP folder within your Arduino sketch folder and condition yourself to placing all of the sketches developed for use on the platform in this folder.
  3. Run through a familiar sequence of devices and high-level programming practices to get acquainted with our new environment. Provide evidence in your first DDP DER entry that you have successfully implemented the following three trials: the single LED blink sketch, the Schaffer Traffic Light, and the Morland Bargraph. For the latter, you'll note that the power supply and digital pins of the ATtiny84 have been broken out in a manner perfectly suited for this device. Be sure to highlight this in your Report. I suggest you showcase the following four Morland Bargraph capabilities,
    1. Simple, recognizable binary sequence or alternating pattern
    2. Shift out 0xFF and demonstrate a 'breathing' bargraph by placing a signal on the 595's output enable pin
    3. Review Adafruit's TMP36 terrific tutorial. Now, what's great about the DDP is that without support of the Serial Monitor, we're (somewhat) blind. However, our Morland Bargraph is an output device that can tell us a great deal if we exploit it correctly. So, wise ACES will, first, familiarize themselves with the TMP36 in a more 'informative' environment. Wire the TMP36 from a breadboard to your Arduino UNO and explore its output with the help of the Serial Monitor. OK, with a better understanding of the device, insert it into a strategic location on the DDP and project the result of an analog reading of the sensor on your bargraph over an appropriate thermal range of your fingers while pinching the device. You can either present the raw readings or tailor it as VU meter with a little math. (map() and constrain() are handy functions for this application as is bit-shifting).
    4. Some other creative and inspiring exercise of your own choosing. Look in your kit and come up with something compelling.

    Finally, pack these four Morland Bargraph exercises into a single sketch with some strong code design decisions. Note, the mark you will receive will be based, in part, on how unique your code is from that of your peers.


3. DDP: CharlieStick (Register-Level Coding )

  1. References
    1. ATmega328P Datasheet. See Section 36 starting on page 612.
    2. ATmega328P Include file: iom328p.h
    3. ATtiny24/44/84 Datasheet. See Section 24 starting on page 182.
    4. ATtiny24/44/84 Include file: iotnx4.h
    5. Search for evidence in the ATtiny84's iotnx4.h file that confirms the information in the adjacent Data Memory Map graphic.
  2. After digesting the previous references you'll appreciate that the header file simply consists of hundreds of #define compiler directives that provide aliases for the specific AVR MCU registers and bit-within-a-byte numbers.
  3. Last fall, in Project 3.2 you were asked to explore Charlieplexing and tasked with implementing our new charlieplexed SimonStick. as Project 3.2.1. As a followup task, Project 3.4.2 asks that you adapt your previous sketch by maximizing your use of Register-Level coding strategies and other #defines from the header file to have your SimonStick function as a VU meter for the TMP36 temperature sensor.
    Note: Both devices are expected to be implemented as DDP appliances. You'll have to think creatively for this.

    Theory JLC Rendering


4. DDP: Intersection Shield

  1. To be continued...

5. DDP: ADC Shield

  1. To be continued...

6. DDP: Legacy Shield

  1. To be continued...

7. DDP: Low-level Assembly Programming

  1. To be continued...