The Amp Hour Electronics Podcast

A weekly show about the trends in the electronic industry.

You are here: Home / Radio Show / #172 – CAD courses and cross platform creation – Printing Propaedeutic Patterns

#172 – CAD courses and cross platform creation – Printing Propaedeutic Patterns

Play

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | RSS

BenchBudEE

We’re going to try a new way of posting links this week. It falls in line with how we post them to our twitter feed as well. Each link allows for discussion on a per link basis, which continues from the time the link was posted (reddit account required).

If there are any missing links, please let us know in the comments below!

Comments

  1. only 20 minutes in but I have a thought about the higher level code being seen on micros. this is related to the IoT!

    Possibly the developers hoping to add physical objects to the web are more used to high level languages and it is too big of a leap to go to C. It will be the classic story – what is the right tool for the job.

    I use Arduino but I do not like much of the built in library. Fortunately it is a bit easy to skip that and go directly to the datasheets of the AVRs to manipulate the timers. I would say I do AVR on Arduino dev boards.

    however, for those that will not need to read an encoder at high speed or do other time-critical things perhaps they are better off with a high level language – higher than the Arduino library.

    A great example of this is electric imp which I also have spent a lot of time with. The hardware runs an RTOS and so it is really easy to code. Making a web enabled machine involves HTML and Javascript and then the scripting language of the imp. These two scripting languages are similar enough that it is no problem to switch between them during development.

    • Electric Imp/RTOS is a good example because I can relate…I want nothing to do with the underlying code. I just want it to work and I’m willing to take the performance hit.

  2. Wow, check out the poster. It uses units of kilo-cycles! And spark gap oscillators! You should probably probably put a low pass filter on that. 😉

  3. Hey Chris, I uploaded the poster to OfficeMax website and had it printed at my local store. With matte paper as well as lamination per Dave’s suggestion, it came in just under $50. Dave nailed it. It defaults to black & white, so I had to select color printing. It’s 36″ x 24″ which is the maximum size they have. What a beauty! I had to call them to tell them I wanted it laminated, and they did a great job. The print shop guys at the local store are quite good. I hope they’re paid well.

    You young guys who didn’t get to play with blueprints missed out on an entire realm of engineering culture! Drawings were done on translucent sheets of various types over the years, which were stored in huge drawing file cabinets. To make a working print, you’d lay the original drawing on top of a blank blueprint sheet and run it through the print machine. The machine optically exposed the paper, probably with UV, and then cured or fixed it with ammonia.

    The drawing and print sizes are labeled by letters, A through maybe F. A-size is USA letter size, 8.5 x 11. B size is double that, and each letter up doubles again.

    One of the first things every engineering student or new engineer learned was how to properly fold a blueprint. If larger than A size, you would fold it in half, print side out, and continue folding in half until it is A-size, with the title block (lower right corner) visible on top.

  4. Regards wireless power transfer – I also ignored it because I thought it was a waste of energy and time… until my expensive smart phone’s micro USB connector went intermittent at 18 months old. A wireless kit got it charging and kept me running while I waited for a USB board to repair it. Now I have a wireless base for work, bedside, and the car. I can opportunity charge, and don’t have to worry about port mechanical wear. I’m sure the phone manufacturers only want it to last one forcing you to upgrade. Wireless charging improves reliability and increases lifetime of the phone. Yes, maybe 1W is lost while charging, but if I get 3 years out of a phone, it saves the embedded energy in a new phone and costs less overall.

  5. If I remember correctly(I might have the wrong episode), you guys were talking about ASICs that are laser etched instead of using masks. Is there a link for this?

  6. I’ve been working on the eLua project (http://www.eluaproject.net/) for a number of years now, so I can make a few comments about the whole higher-level languages on MCUs thing.

    First off, this is only _somewhat_ new. Some existing companies have been in this space for a bit including Sierra Wireless which has been using Lua on it’s devices:
    http://electronicdesign.com/embedded/accelerate-embedded-development-lua

    Also Synapse Wireless has had a Python implementation running on MCUs:
    http://synapse-wireless.com/snap-components-free-developers-IDE-tools/portal
    They gave a talk at PyCon 2009: http://blip.tv/pycon-us-videos-2009-2010-2011/batteries-included-python-on-low-cost-tiny-embedded-wireless-devices-1957193

    Also there are certainly a ton of other (open and non) implementations of things like Forth, BASIC, Java, etc..

    There are a number of reasons why these languages are appealing when they fit on these types of devices:

    Some of the advantages of these are similar to other tools and projects that abstract away hardware details like Arduino and mbed (the, “I don’t need to read through a 1000 page datasheet to work on this thing” factor) which also extends to making it easier to move to new platforms as long as they’re supported (“I don’t need to read another 1000 page datasheet”).

    Where they differ are things like these:

    1) Interactive rapid prototyping.

    On some of these platforms, including eLua, you get a read eval print loop. You can just type in commands (flash LEDs, talk to things over the SPI bus) and see what they do, no compile, link, flash cycle. For ones that don’t you’re still just shipping bytecode to the device which still shortens the cycle to getting new code on a device.

    2) Less complicated toolchain on the desktop

    In the cases where there’s actually a compiler hosted on the MCU, you might just need a serial terminal emulator or some way to copy scripts to the MCUs flash.

    In other cases you just need the scripting language’s compiler which is generally going to be lighter-weight than an Eclipse-based IDE with some associated compiler. And you’ll not need a JTAG interface once your language is already loaded.

    These also make it easier to move to another machine.

    There are other benefits and advantages, but the idea is lowering the barrier to get started but hopefully providing something that is useful later in the development cycle or as a product feature. You could use it for RAD just to get things started and then re-implement in C if you like or use it through to the end with an added benefit: If you’re making a product your end users and integrators will have a much easier time customizing the behavior of the device. Personally I think this sort of thing is great for wireless and wired connected devices (IoT).

    There are plenty of caveats as well. You’re probably not going to use these things in an ECU or for much of anything with hard real-time constraints. These approaches also tend to be memory and flash hungry. Also, all abstractions are going to suck for some use cases. Hardware abstraction layers are going to capture a cross-section of what peripherals on different platforms can do, probably not the full detail of the hardware APIs. On the plus side, many of these platforms make it as simple as possible to write your own C functions and expose that functionality in the language.

    That was a bit rambling, but maybe helpful?

  7. That frequency usage spectrum chart printed by Welch is probably Welch Allyn now – http://www.welchallyn.com/default.htm . I am like Dave in that I am mostly not a fan of software upgrades because most of the changes have a negative impact on my productivity and on my ability to work with work created in a previous version. Another thing that I do not care for is being forced into purchasing a new version of software when the old version works fine for me.

  9. I had it printed at CostCo, where I do all of my photo printing. A 20×30 poster print came out beautifully, and costs less than $20. I had to reduce the size of the full resolution file so that it was under 100M with a tiny amount of JPG compression. The result was perfect.

  10. Dave, you said that people on a Mac who don’t have access to some programs for PCB design and what not, “tough tits.” However, when talking about people using OOP languages for microcontrollers you want people to explore. That it’s not a tough tits use C, situation? It seems to me you have a bit of a biased towards not liking anything Apple related. Is it tough tits to the people who run Linux as well? They are in relatively the same boat. If you say that it’s good to have people stray away from the de facto micro controller programming language, then you should also say it’s good to have companies stray away from the de facto professional productivity OS. I smell pure hateraid.

  11. re: software for Mac: dunno if Dave reads comments here, but seriously Chris, I don’t know how you don’t slap Dave sometimes!

    “tough tits” isn’t an acceptable response any more. the market has changed, broadened, & matured.

    just because Dave had a bunch of Mac zealots trot out the old stereotype that Macs are better at X (where X in this case was “video”, but which has’t been a compelling argument for years) doesn’t mean Macs haven’t been selling like hotcakes & adopted in particular by the up-n-coming generation (unlike Dave, & me for that matter, although I *did* ditch Windows for my day-to-day environment in 2007 after Vista landed & though “I waited 5.5 years for this sh*t? NFW!”, & never looked back).

    Mac has hit ‘critical mass’ & an ever-increasing proportion of (especially commercial) developers are economically required to support at least ‘both’ platforms, sometimes even the ‘other’ platform too ;). “tough tits” was an acceptable response from Apple iOS developers to Android owners until a year or three ago, when Apple had a 3+ year lead in the mobile OS space, but that’s no longer the case, and the economic argument doesn’t allow a “tough tits” response anywhere near as much as it used to. the same is becoming true, at a slower rate of change, of Windows vs. Mac.

    the electronics development tools industry is a bit of an odd-ball, in that there’s so little competition in the mid-range, but it doesn’t change the reality of the platform more & more people are choosing to use.

    re: high level languages coming to small microcontroller platforms. for a while I too cringed at the idea of things like Javascript being used on “serious” hardware (no one cares, or at least no one is injured when a web-browser crashes, but when a mechanical production line goes SNAFU, heads roll). after a while I just thought “fine, whatever :)”. but in the last year I’ve come to accept that as “hardware”, particularly that made with small microcontrollers with aspirations of #IoTness & wanting to do all sorts of cool stuff on the internet, REALLY needs the programming chops of people who spend most of their day with their head in a high level language. i think it’s all part of the merging of ‘scenes’ that we’ve seen with OSHW, & we’re gonna *need* to see more high-level-language talent brought to bear and mixed in with ‘traditional’ hardware & embedded software development.

  12. Going to have to… kind of… disagree with you here.

    Wireless power transfer systems are lucky to be 50% efficient. So although cell phones don’t consume massive amounts of power like your clothes dryer, you’re still loosing greater than half the power you pump, in for what?

    Reliability? That micro USB connector is rated at way more cycles than you used in 18 months. The reason it failed was because it was damaged, poorly designed, or had a manufacturing defect. The same issues would happen MORE frequently with a wireless system designed on a similar budget.

    Wireless systems add significant cost over traditional connectors if you want increased reliability. And 10% of that additional cost could simply be spent on a good quality connector thus completely eliminating any reliability benefit the wireless system might have had.

    Wireless charging improves reliability much buying new shoes each week improves their reliability. It’s a bit excessive and typically not practical.

    Wireless power has it’s uses but they are in niche areas like harsh environments and/or when safety is an issue. The electric toothbrush is a great example. Cell phones, bad example.