|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 uniquecombination 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,
My intent for this repository is to supplement it with your DDP Shield design files coming later this year....
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.
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).
0xFFand demonstrate a 'breathing' bargraph by placing a signal on the 595's output enable pin
constrain()are handy functions for this application as is bit-shifting).
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.
DDP: USB to TTL Serial Cable
A solution to the benefit of serial streaming to the Arduino Serial Monitor and Plotter from the DDP comes in the form of a USB to TTL Serial Cable from Adafruit (below, left). The basis for this discovery comes in the form of this instructable from OldArkie in whch he describes a similar approach from the ATtiny85. The image below, right (click to enlarge) is of a dynamic application of a thumb joystick in a DDP running a sketch (
SerialOutputDDP.ino) that streams the 2D coordinates to a Processing application (
CircularTrigFunctions.pde) developed to introduce students to the true origin of the six trigonometric functions: The Circular Functions. USB cable connections to the DDP can be determined by looking closely at the photo. The White 5V wire is not connected.
I'll provide a demonstration in class on the resumption of classes after the March Break 2020. Both sketches are available from DDP's GitHub repository.
|Adafruit USB-to-TTL Serial Cable #954||DDP Control over the Processing Circular Function Sketch|
3. DDP: CharlieStick (Register-Level Coding)
#definecompiler directives that provide aliases for the specific AVR MCU registers and bit-within-a-byte numbers.
#defines from the header file to have your SimonStick function as a VU meter for the TMP36 temperature sensor.
An Appliance is an ACES term for a PCB-based device that is inserted vertically into a SINGLE female header on either the UNO or the DDP. The Schaffer Traffic Light (STL), the Morland Bargraph (MB) and the CharlieStick, are three examples.
A Shield is the conventional Arduino term for a PCB-based device that spans BOTH female headers, horizontally, on the UNO. ACES have adopted this term in reference to a device that spans both headers on the DDP.
In late 2019, two DDP Shields were developed for ACES to continue to develop their MCU prototpying skills. By the end of the term, after working extensively with these two shields, every ICS4U ACE will have the opportunity to add to the inventory of our DDP Shields through the creation of their own, original, Legacy Shield for future ACES to benefit from.
4. DDP: ADC Shield
This Shield exploits the 10-bit Analog-to-Digital Conversion feature of the ATtiny84 (oddly enough, the DIP14 ATtiny84 offers 8 separate ADC channels as compared to the DIP28 ATmega328P's 6.)
#definethe corresponding port/pin usage. Note. When you create your own DDP Legacy Shield do not overlook the benefits of smart silk-screening to those that follow you.
5. DDP: Intersection Shield
In this Shield segment, our Schaffer Traffic Light (STL) gets a serious upgrade. Watch this clip of the simulation, DDP: Intersection Shield (1:08)
shiftout()function discussed previously in class.
6. DDP: Legacy Shield
ACES' tradition reflects a popular culture trope in which Master Craftsmen Make Their Own Tools. A quick review of the ACES PCB Archive supports this claim. In this latest attempt to enrich the engineering experience of the ACES that follow, you have the privilege of being the first group of Sr. ACES to develop an original set of DDP Shields.
What is unique about this PCB task is the myraid of constraints placed on the design of the PCB Shield, not the least of which are its dimensions. Furthermore, by the time ACES are ready to assemble their DDP Shield, you can assume they have SMD/T experience.
7. DDP: AVR Assembly Language Programming
7.1.1 GPIO Port Summaries
7.1.2 Summary: AVR Assembly Instruction Set
7.1.3 Detailed: Online AVR Assembly Instruction Set
7.1.4 Full Manual: AVR Assembly Instruction Set
7.2.1 Inline (8-bit) AVR Assembly (within the Arduino IDE)
In our first few AVR assembly exercises you will explore how the AVR-gcc toolchain permits the interspersing of assembly language statements amongst Arduino C statements through the use of the
asm () macro. This blog offers a primer...The following video provides a good foundation for AVR Assembly concepts in a little more detail than is required at the moment but, nevertheless, is highly instructive: Intro to Arduino Inline Assembly
22.214.171.124. The Fastest! Blink
In a previous exercise you successfully confirmed that setting a bit in an AVR Port's PIN register, toggled the corresponding bit in its PORT register, leading to the fastest way to blink an LED. In this first exercise we'll perform the same task, in assembly language.
InlineAssemblyfolder, create a New Project called
setup()function , add an
asm volatile ()macro that declares PORTA, pin 0, for output.
loop()function, add an
asm volatile ()macro that writes 1 to PINA, pin 0.
delay()function add a 1 second delay between loop iterations.
126.96.36.199. (All Assembly) Delay
A clock cycle is a tick of the MCU's oscillator. The source of these ticks typically comes from the MCU's external crystal or internal RC clock.
As you can imagine, the benchmark measure of the efficiency of any code sequence rests with determining the number of MCU clock cycles (or simply clocks) it takes to execute, not the absolute amount of time the code takes to execute. Courses in your university Comp. Eng, program will require you to explore this this so let's get a simple taste, now. Further reading: AVR-libc Benchmarks
delay(ms) function is handy, but unproductive, as all it does is waste clock cycles. Nevertheless, exploring an 'All AVR Assembly' equivalent to the
delay(ms) function is instructive for our ends. So, although the previous exercise confirmed that inline assembly and high-level C can coexist, this exercise allows you to explore replacing the high-level
delay(ms) function altogether through additional assembly instructions inside our
asm volatile( ) macro. In doing so, we'll also acquaint ourselves with a few more AVR instructions.
sbiinstruction consume in execution?
delay(1000). Again, choose the avr-gcc syntax for now.
BlinkInlinesketch from the previous class and remove the call to the
delay(1000)function. Copy the auto-generated code from the previous step and insert it into your
asm volatile( )macro.
7.2.2 Standalone (8-bit) AVR Assembly Coding (within the Arduino IDE)
Reference (unnecessarily complicated but informative, nonetheless): https://rwf.co/dokuwiki/doku.php?id=smallcpus
The Arduino IDE offers painfully few tools for the aspiring assembly language programmer to develop a skill set but it has one important thing going for it: familiarity. Make no mistake, confidence, coupled with steady productivity and reasonable success, are required to sustain interest in the challenge of low-level coding and, so far, you're making SUBSTANTIAL progress.
So, let's keep the hardware task the same (fastest blink of an LED) but strip away the cumbersome
" " and
\n from inline assembly to write clearer, standalone, AVR assembly code.
188.8.131.52. The Fastest! Blink
Assembly, create a first project called
FastestBlink.inoleaving the file completely blank. (an informative action would be to compile (verify) this empty file and read the diagnostic error messages it produces. Remember, all the code you have ever run in the Arduino IDE operates within the C driver shell
loop()function. We'll now provide these functions in Assembly!
.S(Note: it MUST be a capital S). Look to the top right corner of the IDE, click on the dropdown button, select
New Taband, in the text box, label the new file,
asm.S. (Note: you could call it anything you want but let's keep it consistent for today)
asm.S. file. The
.globalassembler directive is one of many that assists the toolchain with the creation of the final executable. Functions in assembly language are simply labels. Furthermore, it should be obvious now that they terminate with a
.global setup setup: ret .global loop loop: ret
setupfunction, free from the
\nsyntax required in inline assembly. Comment appropriately.
loopfunction. Comment appropriately.
.globaldirective is not required as this function requires only local access (ie, not visible to other files in the project that will be linked together). Return to our AVR Delay Calculator to obtain assembler code for the body of our
killfunction that will simply waste 1s worth of clock cycles. Comment appropriately.
asm.Sfile, upload. and admire!
184.108.40.206. Schaffer Traffic Light
In this second standalone AVR Assembly exercise we return to the venerable STL to continue to expand our knowledge base of instructions. Setting (or clearing) an individual bit od a PORT is handy, but typically you'll want to affect multiple bits at a time. For these purposes you'll need the
Place your Schaffer's Traffic Light into DDP pins A2..A0 + GND. (conveniently, the Intersection Shield works just as well for these exercises)
220.127.116.11.1 Version 1
AssemblyStandalonefolder create the project
STLv1.inofile and add an
18.104.22.168.2 (Improved) Version 2: AVR Assembly delay(ms) Function
Rather than entering and exiting multiple
asm volatile () blocks, Version 2 accomplishes the same result with a single
asm volatile () block by replacing the Arduino C
delay(ms) function with an assembly function that does the same thing (waste clock cycles).
asm volatile ()code block in the
setup()function, run the STL continuously for same the 3s-1s-3s delay sequence.
22.214.171.124. Morland Bargraph
To be developed....
7.2.2 Standalone Assembly (within the Arduino IDE)
126.96.36.199. Schaffer Traffic Light
To be developed...
To be developed...
188.8.131.52. OLED Temperature Display
To be developed...
7.3 Standalone Assembly (Atmel Studio 7)