Following up on Chip McClelland’s IoT presentation at this month’s meeting at NCSU, here’s a Freescale/Arm high level take on what’s needed to build out the Internet of Things. The figure on page 10 and the table on 11 are handy to get a feel for different communication schemes out there.
At the TriEmbed meeting this coming Monday I’ll be asking if others are interested in joining a systematic self-study of Kicad.
I knew I’d be driven to this sooner or later, but the future is now, as they say. I’m working on a combination clock calibrator and frequency counter and find the design process dominated by the challenge of fitting the silly thing into a single Eagle schematic sheet.
The current rough cut of the circuit building blocks is the super-compressed schematic toward the bottom of the project page. This hodge podge of schematic symbols jammed together make it clear that the free version of Eagle is not up to expressing a system this large and complex. (Correction: I have a license for non-educational use, but just the cheap one that has the same size constraints as the free version.)
Update: A “Kicad Study Group” page has been added and at least a half dozen folks expressed interest in taking part.
Update: Nobody’s missed anything, time’s just run short this month.
Many Arduinos are based on the Atmega 328 P chip. Note that P. If you buy raw chips be sure the P is present. When you look up “Atmega328” at a site like Digikey the P and non-P versions are side by side and you might just go for the cheaper one without noticing the difference. You will be sucking persimmons if you’re missing the P. I am now a relative and reluctant expert about working around missing Ps. One might say I’m P‘ing into a pot with information I wish I didn’t have. Actually, it was many months ago that I accidentally bought some P-challenged Atmega328 chips. But it was only today that I realized I was down to the bottom of the barrel and forced to replace a P with a non-P in an Arduino Uno, and that situation can best be spelled PO.
THIS CHIP BELOW IS THE Atmega328P YOU WANT:
THIS CHIP ABOVE IS THE Atmega328 CHIP YOU DO NOT WANT. Notice how you can’t read the markings? That’s an accidental hint about which is the correct part, but also indicative of the apparent conspiracy the chip makers are involved in to make sure non-machines (i.e. us) can’t read the markings in ordinary conditions. Both chips were close to flat, but the bottom one was obviously not flat (or tilted with respect to the light source) enough!!!
Postscript: Making a 328 chip run in an Uno is a total Pain. I should probably document that some place to save the next person some trouble. However once it’s done the fact that it’s the “wrong chip” is no longer visible if you’re using the bootloader to program it.
For those using Linux or something functionally equivalent for “Arduino development”, Tim Marston’s Arduino make file makes a wonderful tool. Apart from saving lots of mouse movements, using this make file in combination with the AVR tools and Arduino libraries is drastically faster. You have to see the difference to believe it could have been possible to make the Arduino IDE look so dog slow.
Anyway I wanted to share one detail to save others grief if/when they use this tool with Attiny chips. The make file passes “-D” to avrdude, and that won’t fly with chips like the Attiny84A that need a chip erase cycle if you also want avrdude to verify the bytes it’s programmed. Here is the problematic line:
AVRDUDEFLAGS += $(addprefix -C , $(AVRDUDECONF)) -D
My quick hack was to use one of my (Bourne/Bash shell) scripts to determine if I’m programming one particular chip vs another (by reading its signature) and then pass the appropriate switch in for avrdude. So my make file looks like this:
AVRDUDEFLAGS += $(addprefix -C , $(AVRDUDECONF) $(CHIP_ERASE)
And then when I invoke the make command I’ll use something like this:
make blah blah CHIP_ERASE=$ERASE blah blah upload
Then my script sets ERASE to “-D” or “” depending on the chip type.
Consult your specific AVR chip’s data sheet to determine whether it can get along without a chip erase cycle (e.g. like the Atmega 328p).
Addendum: The avrdude “-e” option can be appended and it will override -D and force an erase. So if the last AVRDUDEFLAGS assignment has the $(ERASE) reference the sense can be flipped and it becomes less confusing, and you just need to feed in a “-e” for the chips like Attiny that lack page erase.
Also, I forgot I’d removed the “-V” switch from Tim’s make file and this of course suppresses verification. So if you’re reading this Tim, I can understand why you might have been scratching your head.
Finally, one might assert that the “-e” can trivially be appended with something like this:
make -f arduino.mk blah blah AVRDUDEFLAGS=”-e”
Except this doesn’t work as documented in the make file comments. That is, if you try to do this you end up with the “-e” replacing ALL the avrdude flags: the append operations in the make file are trumped by the command line assignment. Maybe I’m missing a make flag that changes the variable assignment semantics? Don’t know, but I’ll try to return to this later and maybe develop a patch to incorporate automation features to guess a programmer to use and chip to program.
I’m putting together some logic chips to make a couple of precision timing tools as part of a clock calibration project. The FIRST old TI chip I go to add to a new schematic in Eagle has no library support. If I had a nickle for every time this has happened… So I search for it and here’s the one hit at Element14:
“Hey, I’m a new user here, and pretty new to using Eagle Cad. I am looking for a dual 16 bit counter, and the chip that I’ve been using in my lab, and am using Eagle Cad to make a schematic.
Is there any library that includes the chip? Or is there any good alternative inside the existing Eagle Cad libraries?
74LV8154 is the chip I’m using, datasheet: http://www.ti.com/product/sn74lv8154-ep“
Thanks! <name omitted>
This is followed by one reply:
if you are new to EAGLE, it’s a good point to start your training by
creating your own library. You will have to learn it anyway in the long run.
Best Regards, <omitted>
Folks, here is my reply to this: There will soon be an Eagle library item for this chip. I’ll gladly mail it to you after you deposit $100 in my Paypal account. Consider this extra special motivation for you to fully enjoy the learning experience of making your own component file as a cheaper option that will enrich your life and improve your character.
Sheesh. But seriously, it might eventually be worthwhile to create TriEmbed libraries. I have a handful of custom component descriptions that I trust and would be comfortable sharing. The additional value of this is that we might get feedback about how to improve them.
Here’s the graph that got scrubbed out of the list msg about tests of the TI TPS63031 buck/boost DC converter chip (3.3v out for 2-5.5 volts in). When I look at that msg as I got it from the list the graph is there! But I just looked in the archives and see that it was scrubbed. Oh well.
This shows the package temperature measured with a cheapo IR themometer with different input voltages and output load currents. Chip McClelland is going to combine this with his tests for more details later.
I’m still looking for clues about how this happened, but with yesterday’s soldering Chip and I did there was this terrible too-fast drop in temperature that explains the “dull” appearance of some of the solder joints. There were six breakout boards maybe 3/4 to 1″ square each sitting on a 1×4″ piece of circuit board in the middle of the oven tray. I’m aware this (plain T-962) oven is notorious for not performing well on large boards or boards outside the center of the tray, etc. But this was the first case of the temp control making a huge error at a critical moment. With one other batch I saw a mistake like you see below below and to the right of the one the arrow points to. Oh well, time to finish the fume hood and turn attention to some upgrades.
I’m going to be reading this instead of “The New Yorker” for a while.
Did I say “for a while”? There is an amazing pile of stuff linked off this page.
The annual Cary Swapfest was held at Ritter Park this year.
I was late getting to the ‘Fest and a change of plans kept me from taking my stuff to put up for sale. But I had a nice chat with Jon Wolfe of Anibit and got the dual H-drive chip I desperately needed to move the hdd motor project forward. At least one kindred spirit dropped by to chat and take a TriEmbed info sheet home with him. Hopefully we’ll be seeing him at a future meeting. The ‘Fest was much, much larger than the last time I went, but that was eons ago. I guestimate 40-50 distinct tables of interesting stuff for sale, including lots of electronic components and devices. They had snacks and drinks and held test sessions for those interested in getting or upgrading their amateur radio license.
I saw two other TriEmbed folks who appeared to have great success finding parts for their project. I would definitely recommend this event as being worth the $4 admission just for the fun of looking at the large collection of familiar and very unusual gizmos, not to mention the chance to yack with interesting people.