Electronics Production
Electronics production assignment also included a group project. The intention of this group project was both to describe the PCB production process and to check that everything in the mini CNC machines was working well. In order to do that, we needed to mill a test pattern.
In my particular case, I had already completed the whole PCB production process (you will be able to see it in detail a few paragraphs below), so this part of the assignment was mainly useful for checking that the mini CNC machines in the lab were still in good condition, and for helping my group members learn how the PCB production process was.
Completing the group assignment
We started by downloading the “trace-width” test files (traces and interior) available at the Electronics Production assignment page.
Then, we used Fab Modules for setting the milling files, having into account that we would mill the PCB traces using the 1/64 milling bit, and the PCB outline using the 1/32 milling bit.
Once the milling files were ready, and the circuit board stock properly attached to the mini CNC machine’s bed, we launched the milling jobs using the VPanel software.
A few moments later the test file PCB was done… and the outcome was quite nice!
Time for the individual assignment
As individual assignment for the Electronics production week we had to fabricate one of the FabISP programmers available at the Fab Academy archives.
A FabISP is an in-system programmer for AVR micro-controllers, designed for production within a Fab Lab that allows to program the micro-controllers on other boards. Fabricating one of these programmers meant CNC milling) the printed circuit board (PCB) , soldering the electronic components, programing the board, and testing it.
Among the several versions of the FabISP available in the Fab Academy’s electronics production week page, we could choose any of them for completing this assignment. I would have loved to make more than one, but I finally opted for one of Neil’s versions (which is based on David Mellis's FabISP, which is based on Limor's USBTinyISP, which is based on Dick Streefland's USBTiny).
From the two versions available of Neil’s FabISP (hello.ISP.44 vs hello.ISP.44.res), I chosen the hello.ISP.44 board. The main difference between these two boards was that the hello.ISP.44 uses a 20MHz crystal oscillator and two 10pF capacitors for the clock signal, while the hello.ISP.44.res uses just one 20MHz resonator. Apart from that, everything else was completely the same!
The very first thing I did after deciding which FabISP to fabricate, was to download all the *.png files related to the hello.ISP.44 board available at the Fab Academy’s “Electronics Production” week page (board, components, traces, and interior). Then, I saved all these files in my Fab Academy student folder at IAAC’s cloud.
As I was going to need the traces and interior .png files for preparing the CNC milling files first, and I was going to need also the board and components .png files for pinpointing and assembling the components later, having these files already saved in the cloud would allow me to quickly access them from any of the computers that I would have to use during the whole PCB manufacturing process.
In theory, the next step should have been preparing the milling files. I already had the *.png files for milling the traces and cutting the outline of the board that I was planning to fabricate, so it was supposed that I had everything I needed in order to proceed with the milling.
Anyway, as the milling files had to be prepared taking into account the PCB milling machine that I was going to use, I needed to figure this out before going further in this assignment.
Reviewing the PCB prototyping machines available
Learning how to properly use a PCB prototyping machine was essential in order to complete this assignment successfully. On the other hand, I already knew that we were going to use these little CNC machines in subsequent assignments as “Electronics Design”, “Molding and Casting”, “Input Devices”, “Output Devices”, and “Networking and Communications”, so learning how to get the most out of them from the very beginning seemed a really good idea to me.
At the time of this writing, there were two different models of PCB prototyping machines available at Fab Lab Barcelona’s electronics room:
Roland Modela MDX-20 (1 unit)
This machine was the oldest of the PCB prototyping machines available at the lab.
Nonetheless, it was not only capable of milling material such as ABS, acrylic, woods, plaster, styrene foam, chemical wood, modeling wax, and light metals such as aluminum and brass, but it could be also used for precise 3D scanning when the “Roland Active Piezo Sensor” accessory was attached.
The maximum work area for this machine was 203,2 (X) x 152,4 (Y) x 60,5 (Z) mm. And while the software resolution was 0.025 mm/step, the mechanical resolution was 0,00625mm/step. On the other hand, the feed rate during milling operations could go from 0.1 to 15 mm/sec.
This CNC milling machine included a 10W DC spindle motor that could reach a maximum revolution speed of 6500 rpm, with a tool chuck for 3.175 mm (1/8") shank diameter milling bits.
It was connected via RS-232C (using a Serial to USB adapter) to a dual-boot Windows7/Ubuntu computer. And as far I could find out, it used to be run on Windows for 3D scanning operations, using Dr. PICZA software application. And for milling jobs, it used to be operated using the backend installation of Fab Modules in Ubuntu.
The Modela MDX-20 PCB prototyping machine was already discontinued by the time I was writing this, and it had been replaced by the MonoFab SRM-20.
Roland MonoFab SRM-20 (2 units)
**
The monoFab SRM-20 was the latest desktop milling machine designed by Roland at that time.
As mentioned before, it could be said that it was an updated version of the Modela MDX-20, although this new version was intended just for CNC milling (modeling wax, wood, chemical wood, foam, cork, plaster, acrylic, poly-acetate, ABS, or PC boards), and did not include the 3D scanning capabilities of its predecessor.
The operation strokes were also 203,2 (X) x 152,4 (Y) x 60,5 (Z) mm, but the spindle motor and the tool chuck system were completely different. It incorporated a DC Motor Type 380 with a maximum rotation speed of 7000 rpm, and the collet system for 3.175 mm (1/8") shank diameter milling bits included by default was independent, so it could be easily replaced by another collet for cutting tools with bigger or smaller shank diameter.
The software resolution was variable depending on the control commands set used, being 0.01 mm/step for RML-1 commands, and 0.001 mm/step for NC code commands. While the maximum mechanical resolution was 0.000998594 mm/step.
Unlike the Modela MDX-20, the monoFab SRM-20 machines had a fully enclosed cabinet, reducing dust and noise. The cover also featured an intelligent safety interlock that automatically paused the machine when the cover was opened.
Each of the two monoFab SRM-20 PCB prototyping machines available at Fab Lab Barcelona was connected via USB to a dedicated dual-boot Windows7/Ubuntu computer. Under windows, the software installed was VPanel (control panel), MODELA Player 4 (CAM), Virtual MODELA (preview tool), iModela Creator (design to production tool), ClickMILL software (direct control), and SFEdit2 software (TrueType to Stroke font converter).
In any case, using just VPanel and the Fab Modules’ web browser version was enough for milling PCBs with these machines.
Reading the user manual
I would have loved to learn how to use both models during this assignment, but the computer connected to the Modela MDX-20 was not booting at the time, so I had to focus only on learning how to use the monoFab SRM-20.
Maybe in the future (if the computer attached to the Modela MDX-20 is fixed), I would have the chance to spend some time playing with it. I would really love that! But for the time being, I downloaded the user manual for the Roland SRM-20, and I carefully read it.
The 152 pages of the manual described the machine’s features further (including part names and functions), and gave me a general idea of the very basics when working with this machine (VPanel, cutting tools, cutting materials, etc). On the other hand, it also explained the workflows when using the different software applications provided by Roland (SRP Player, MODELA Player).
As I was going to use Roland’s VPanel software application and the web-browser version of Fab Modules for milling the PCB, most of the software related information in the user manual was not very relevant at this point… but surely it would be useful at some point later!
Regarding the cutting tools, which was another relevant element to have in mind when preparing the milling files, the user manual showed me the different shapes of milling bits which could be used: flat tip, round tip, pointed tip, etc. And it also explained a extremely important information… how to properly attach these cutting tools to the existing collet!
In any case, as explained by Neil during the lecture, among vast amount of milling bits that could be used with this machine, we were going to use mainly two flat tip bits for milling the PCBs. A 1/64” (0.396 mm) milling bit for milling the traces, and a 1/32” (0.793 mm) bit for the outcuts.
A third 0.01” (0.254 mm) milling bit could be also used for milling the traces, but only if the distance between the traces/pads of the circuit to be milled was so small that we were forced to use this extra-small milling bit instead of the 1/64” (0.396 mm).
In my case, using this 0.01” (0.254 mm) milling bit was absolutely unnecessary, and using the 1/64” (0.396 mm) and 1/32” (0.793 mm) bit was enough as too mill the hello.ISP.44 successfully.
On the other hand, the material from which the PCBs were going to be machined was phenolic paper or FR-1. This is a material often used to make printed circuit board substrates, that is made of wood fibre and phenolic polymers. It is a fibre reinforced plastic, most commonly brown in color, and can have a copper foil lamination on one or both sides.
The circuit board stock that I was going to use for making the hello.ISP.44 board was a 1.6 mm thick 76,2 x 50,8 mm (3x2”) single sided FR1 PCB. Actually, with only one of these FR1 PCBs it could be possible to mill up to three hello.ISP.44 , as long as the space was well seized.
**
Once I knew which machine, milling bits and material I was going to use, and I had also learn the very basics of working with them… it was time to prepare the milling files using Fab Modules!
Preparing the .rml files with Fab Modules
A file with the *.png file extension is very useful to store graphics on websites but, unfortunately, it is not a file extension that the Roland SRM-20 milling machines (or any other CNC machine in the Fab Lab) can understand. In order to make the Roland SRM-20 to understand the images of the circuit that I had in *.PNG file format, it was necessary to convert them to G-code.
G-code is the most widely used programming language for controlling industrial machines such as mills, lathes and cutters, as well as 3D-printers. It has many variants, but most (or all) adhere to certain common rules. In the case of the SRM-20 milling machines, the suitable G-code variants were RML-1 (.rml file extension) and NC (.nc file extension).
It is possible to find many software applications that can be used for converting a graphic image to G-code (i.e. Inkscape, Scan2CAD, etc). And getting NC code file (one of the most common G-code file type) would be as easy as installing any of them, and following the required procedures.
In any case, the software applications developed by Roland for being used with their CNC machines generate .rml file extension archives. And this is also the file extension that can be generated using Fab Modules. Therefore, using Fab Modules would be the right way to go for this exercise (although using NC code generated with alternative software was also very tempting).
Besides, the browser-based version of Fab Modules can be accessed from any computer connected to the internet, which makes it very handy learning how to use it.
In order to convert the .png files to .rml files using the web browser version of Fab Modules, the first thing I did was opening a new Google Chrome window, and writing “fabmodules.org” in the address bar.
**
Once the “fabmodules.org” page was loaded, I clicked on the “input format” button at the upper-left corner of the site, and I selected “image (.png)” from the drop-down list that appeared.
**
As soon as I selected “image (.png)” from the “input format” drop-down menu, a navigation window opened. I used that navigation window in order to search for the “hello.ISP.44.traces.png” file that I had previously saved in my Fab Academy student folder at IAAC’s cloud.
Once I found the “hello.ISP.44.traces.png” file, I selected and opened it by clicking on the “Open” button at the lower-right corner of the navigation window. The navigation window closed, and the image of the hello.ISP.44 traces appeared in the fabmodules.org web page.
Simultaneously, a new button labeled as “output format” appeared right next to the former “input format” button (later converted to “image (.png)” after selecting that option from the drop-down menu).
On the other hand, an “input” parameters menu with details of the opened file (name, dpi, size) appeared at the upper-right side of the fabmodules.org web page.
**
I checked the size and resolution of the board and everything seemed to be ok.
Then I clicked on the “output format” button that had just appeared, and I selected the “Roland mill (.rml)” option from the drop-down list.
**
As soon as I selected “Roland mill (.rml)”, a new button labeled as “process” appeared right next to the former “output format” button (later converted to “Roland mill (.rml)”after selecting that option from the drop-down menu).
An “output” parameters menu also appeared at the right side of the fabmodules.org page, just below the “input” parameters menu that that had appeared in the previous step.
Then, I clicked on the “process” button, and from the drop-down list that appeared I selected the option “PCB traces (1/64)”. As mentioned before, the right tool for milling the PCB’s traces was the 1/64” milling bit, so it was very important to select this option correctly.
**
On the other hand, when I selected “PCB traces (1/64)” from the “process” drop-down menu, a “process” parameters menu also appeared at the right hand side of the web page.
Once I had selected the right “input”, “output” and “process” in the drop-down menus at the top of the fabmodules.org page, it was time to modify the parameters in the “output” and “process” menus at the right of the page.
Under “output > machine”, I selected “SRM-20”. Selecting this option, automatically filled in the rest of the output parameters with default values. I left the “speed (mm/s)” parameter as it appeared by default (4).
But I changed the “x0(mm)”, "y0(mm)”, and “z0(mm)” parameters to 0, so there would be no offset from the origin point that I was going to set in V-Panel later.
And I also changed the “zjog (mm)” parameter to 12, so the tool would rise 12 mm over the material every time it had to move from one point to the other of the PCB.
In the “process” menu, I did not change any value, so all the parameters were left as they appeared by default when I had selected “PCB traces (1/64)” in the “process” drop-down menu:
- direction: climb
- cut depth (mm): 0.1
- tool diameter (mm): 0.4
- number of offsets (-1 to fill): 4
- offset overlap (%): 50
- path error (pixels): 1.1
- image threshold (0-1): 0.5
- ort path: yes
- sort merge diameter multiple: 1.5
- sort order weight: -1
- sort sequence weight: -1
Then, I clicked the “calculate” button under “process”, and the image of the hello.ISP.44 traces completely disappeared from the screen.
A few second later the different tool paths started to appear one by one (in blue color), up to a total number of 4 (as selected in the “number of offsets” parameter under “process”). Along with the four tool paths, the movements in the air of the tool were also represented (in red color).
Finally, I clicked the “save” button under “process”, and a new navigation window opened.
I used that navigation window to search for my Fab Academy student folder at IAAC’s cloud, and once I found it, I saved the milling job as “hello.ISP.44.traces.rml”
The G-code file for machining the traces of the hello.ISP.44 with the monoFab SRM-20 was ready, but I still needed to prepare the G-code for the outcut. Basically, I needed to repeat the very same process, but changing the source file, some of the options selected, and few parameter values.
I refreshed the navigation browser and the web page was reseted. Meaning that all the changes made during the previous *.rml file preparation process disappeared from the window browser, and I was back in the beginning, where the “input format” button at the upper-left corner was waiting to be clicked.
So I clicked on the “input format” button, and I selected “image (.png)” from the drop-down list that appeared. Using the navigation window that opened, I searched for the “hello.ISP.44.interior.png” file in my Fab Academy student folder at IAAC’s cloud, and I opened it.
The image of the hello.ISP.44.interior appeared on the web page, the “Output format” button appeared again right next to the former “input format” button, and the “input” menu with details of the opened file (name, dpi, size) appeared at the upper right of the fabmodules.org page.
Then, I clicked on the “output format” button, and I selected the “Roland mill (.rml)”.
As soon as I selected “Roland mill (.rml)”, the “process” button appeared again right next to the former “output format” button, and the “output” parameters menu appeared at the right side of the page.
Note that until then, the whole .rml file preparation process was identical to the previous one (except for the *.png file that I was using). But some things would be different from there.
As the 1/32” milling bit was the right tool for milling the PCB outcut, I clicked on the “process” button and I selected “PCB outline (1/32)”. Once again, this was very important in order to obtain a proper calculation later.
Once the right tool was selected, the “process” parameters menu appeared at the right side of the page below the “input” and “output” parameters menus that had appeared before.
Then, I modified the parameters in the “output” and “process” menus at the right of the page.
Under “Output > machine”, I selected “SRM-20”. And I changed the “speed (mm/s)” parameter to 0.5; the “x0(mm)”, "y0(mm)”, and “z0(mm)” parameters to 0; and the “zjog (mm)” parameter to 12.
In the “process” parameters menu, I left all the parameters as they were by default again:
- direction: climb
- cut depth (mm): 0.6
- stock thickness (mm): 1.7
- tool diameter (mm): 0.79
- number of offsets (-1 to fill): 1
- offset overlap (%): 50
- path error (pixels): 1.1
- image threshold (0-1): 0.5
- sort path: yes
- sort merge diameter multiple: 1.5
- sort order weight: -1
- sort sequence weight: -1
Then, I clicked the “calculate” button under “process”.
The image of the hello.ISP.44 interior completely disappeared from the screen, and a few seconds later the tool paths appeared (in blue color).
In order to see the different passes of the tool, I rotated the view using the mouse’s right button. As the “stock thickness” was 1.7 mmm, and the “cut depth” was set to 0.6, the number of tool paths that could be seen was 3.
Finally, I clicked the “save” button under “process”, and I used the navigation window to save the milling job as “hello.ISP.44.traces.rml” in my Fab Academy student folder at IAAC’s cloud.
At this point, the two .rml files that I needed for milling my hello.ISP.44 board were ready, so it was time to move myself to one of the SRM-20 milling machines.
Milling the hello.isp board
Once I was sit in from of the PCB milling machine, the first thing I did was turning on the computer connected to it. Immediately after, I turned on the monoFab SRM-20 machine by pressing the “Power” button located at the top of the machine.
As soon as I pressed the “Power” button, the LED lamp at the top of the SRM-20 started to flash, and the machine’s initialization started: the spindle head moved up and left, and the table moved to the front. Once the initialization completed, the LED lamp at the top of the SRM-20 stayed lit.
With the SRM-20 initialized and the computer turned on, I launched the VPanel program by clicking the corresponding icon in the task bar.
The first thing I did after the VPanel program opened was making myself sure that the machine was correctly set up by clicking the “Setup” button at the lower right of the program window.
This opened the “Setup” dialog window, where two tabs could be found.
In the “Modeling Machine” tab, I checked that “RML-1/NC Code” was selected under “Command Set”. And also that “Millimeters” was selected under “Unit”.
As the “Power Option” parameter was not very relevant, and the option “Move cutting tool to desired location” was selected under “Direction of the Y axis moving keypad”, I could confirm that everything in that tab was ok.
Then, I also checked the parameters in the “Correction” tab. As the correction values for the three axes were set to 100%, there was nothing else to look at, and I closed the “Setup” dialog window could by clicking the “OK” button at the lower-right corner of the “Setup” dialog window.
**
Once I checked that the machine was correctly set up, I opened the machines lid, un-tightened the table’s screws, and removed the table from the machine, in order to attach the FR1 PCB to the machine’s table more conveniently.
Anyway, before I focused on attaching the FR1 PCB to the table, I closed the machine’s lid, and I turned the spindle on by clicking the “ON” button under “Spindle” in the VPanel program.
But I just wanted to warm the spindle up for a few minutes, I set the slide control under “Spindle Speed” to the lowest value possible, by sliding it to the very left.
**
Note that warming up the spindle was not mandatory, but as far as I understood after reading the machine’s user manual, it is a good practice when working with the monofab SRM-20.
While the spindle was warming up, I thoroughly cleaned the surface of the MDF sacrificial board that was taped down on top of the machine’s bed. There were not adhesive or double tape residues, so I basically removed the dust particles using a soft brush.
Right after cleaning the sacrificial board, I checked that the MDF board was firmly attached to the table, and that its surface was flat. Apparently… it was! So I could continue without further delay.
Next step was placing the material to be machined over the sacrificial board, so I cut a couple of pieces of double sided tape, and I applied them all the way across the bottom side of the FR1 PCB, being careful not to leave folds or overlaps.
Then, I removed the paper liner from the double sided tape, and I sticked the PCB on the MDF scrap board, making sure the PCB’s front side was completely parallel to the board's front side.
I also pressed the PCB against the scrap board using a piece of paper, so the PCB would be properly sticked but without leaving fingerprint marks on the copper surface.
Note that leaving fingerprints on the copper surface makes it harder to solder the components to the board, so cleaning any fingerprint or spot before milling is highly recommended.
With the PCB correctly attached to the MDF board, it was time to put the table back in the machine, so I set the “spindle speed” parameter back to 100%, and I stopped the spindle head by clicking the “OFF” button in the VPanel program.
Once the spindle head stopped, I opened the machine’s lid and relocated the table in place.
With the table in position and the screws correctly tighten, I used the [X][Y] feed buttons of the VPanel program to move the spindle head until it was over the PCB.
Once the spindle was over the PCB, I moved the spindle head up using the [Z] feed button in order to have enough space as to insert the milling bit, but also for the hole of the mounting screw to be accessible.
Then, I grabbed the 1/64” milling bit and, after checking that the tip was in good condition, I inserted approximately 1/3 of the shank in the spindle's collet.
The next thing I did was setting the origin point! And in order to do that, I brought the tip of the milling bit near the front-left corner of the PCB first, using the [X][Y] feed buttons.
Then, I used the [Z] feed button to slowly move the spindle head down, until the tip of the milling bit was 3 or 4 mm above the left-front corner of the PCB.
**
Once I the milling bit was over the front-left corner of the PCB and 3-4 mm away from its surface, I pressed the “X/Y” button under “Set Origin Point” in the VPanel program, so the X and Y coordinates in the left side of the program window were set to “0.00 mm”.
**
The origin point for the X and Y axes was set, but I still had to set the origin point for the Z axis.
In order to do that, I used an hex key to loosen the collet's set screw and, while holding the milling bit from the shank with two fingers, I allowed the bit to gently land on the PCB's surface.
Once the tip of the milling bit was in contact with the surface of the PCB, I used the hex key again to tighten the collet screw.
Then, in the main screen window of the VPanel program, I clicked the “Z” button under “Set Origin Point”, so the Z coordinate was also set to 0.
At that point, the PCB was attached to the machine, the 1/64” milling bit was inserted in the collet, and the origin point was set. Therefore, it was time to send the corresponding milling job!
So I clicked on the “Cut “ button at the lower right of the VPanel program, and the “Cut” dialog window appeared on the screen.
**
Then, I clicked on the “Add” button at the lower left of the “Cut” dialog window, and a new navigation window opened. Using that “Open” navigation window, I searched for the “hello.ISP.44.traces.rml” file that I had previously saved.
Once I found the “hello.ISP.44.traces.rml” file, I opened it. The navigation window closed, and the hello.ISP.44.traces.rml file appeared in the “Output File List” of the “Cut” dialog window that was still open behind.
With the “hello.ISP.44.traces.rml” file in the “Output File List”, I clicked the “Output” button at the lower right of the “Cut” dialog window, launching the milling process.
After a few minutes the milling job had finished, so I opened the machine’s lid, and I cleaned the PCB’s surface with a brush so I could check the outcome.
Unfortunately, the copper had not been completely removed in some areas and few traces were not correctly defined, meaning that the surface of the sacrificial board was not flat.
As the sacrificial board’s surface was not flat, I had to prepare a milling job to flatten the whole surface. And for what I knew, the easiest way to do that was using Roland’s Click Mill software, and one of the 1/8” 2FL flat-end milling bits available at the lab.
So I removed the FR-1 PCB from the sacrificial board, and I replaced the 1/64” milling bit for a 1/8” milling bit. Then, I followed the zeroing process for setting the new origin point in the scrap board, and I launched the Click Mill application.
Once Click Mill was open, I selected the “Surface” tab. I introduced the details for the “Lower left” and the ”Upper right” corners of the sacrificial board. And I also introduced, the cutting “Depth” and “Tool-up Height” values.
Then, I clicked in the the “Cut” button in lower-left of the program window, and a new dialog window appeared were I selected the “Tool” to be used and the “Material” to be machined.
Before going any further, I reviewed the “Cutting parameters” added by default when selecting “Tool” and “Material” were reasonable. Then, I clicked the “Cut” button in the lower left corner.
The SRM-20 started! A while later, the sacrificial board’s surface was completely machined and probably flat, so… I could re-start the PCB milling process again!
First of all, I removed from the FR1 board the old pieces of double sided tape that I have used to stick it to the MDF sacrificial layer on the first try, and I added new ones.
Then, I sticked the FR1 PCB on the freshly milled MDF board so the PCB’s front side was completely parallel to the table's front side, and making sure that there were no fingerprints or spots on the copper surface.
Then, I removed the 1/8” milling bit that was still in the collet, and I replaced it with the 1/64” milling bit that I had used before as its tip was still in good condition.
And finally, I set a new origin point just at the right of my previous failed attempt.
Then I clicked on the “Cut “ button of the VPanel program again. The “Cut” dialog window appeared and the “hello.ISP.44.traces.rml” file was still in the “Output File List”, so I just had to click the “Output” button and the milling machine started.
After a few minutes of “uneasy” wait, the machining job finished. As soon as the Spindle stopped, I opened the machines lid, moved the table to the front, and cleaned the PCB’s surface with a brush. This time the outcome was much more satisfying! No perfect but better!
**
I must admit that I was quite proud that I had reached this point. Anyway, the PCB milling process had not finished yet… I still had to machine the outline of the PCB!!
The first thing I did in order to proceed with the PCB’s outline machining was changing the tool. As mentioned before, the right milling bit for milling the outcut is the 1/32” bit, so I moved the spindle up, removed the 1/64” bit that was still in the collet, and I replaced it with the 1/32” bit.
Once I changed the milling bit, I clicked the “X/Y“ button under “Move > To Origin” in the VPanel program window, and the spindle head moved to the origin point that I had set before for milling the traces.
Then, I slowly moved down the spindle head until the tip of the milling bit was around 3-4 mm above the PCB plate. And I repeated the same procedure for setting the origin point in the Z axis that I have used before.
After zeroing the Z axis, I clicked on the “Cut “ button of the VPanel program. The “Cut” dialog window appeared and the “hello.ISP.44.traces.rml” file was still in the “Output File List”, so I click the “Delete” button.
Then, I clicked on the “Add” button at the lower left of the “Cut” dialog window, and I searched for the “hello.ISP.44.interior.rml” file using the “Open” navigation window that appeared.
Once I opened the “hello.ISP.44.interior.rml”, the “Open” navigation window closed, and the “hello.ISP.44.interior.rml” appeared in the “Output File List” of the “Cut” dialog window.
Then, I clicked the “Output” button and the machine started the process.
A few minutes later, the machining job finished. So, I opened the machines lid, moved the table to the front, and cleaned the PCB’s surface with a brush. The PCB still attached to the scrap board, but it could be clearly seen that the whole thickness of the board had been milled.
With the help of a spatula, I gently took of both the hello.ISP.44 PCB and the rest of the FR1 PCB from the scrap board.
I have already milled my first PCB and it was not all bad, but I was also sure that the outcome could be improved. Since I already had the whole process clear, I repeated it a few times more, but changing some of the parameters in the Fab Modules “process” menu, until I I got a handful of hello.ISP.44 PCBs with the right finish.
I even etched a hello.ISP.44 board (it can be seen along with the others in the picture above) using photosensitive positive PCBs, transfer paper, a UV-exposure unit, Hydrogen peroxide, Hydrochloric acid and a bunch of utensils, but I guess that is a long story for another time.
Assembling the Hello.ISP board
Once the PCB for the Hello.ISP was ready, it was time to for me to identify and collect the electronic components that I needed for assembling the board.
With the help of the hello.ISP.44 labeled board diagram and the image of an assembled hello.ISP board that I had downloaded at the very beginning of this assignment, I made a list indicating the name, and the quantity that I needed of each component:
- 1x Mini-B USB connector
- 1x ATTiny 44 microcontroller
- 1x 6 pin header
- 1x 1uF capacitor
- 1x 10pF capacitor
- 2x 0 Ohm resistor
- 2x 100 Ohm resistor
- 1x 499 Ohm resistor
- 1x 1k Ohm resistor
- 1x 10k Ohm resistor
- 1x 20MHz crystal
- 2x 3.3V Zener diode
Besides, in order find out more information about these parts, I searched for them in the Fab Lab Inventory, where I obtained their Digi-Key Part Number.
Knowing the Digi-Key Part Number, allowed me to visit the product page of each of the components that I was going to solder into the PCB. So I was able to see what they looked like, and also learn more about their specifications:
- Mini-B USB connector → Digi-key Part Number: H2961CT-ND
- ATTiny 44 microcontroller → Digi-key Part Number: ATTINY44A-SSU-ND
- 6 pin ISP header → Digi-key Part Number: 609-5161-1-ND
- 1uF capacitor → Digi-key Part Number: 445-1423-1-ND
- 10pF capacitor → Digi-key Part Number: 311-1150-1-ND
- 0 Ohm resistor → Digi-key Part Number: 311-0.0ERCT-ND
- 100 Ohm resistor → Digi-key Part Number: 311-100FRCT-ND
- 499 Ohm resistor → Digi-key Part Number: 311-499FRCT-ND
- 1k Ohm resistor → Digi-key Part Number: 311-1.00KFRCT-ND
- 10k Ohm resistor → Digi-key Part Number: 311-10.0KFRCT-ND
- 20MHz Crystal→ Digi-key Part Number: 644-1039-1-ND
- 3.3V Zener diode → Digi-key Part Number: BZT52C3V3-FDICT-ND
After reviewing the product page for each part, I was more aware of what I had to look for in the electronic components storage cabinets available at Fab Lab Barcelona. So I headed to the Lab’s electronics room, and I started collecting what I needed.
I spent a few minutes considering the labels and opening drawer after drawer, until I had collected the right amount of every component on the list that I had previously made.
As I was planning to assembly the board using the soldering tools that I had at home instead of the Fab Lab’s equipment, I put all the collected components in as mall plastic box. Note that most of these parts were very small, so not keeping them inside a box, would have probably meant losing more than one on the way home.
Once at my place, the first thing I did was gather the tools that I was going to need in order to solder the small SMD components to the Hello.ISP PCB. And the tools I needed were:
- Soldering iron with a 0.5mm conical fine-point tip
- Soldering iron stand with sponge
- Distilled water
- 0.35 mm soldering wire
- Desoldering wick
- Tweezers
- Vacuum base PanaVise PCB holder
- Solder fume extractor
- Magnifying glass
Once I had all the tools with me, I plugged in the soldering iron into the mains.
While the soldering iron was heating up, I took all the electronic components out from the blisters in which they came, and I ordered all of them near the Hello.ISP PCB.
After double checking that I had all the parts needed for completing the Hello.ISP assembly, I held the PCB in the PanaVise. Then, I checked if soldering iron was already hot enough as to melt the Ø0.35 mm soldering wire and… yes, it was!
So I placed the solder fume extractor close to the PanaVise, I turned it on, and I started soldering.
Following the FabISP: Electronics Production tutorial available in the Fab Academy tutorials page, I started by soldering the USB connector.
This component was supposed to be the most difficult component to be soldered into this board, but after watching one of the hundreds of videos available online that explain how to solder surface mount devices, it was quite easy to get a pretty good result.
The next component to be soldered according to the FabISP: Electronics Production tutorial, was the ATTiny 44 micro controller. In principle, this component seemed to me much more hard to solder than the USB connector, but using the same “flood and wick” soldering technique that I have used before for soldering the USB connector’s pins, it ended up being quite easy.
In any case, it was very important to have in mind when soldering the ATTiny 44 chip that it had to be positioned with a specific orientation. I was careful to ensure that the little circle on the chip indicating the VCC pin was facing the right direction before soldering it. And for that, I had to use the magnifying glass, since the naked eye could not appreciate that detail.
According to the FabISP: Electronics Production tutorial, the next component to be soldered was supposed to be the 20MHz Crystal. Then the diodes, the resistors, the capacitors, and the 6 pin header, in that order.
The orientation of the crystal, resistors, capacitors, and the pin header did not matter because they do not have polarity. Instead, the diodes orientation is important because they do have polarity.
Knowing this, I preferred to skip the order recommended in the tutorial, and I soldered the two diodes first, ensuring that the tiny white line on the surface of the package indicating the cathode was facing the right direction.
Then I put solder in one of the pads where the crystal, resistors, capacitors and header were going to be placed, and I soldered all these components being careful of placing them in the right spot, but without paying close attention to the orientation, as I already knew that none of them would be problematic in that sense.
I am not totally sure if this was there best way to do it, but it worked pretty well for me. And after a few minutes of soldering, the Hello.ISP board was assembled, and it seemed to be quite decent.
Anyway, before doing anything else, I used the magnifying glass to double check that there were not cold points, bridges, or any other common soldering problems in the board.
Everything appeared to be in order, so I venture myself to execute the last step of the FabISP: Electronics Production tutorial (called the “smoke test”), and I plugged the Hello.ISP board into my laptop using a mini-USB to USB-A cable.
I did not receive any message about the board is drawing too much power from my laptop, and I did not see smoke or notice any weird smell coming out from the board, meaning that there were not shorts, and that I could proceed to programming the board.
Programming the Hello.ISP board
In order to program the Hello.ISP board, I followed the FabISP: Programming tutorial that was also available in the Fab Academy tutorials page. And according it, the first thing to do was installing the necessary software.
As I was using a Mac OS X laptop for programming the Hello.ISP board, I downloaded CrossPack AVR. CrossPack AVR is a development environment for Atmel’s AVR micro controllers running on Apple’s Mac OS X, similar to AVR Studio on Windows. It consists of the GNU compiler suite, a C library for the AVR, the AVRDUDE uploader and several other useful tools.
From the CrossPack downloads page, I downloaded the latest version available, which was CrossPack-AVR-20131216.dmg at that moment. I clicked over the “download” button, and I used the dialog window that appeared to save the image file in my laptop’s “Descargas” (downloads) folder.
Once the image file was completely dowloaded, I opened it by double clicking the image file, and a new window appeared which contained a Readme.rtf file, and a installer package file named CrossPack-AVR.pkg.
I opened the installer file by double clicking on it, and I followed the installation instructions that appeared, until the installation process was completed.
According to the FabISP: Programming tutorial, the next step was “getting Make via XCode”.
I already had XCode installed in my computer, so I directly downloaded the FabISP Firmware for MacOS 10.8.2 to my desktop (and not to my downloads folder as I did with Crosspack AVR), using the download link available at the FabISP: Programming tutorial page.
Once the download was complete, I had to unzip the “fabISP_mac.0.8.2_firmware.zip” file that I have just downloaded. In order to do that, I followed the tutorial and, instead of any of the other decompress programs that I had installed in my laptop, I used the Terminal program.
So, I launched the Terminal program, and I navigated to the desktop directory by typing the “cd ~/Desktop/” command.
Last login: Fri Oct 27 08:22:13 on ttys000
MacBook-Pro-de-Aitor:~ aitoraloa$ cd ~/Desktop/
MacBook-Pro-de-Aitor:Desktop aitoraloa$
Once I was in the Desktop directory, I used the “unzip fabISP_mac.0.8.2_firmware.zip” command to decompress the fabISP_mac.0.8.2_firmware.zip file.
And as soon as I hit the Enter key on my keyboard, the terminal program spit out a few lines of code indicating that the fabISP_mac.0.8.2_firmware.zip file had been uncompressed.
MacBook-Pro-de-Aitor:Desktop aitoraloa$ unzip fabISP_mac.0.8.2_firmware.zip
Archive: fabISP_mac.0.8.2_firmware.zip
creating: fabISP_mac.0.8.2_firmware/
inflating: fabISP_mac.0.8.2_firmware/.DS_Store
creating: __MACOSX/
creating: __MACOSX/fabISP_mac.0.8.2_firmware/
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/._.DS_Store
inflating: fabISP_mac.0.8.2_firmware/main.c
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/._main.c
inflating: fabISP_mac.0.8.2_firmware/main.elf
inflating: fabISP_mac.0.8.2_firmware/main.hex
inflating: fabISP_mac.0.8.2_firmware/main.o
inflating: fabISP_mac.0.8.2_firmware/Makefile
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/._Makefile
inflating: fabISP_mac.0.8.2_firmware/usbconfig.h
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/._usbconfig.h
creating: fabISP_mac.0.8.2_firmware/usbdrv/
inflating: fabISP_mac.0.8.2_firmware/usbdrv/.DS_Store
creating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._.DS_Store
inflating: fabISP_mac.0.8.2_firmware/usbdrv/asmcommon.inc
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._asmcommon.inc
inflating: fabISP_mac.0.8.2_firmware/usbdrv/Changelog.txt
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._Changelog.txt
inflating: fabISP_mac.0.8.2_firmware/usbdrv/CommercialLicense.txt
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._CommercialLicense.txt
inflating: fabISP_mac.0.8.2_firmware/usbdrv/License.txt
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._License.txt
inflating: fabISP_mac.0.8.2_firmware/usbdrv/oddebug.c
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._oddebug.c
inflating: fabISP_mac.0.8.2_firmware/usbdrv/oddebug.h
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._oddebug.h
inflating: fabISP_mac.0.8.2_firmware/usbdrv/oddebug.o
inflating: fabISP_mac.0.8.2_firmware/usbdrv/Readme.txt
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._Readme.txt
inflating: fabISP_mac.0.8.2_firmware/usbdrv/USB-ID-FAQ.txt
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._USB-ID-FAQ.txt
inflating: fabISP_mac.0.8.2_firmware/usbdrv/USB-IDs-for-free.txt
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._USB-IDs-for-free.txt
inflating: fabISP_mac.0.8.2_firmware/usbdrv/usbconfig-prototype.h
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._usbconfig-prototype.h
inflating: fabISP_mac.0.8.2_firmware/usbdrv/usbdrv.c
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._usbdrv.c
inflating: fabISP_mac.0.8.2_firmware/usbdrv/usbdrv.h
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._usbdrv.h
inflating: fabISP_mac.0.8.2_firmware/usbdrv/usbdrv.o
inflating: fabISP_mac.0.8.2_firmware/usbdrv/usbdrvasm.asm
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._usbdrvasm.asm
inflating: fabISP_mac.0.8.2_firmware/usbdrv/usbdrvasm.o
inflating: fabISP_mac.0.8.2_firmware/usbdrv/usbdrvasm.S
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._usbdrvasm.S
inflating: fabISP_mac.0.8.2_firmware/usbdrv/usbdrvasm12.inc
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._usbdrvasm12.inc
inflating: fabISP_mac.0.8.2_firmware/usbdrv/usbdrvasm128.inc
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._usbdrvasm128.inc
inflating: fabISP_mac.0.8.2_firmware/usbdrv/usbdrvasm15.inc
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._usbdrvasm15.inc
inflating: fabISP_mac.0.8.2_firmware/usbdrv/usbdrvasm16.inc
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._usbdrvasm16.inc
inflating: fabISP_mac.0.8.2_firmware/usbdrv/usbdrvasm165.inc
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._usbdrvasm165.inc
inflating: fabISP_mac.0.8.2_firmware/usbdrv/usbdrvasm18-crc.inc
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._usbdrvasm18-crc.inc
inflating: fabISP_mac.0.8.2_firmware/usbdrv/usbdrvasm20.inc
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._usbdrvasm20.inc
inflating: fabISP_mac.0.8.2_firmware/usbdrv/USBID-License.txt
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._USBID-License.txt
inflating: fabISP_mac.0.8.2_firmware/usbdrv/usbportability.h
inflating: __MACOSX/fabISP_mac.0.8.2_firmware/usbdrv/._usbportability.h
MacBook-Pro-de-Aitor:Desktop aitoraloa$
Once the “fabISP_mac.0.8.2_firmware” directory had been created, I moved into this newly created directory by typing the “cd ~/Desktop/fabISP_mac.0.8.2_firmware” command.
MacBook-Pro-de-Aitor:Desktop aitoraloa$ cd fabISP_mac.0.8.2_firmware
MacBook-Pro-de-Aitor:fabISP_mac.0.8.2_firmware aitoraloa$
And then, I also used the “ls” command in order to just see the files in that directory.
MacBook-Pro-de-Aitor:fabISP_mac.0.8.2_firmware aitoraloa$ ls
Makefile main.c main.elf main.hex main.o usbconfig.h usbdrv
MacBook-Pro-de-Aitor:fabISP_mac.0.8.2_firmware aitoraloa$
And that was all regarding the software download! I had CrossPack AVR installed, I also had XCode installed, and I had the FabISP firmware for Mac downloaded too! Next!
According to the FabISP: Programming tutorial that I was still following, the next step was powering the Hello.ISP board. It would be impossible to program the FabISP if it would not be powered.
In any case, the right way to power the Hello.ISP board was connecting it to the computer via the USB connector, and using a separated programmer plugged into the 6-pin programming header. This separated programmer could be a working FabISP board, or any other commercially available programmer as the Atmel AVRISP MkII.
**
As I had one of these Atmel’s programmers at home (but not any other working FabISP), I had no other option than using the AVRISP MkII programmer to power (and eventually program) my Hello.ISP board.
On the other, I had already read in the “FabISP: Programming” tutorial that the “Makefile” document present in the “fabISP_mac.0.8.2_firmware” directory was set up to work with the AVRISP MkII by default, so using the AVRISP MkII would also absolve me tempoarily from having to edit the “Makefile” document.
Knowing this, I connected both the Hello.ISP board and the AVRISP MkII programmer to my laptop using the corresponding USB cables in each case.
The next step was connecting the AVRISP MkII programmer’s ISP female connector to the 6 pin male header of the Hello.ISP board. But it was very very important to connect these two devices correctly in order to avoid any issue, so a decided to make a little research before doing that.
With the help of the hello.ISP.44 labeled board diagram, I figured out the pin layout for the 6 pin male header in the hello.ISP.44 board. And visiting Atmel’s AVRISP MkII Introduction page at Atmel’s documentation web site, I found out the AVR ISP connector pinout too. Great!
Once I discovered the right orientation for hooking up the AVRISP MkII programmer’s ISP connector into the Hello.ISP.44 board’s header, I connected it. And as soon as I did it, the light indicator of the AVR ISP MkII changed from red to green, meaning that the hello.ISP.44 board was getting power.
**
According the FabISP: Programming tutorial, the next step after powering the FabISP was to edit the “Makefile” document inside the “fabISP_mac.0.8.2_firmware” directory. Anyway, the “Makefile” was set up to work with the AVRISP MkII by default, and as I was going to use a AVRISP MkII to program the FabISP, I did not need to change it this time. Finally, it was time to program the board!
I opened a new Terminal window, and I moved to the fabISP_mac.0.8.2_firmware directory again by typing the “cd ~/Desktop/fabISP_mac.0.8.2_firmware” command, and hitting the Enter key.
Last login: Tue Oct 31 13:07:53 on ttys000
MacBook-Pro-de-Aitor:~ aitoraloa$ cd Desktop/fabISP_mac.0.8.2_firmware
MacBook-Pro-de-Aitor:fabISP_mac.0.8.2_firmware
Then, I compiled the firmware by using the “make clean” command, and hitting the Enter key.
MacBook-Pro-de-Aitor:fabISP_mac.0.8.2_firmware aitoraloa$ make clean
And according to the tutorial, the response that I received from the system was the right one, meaning that the firmware compilation had been successful.
rm -f main.hex main.lst main.obj main.cof main.list main.map main.eep.hex
main.elf *.o usbdrv/*.o main.s usbdrv/oddebug.s usbdrv/usbdrv.s
Immediately after, I typed the “make hex” command in order to create the main.hex file (or output binary) that the AVR micro controller needs to run, and I hit Enter key.
MacBook-Pro-de-Aitor:fabISP_mac.0.8.2_firmware aitoraloa$ make hex
According the tutorial, the response received from the system was also successful.
avr-gcc -Wall -Os -DF_CPU=20000000 -Iusbdrv -I. -DDEBUG_LEVEL=0
-mmcu=attiny44 -c usbdrv/usbdrv.c -o usbdrv/usbdrv.o
avr-gcc -Wall -Os -DF_CPU=20000000 -Iusbdrv -I. -DDEBUG_LEVEL=0
-mmcu=attiny44 -x assembler-with-cpp -c usbdrv/usbdrvasm.S -o usbdrv/usbdrvasm.o
avr-gcc -Wall -Os -DF_CPU=20000000 -Iusbdrv -I. -DDEBUG_LEVEL=0
-mmcu=attiny44 -c usbdrv/oddebug.c -o usbdrv/oddebug.o
avr-gcc -Wall -Os -DF_CPU=20000000 -Iusbdrv -I. -DDEBUG_LEVEL=0
-mmcu=attiny44 -c main.c -o main.o
avr-gcc -Wall -Os -DF_CPU=20000000 -Iusbdrv -I. -DDEBUG_LEVEL=0
-mmcu=attiny44 -o main.elf usbdrv/usbdrv.o usbdrv/usbdrvasm.o usbdrv/oddebug.o
main.o
rm -f main.hex main.eep.hex
avr-objcopy -j .text -j .data -O ihex main.elf main.hex
avr-size main.hex
text data bss dec hex filename
0 2020 0 2020 7e4 main.hex
Once the firmware was compiled and the main.hex file created, it was time to set the fuses for the programmer to use the external clock (provided by the 20Mhz crystal).
In order to do that, I typed “make fuse” in the Terminal window, and then I hit “Enter”.
MacBook-Pro-de-Aitor:fabISP_mac.0.8.2_firmware aitoraloa$ make fuse
Once again, the response that I received from the system was the right one according to the tutorial, meaning that the fuses had been successfully set.
avrdude -c usbtiny -p attiny44 -U hfuse:w:0xDF:m -U lfuse:w:0xFF:m
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e9207
avrdude: reading input file "0xDF"
avrdude: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xDF:
avrdude: load data hfuse data from input file 0xDF:
avrdude: input file 0xDF contains 1 bytes
avrdude: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xFF"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xFF:
avrdude: load data lfuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.
Finally, I programmed the board. It was as simple as typing the “make program” command in the terminal window, and hitting the “Enter” key.
MacBook-Pro-de-Aitor:fabISP_mac.0.8.2_firmware aitoraloa$ make program
The response that I received from the system was:
avrdude -c usbtiny -p attiny44 -U flash:w:main.hex:i
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e9207
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "main.hex"
avrdude: writing flash (2020 bytes):
Writing | ################################################## | 100% 5.68s
avrdude: 2020 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex contains 2020 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 3.36s
avrdude: verifying ...
avrdude: 2020 bytes of flash verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.
avrdude -c usbtiny -p attiny44 -U hfuse:w:0xDF:m -U lfuse:w:0xFF:m
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e9207
avrdude: reading input file "0xDF"
avrdude: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xDF:
avrdude: load data hfuse data from input file 0xDF:
avrdude: input file 0xDF contains 1 bytes
avrdude: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xFF"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xFF:
avrdude: load data lfuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.
Which seemed to be ok according with the “FabISP: Programming” tutorial, so I could already think that the hello.ISP.44 board had been correctly programmed.
Anyway, I needed to verify that the hello.ISP.44 board was working correctly before start jumping with joy. In order to to that, I followed the “To Verify That Your ISP is working correctly:” instructions available at the FabISP: Programming tutorial for Mac OS.
I opened the System Profiler on my laptop, and I went to “Hardware > USB > Hub”.
Under the USB devices three, I could see one “FabISP” listed, meaning that the hello.ISP.44 board was correctly programmed, and that it could be recognized by my computer.
At that point, the only thing that I had left to do in order to use the hello.ISP.44 board as a programmer, was removing the two 0 Ohm resistors that I had placed in the SJ1 and SJ2 positions of the board diagram.
I plugged the soldering iron to the mains again. And while waiting for it to get hot, I placed the hello.ISP.44 board back in the PanaVise. Once the soldering iron was hot enough, I alternately heated each side of the resistor until I was able to remove it with the help of some tweezers.
After the two resistors were removed from the board, I used soldering wick to clean off the pads.
**
I could then say that my hello.ISP.44 programmer was finished, and allegedly working.
In any case, the best way to see if it was really working was using it for programming any other device. So I decided that it would be nice to make a second hello.ISP.44 board, and to use the FabISP that I already owned to program it. As I already knew the process, it should not be hard for me to repeat it, right!? Indeed, it was not!
Once I had a second hello.ISP.44 board assembled and ready to be programmed, I found that I needed to make a ISP cable in order to connect the two hello.ISP.44 boards via their 6 pin headers.
Making the IDC ISP cable
After reviewing some former Fab Academy students’ documentation, I understood that for making the suitable ISP cable to connect the hello.ISP.44 boards to each other, I just needed a small piece of 6 way flat cable and two 6 pin (2x3) crimp-on IDC connectors.
While I was checking the drawers looking for the hello.ISO.44 components, I saw a drawer with the “2x3 FEMALE CONNECTOR” label on it. So I went back to the Fab’s electronics room, and took a few 6 pin (2x3) crimp-on IDC connectors (including the strain reliefs).
**
At the Fab Lab’s electronics room, there was also a big spool of 10 way ribbon cable. I asked if there was also 6 way ribbon cable available, but the answer was NO. I was also informed that I would have to use that 10 way ribbon spool in order to get the 6 way ribbon cable that I needed.
The truth is that converting a 10 way ribbon cable into a 6 way ribbon cable is not a big issue. It was as simple as removing 4 of the wires from the 10 way ribbon cable. And that was what I did!
I started by cutting an approximately 20 mm piece of cable from the 10 way ribbon cable spool.
**
Then, I made a small cut between the yellow and the green wires with the help of cutting pliers.
Note that I could have cut between the blue and the purple wires, but I preferred to keep the black wire at one side of the resulting 6 way flat cable, in order to use it as reference for the IDC connector's ground later.
**
Once the cut was done, I separated the 4 wires that I wanted to pull apart from the other 6 wires by gently stretching both sets of wires in different directions.
The clear jacket joining the 10 wires together was thinner between wires, so pulling apart the wires happened to be very easy, since the wires separation itself was acting as a guide.
Once I checked that the resulting ribbon cable had not defects, I passed one of the 6 way ribbon cable’s end through the IDC connector. And when the ribbon cable’s end was more or less aligned with the opposite side of the connector, I pressed the connector onto the ribbon cable.
Note that when making a regular IDC cable, we have to take into account the polarity. However, for this ISP cable that I was making, the polarity was not relevant. It was just important to keep in mind for later that the connection between the headers of the two hello.ISP.44 boards had to be “straight-through”, this is pin 1 to pin 1, pin 2 to pin 2, pin 3 to pin 3, pin 4 to pin 4, etc.
Punching the connector completely onto the ribbon cable by hand was impossible for me, and I did not have a proper IDC connector crimp tool on hand, so I had to find another way to crimp the connector onto the ribbon cable. After watching a couple of videos online about crimping ribbon connectors, I found out that the best way to crimp the 6 pin IDC connector was using one vise.
**
Once I had the two IDC connectors crimped onto the ribbon cable, I also attached the strain reliefs. Attaching them was not really necessary, as the ISP cable connection was not susceptible of being accidentally pulled off, but it made me happy to complete the IDC connector set.
Then, I grabbed a digital multimeter in order to check the cable connections. I selected the multimeter's continuity test mode, and I tried to reach the contacts of the IDC connectors, which happened to be impossible because the probes were not small enough.
To solve this problem, I used a couple of tiny pieces of 0.35 mm solder. I inserted these solder pieces in each of the connectors’ holes, and I checked the connections by touching the end of the solder pieces that jutted out from the connectors with the multimeter's probes.
**
All the cable connections turned out to be fine, so the IDC ISP cable was ready and I could program the second Hello.ISP.44 board that I just assembled, using as a programmer the first Hello.ISP.44 board that I had previously assembled (and programmed with the AVRISP MkII).
Using the Hello.ISP board as a programer
The first thing I did in order to complete this last part of the assignment, was connecting both hello.ISP.44 boards to my laptop using a couple of USB-A to mini-USB cables.
Then, I connected both hello.ISP.44 boards together using the IDC ISP cable that I had just made.
Before doing anything else, I double checked that the IDC ISP cable was connecting the headers of the two hello.ISP.44 boards correctly. As mentioned before, the connection between headers had to be “straight-through”, meaning that the pin 1 of the hello.ISP.44 board acting as programmer had to be connected to the pin 1 of the hello.ISP.44 board to be programmed, the pin 2 of the hello.ISP.44 board acting as programmer had to be connected to the pin 2 of the hello.ISP.44 board to be programmed, and so on.
**
Taking up the “FabISP: Programming” tutorial, the next step after powering the FabISP was to edit the “Makefile” document inside the “fabISP_mac.0.8.2_firmware” directory.
As the “Makefile” was set up to work with the AVRISP MkII by default, and I was going to use a FabISP this time, I needed to edit it. So I opened the “Makefile” document using TextEdit, and I searched for the lines mentioned in the tutorial:
#AVRDUDE = avrdude -c usbtiny -p $(DEVICE) # edit this line for your programmer
AVRDUDE = avrdude -c avrisp2 -P usb -p $(DEVICE) # edit this line for your programmer
Once I found these two lines, I removed the "hash" symbol (#) in front of the line “AVRDUDE = avrdude -c usbtiny -p $(DEVICE)” , and I added a "hash" symbol (#) to the beginning of the line with the “AVRDUDE = avrdude -c avrisp2 -P usb -p $(DEVICE)” to comment it out.
AVRDUDE = avrdude -c usbtiny -p $(DEVICE) # edit this line for your programmer
#AVRDUDE = avrdude -c avrisp2 -P usb -p $(DEVICE) # edit this line for your programmer
And I saved the “Makefile” document, overwriting the original one.
Then, I opened a new Terminal window, and I moved to the fabISP_mac.0.8.2_firmware directory by typing the “cd ~/Desktop/fabISP_mac.0.8.2_firmware” command, and hitting the Enter key.
Once I was in the fabISP_mac.0.8.2_firmware directory, I compiled the firmware, created the main.hex file, set the fuses and flashed the program on the new hello.ISP.44 board, using the same commands that I had used before when using the AVRISP MkII. Everything went fine and the response received from the system was the right one in every step.
Last login: Mon Nov 6 16:31:20 on ttys000
MacBook-Pro-de-Aitor:~ aitoraloa$ cd ~/Desktop/fabISP_mac.0.8.2_firmware
MacBook-Pro-de-Aitor:fabISP_mac.0.8.2_firmware aitoraloa$ make clean
rm -f main.hex main.lst main.obj main.cof main.list main.map main.eep.hex main.elf *.o usbdrv/*.o main.s usbdrv/oddebug.s usbdrv/usbdrv.s
MacBook-Pro-de-Aitor:fabISP_mac.0.8.2_firmware aitoraloa$ make hex
avr-gcc -Wall -Os -DF_CPU=20000000 -Iusbdrv -I. -DDEBUG_LEVEL=0 -mmcu=attiny44 -c usbdrv/usbdrv.c -o usbdrv/usbdrv.o
avr-gcc -Wall -Os -DF_CPU=20000000 -Iusbdrv -I. -DDEBUG_LEVEL=0 -mmcu=attiny44 -x assembler-with-cpp -c usbdrv/usbdrvasm.S -o usbdrv/usbdrvasm.o
avr-gcc -Wall -Os -DF_CPU=20000000 -Iusbdrv -I. -DDEBUG_LEVEL=0 -mmcu=attiny44 -c usbdrv/oddebug.c -o usbdrv/oddebug.o
avr-gcc -Wall -Os -DF_CPU=20000000 -Iusbdrv -I. -DDEBUG_LEVEL=0 -mmcu=attiny44 -c main.c -o main.o
main.c:88:13: warning: always_inline function might not be inlinable [-Wattributes]
static void delay ( void )
^
avr-gcc -Wall -Os -DF_CPU=20000000 -Iusbdrv -I. -DDEBUG_LEVEL=0 -mmcu=attiny44 -o main.elf usbdrv/usbdrv.o usbdrv/usbdrvasm.o usbdrv/oddebug.o main.o
rm -f main.hex main.eep.hex
avr-objcopy -j .text -j .data -O ihex main.elf main.hex
avr-size main.hex
MacBook-Pro-de-Aitor:fabISP_mac.0.8.2_firmware aitoraloa$ make fuse
avrdude -c usbtiny -p attiny44 -U hfuse:w:0xDF:m -U lfuse:w:0xFF:m
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9207
avrdude: reading input file "0xDF"
avrdude: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xDF:
avrdude: load data hfuse data from input file 0xDF:
avrdude: input file 0xDF contains 1 bytes
avrdude: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xFF"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xFF:
avrdude: load data lfuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: safemode: Fuses OK (H:FF, E:DF, L:FF)
avrdude done. Thank you.
MacBook-Pro-de-Aitor:fabISP_mac.0.8.2_firmware aitoraloa$ make program
avrdude -c usbtiny -p attiny44 -U flash:w:main.hex:i
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9207
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "main.hex"
avrdude: writing flash (2002 bytes):
Writing | ################################################## | 100% 2.03s
avrdude: 2002 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex contains 2002 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 2.40s
avrdude: verifying ...
avrdude: 2002 bytes of flash verified
avrdude: safemode: Fuses OK (H:FF, E:DF, L:FF)
avrdude done. Thank you.
avrdude -c usbtiny -p attiny44 -U hfuse:w:0xDF:m -U lfuse:w:0xFF:m
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9207
avrdude: reading input file "0xDF"
avrdude: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xDF:
avrdude: load data hfuse data from input file 0xDF:
avrdude: input file 0xDF contains 1 bytes
avrdude: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xFF"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xFF:
avrdude: load data lfuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: safemode: Fuses OK (H:FF, E:DF, L:FF)
avrdude done. Thank you.
MacBook-Pro-de-Aitor:fabISP_mac.0.8.2_firmware aitoraloa$
Finally, I verified that the hello.ISP.44 board was working correctly using the System Profiler on my computer. With the two hello.ISP.44 boards still connected to my laptop, I could see two “FabISP” listed under the USB devices three, meaning that the newly flashed hello.ISP.44 board had been correctly programmed, and that it could be also recognized by my computer.
Tools used
For preparing the *.rml files Windows Fab modules
For milling the Hello.ISP board Roland SRM-20 Hex key FR1 PCBs Double-sided tape Spatula Rubbing alcohol Paper towels
For assembling the Hello.ISP board
For programming the Hello.ISP board
For making the IDC ISP cable