@Stargzer..you took your time to reply there!! I use Paint for all sorts of things...like you I have scanned stuff and prettied it up...a Google map with annotations for participants in a meeting, showing where work / hotel / gas stations / restaurants were.... a plan of the workplace (from a fire evacuation diagram) showing the location of all comms cabinets...etc. Paint is simple but almost totally unlimited in what you can do with it. It does not have the niceties of Photoshop or Visio, and I'd love to be a virtuoso in either of those, but I rarely feel the need.
My PCB design program is an ancient one very similar to Paint but with the addition of pre-drawn pads and IC footprints... it's great in that you can put almost anything anywhere, you don't have to have a footprint for an unusual connector or component.
I also use Cardfile which started life in Win 3.1. Great little program, stores a heading and several lines of free form text, so again you can use it for almost anything.
BIG problem though, apart from Paint, neither of the others work under Win 8, I am going to have to build a Win XP or 2000 machine just for these!
@David Ashton: However this is when I do my own (usually simple) schematics by hand or with MS Paint (luddite, aren't I?)
Simple tools can do some neat tricks! I had to do a floor layout for some reorganized office space. I scanned the existing floor plan from facilities and imported it into MSPaint. With a lot of cut and paste I managed to make it look so good the guy asked me what CAD program I used. :-D
This must be very recognizable by a lot of us folks: Yet another CAD company trying to sell us 'tools' that create schematic symbols from an FPGA pin list. You get these 'square blobs' full of 'pins' having absolutely no relation to the schematics that you currently are creating.
No thank you, not my cup of tea. To my opinion: Schematics are artwork and are as important as the PCB design itself: FPGA's should be represented in banks, just as they are internally organized.
For example, this I find an absolute shame: CAD companies selling their toolchains with schematic entry tools that really are from the '80's. Horrible. I used PCAD until a couple of years ago. I used it until they were invaded by the Chinese. Now -fully into Chinese hands- they force you to go to work 'in the cloud'. Well, I followed StarTrek for years and I know how unpredictable 'clouds' can be, so thank you, I miss another cup of tea.
[COMPUTING IN THE CLOUD IS NOT A WISE IDEA] (c) Rob Gongrijp, a former Dutch hacker
Then, Cadence... what ??? !!! Orcad schematics? From the 80's indeed. They should be ashamed of themselves. You cannot even recognize LVDS pairs besides to couple them inside a 'spread sheet'. Helpful indeed, those spreadsheets, but the schematics *should* tell you the full story as a lot of people here already mentioned. And you have to know that they *have* proper schematic entry tools. Even PCAD is more modern looking than Orcad. People tend to make these 'label schematics', unreadable, I hate those.
I have the feeling that 2D CAD just is a big money maker and they don't care a ^#$%@^ of our struggle to get something properly on paper. Beeing in the industry for more than 25 years this is one of my frustration points. So, thanks for bringing this up.
At one place I used to work all logic gates were drawn as boxes. No sense of the logic function, the only intent of the schematic was to create a netlist to create a PCB. The idea was that no competitor could use the schematic to figure out the logic. Nor could anyone else within that company.
That, of course, is what happens when the lawyers are let out of their cages.
betajet, I disagree. Clear documentation makes it that much easier to handoff to another engineer. I personally ttry to make my documentation clear, especially firmware by adding tons of comments on the intent of the code. However, I have seen folks manage to stay in a job way longer than management desired, by purposefully writting obscure code. Schematics aren't so difficult to clean up, no matter how bad the original authors intentions were.
My first engineering job had a requirement, from the military customer I beleive, that schematics not have dots. If lines cross, they do not connect nets. If a connection is desired, the vertical line must be offset and split into two Ts. They said the dots would get lost in mutliple photocopies. It made sense to me and I have adopted it for use over the last 30 years. I don't why, but when I see a schematic with little hoops where nets cross and don't connect, it makes me think of hobbyist versus professional.
"The worst as you say are MCU diagrams where the tendency seems to be to put ICs in isolation with a funny shaped box on each pin with a cryptic signal name in each. Somewhere on the rest of the diagram is another box, going into another IC, with the same signal name"
One of the things I like about Altium Designer is the 'Harness' device. Similar to a bus, but allows a free-form mix of signals, including busses and other harnesses, to bu grouped together as a single line.
These days my typical circuit has a top level with a bunch of subsheets connected by harnesses with suitable names. The CPU subsheet has harnesses with the IO conditioning subsheets, keypad subsheet, display subsheet, etc.
Of course the CPU sheet itself still has many labelled wire stubs, but at least I can collect many nets directly into harmesses, and can often position the others so the connections are not too hard to find. I thought to add some screen-shots, but anything useful is a bit big.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.