If this is your first visit, be sure to check out the FAQ by clicking the link above. You have to register before you can post.

If you have recently signed up, please make sure you log in so that your activity is registered. This is required for automatic promotions to work and to ensure your account is not deleted during the registration process.

AthenaOfDelphi

Moderation Process Reminder

Since this appears to be a problem, please be aware that some areas of the site are moderated. When you post to these areas, you will be told that your post is awaiting moderation.

You will not be able to see posts that you have made that are waiting to be moderated.

Do not think that because your post has not appeared that an error has occurred. If this happens an error message will be displayed (you should note this and report it in the 'Site News/Feedback' forum.

Well, it may do and if you mention scripting on the forums you'll run into a number of suggestions for scripting engines. But what if you don't need the full on complexity of a scripting engine? What if you just want simple things?

As an example, consider this... I was asked by a former employer if I could re-engineer one of his products. This particular product was a card vendor and it was beginning to suffer the effects of parts obsolescence caused by legislation such as RoHS. So I took one of these units, took it apart and reverse engineered the schematics from the PCB and then set about updating it to use modern variants of the components it had been using.

One thing that struck me was that if you consider a simple device such as a card vendor, there can actually be quite a lot of conditions that you may want to feedback to the user. For example:- Cards low, cards empty, card jam, feed jam, initializing, unrecoverable error, waiting for card to be taken, ready, vending. The units had a single LED opening in the case which was injection moulded so I had no option to add more LEDs, plus adding more LEDs would have required me to increase the component count and thus increase costs.

So, I decided I would use a two colour light emitting diode. Put the power on one way and get a green light, power on the other, get a red light, and if you're brave switch them back and forth and get a vague representation of yellow or orange.

That's four states... off, green, red, muddy yellow/orange.

OK I thought to myself, I can work with that, I'll just flash the light at different speeds.... solid green means it's OK, green flashing slowly means it's vending... you get the picture. I sat down with the C compiler I use for PIC development and wrote some code that would do this and to my horror when it was compiled it used something like 300 words of program memory.

If you're not familiar with PIC micro-controllers, they are tiny beasts, the one I was using had, if memory serves, something like 8 thousand program words available and my first crack at providing more feedback to the users had consumed nearly 4% of the available program space. I wracked my brain trying to come up with a solution to this problem and despite my best efforts after several days of thinking I was just not able to improve upon my appalling solution.

Interesting article. Of course there's a difference between writing programs on computers with almost unlimited memory compared to micro controllers but the point about keeping it simple and clean is absolutely still valid.
I think many developers (myself included) sometimes have a tendency to make solutions more complicated than the really are. The reasons can be many. Maybe you're thinking of possible future usages of your code or maybe you just want to try a new more complex solution or maybe you just don't know better. Often the truth is that you could have settled with a simple and easy solution since that's all you really need and will need in the future.

I've enjoyed reading this just like I've enjoyed reading your other articles through time. Looking forward to your next piece of writing.

Pretty interesting. Didn't know you did microcontroller programming. I'm currently exploring that stuff. I've got some ATmega and ATTiny chips here. I'd like to build some cool things with RGB LED's and perhaps do some audio projects.

The raspberry pi is also interesting. It's GPIO pins allow you to drive all kinds of circuitry and since it can run a lightweight linux distribution, it will run pascal programs as well. You'd have to set up an ARMv6 cross compiler though.

I've been tinkering with PICs on and off for about 6 years. Very cool little devices. My latest project is a digital controller for electrifying old mechanical clocks so they need very little attention (picture).

Specs of this little adventure are:-

PIC18F97J94 (64,000 words of program memory)

4x4 keypad

20x4 LCD

24 lines of 5v compatible digital IO (3 blocks of 8 bits which can be set to in or out)

Serial memory for configuration

Real time clock

Lead acid battery backup

High power DC switches for driving solenoids to strike chimes

USB interface for configuration/final setup

In one of my old jobs, I was designing a commercial version of the First East Disco Dance Floor. My final prototype hooked up to a PC via RS232 and provided an 8x8 grid. The production model was going to use an Ethernet interface so we could lay bunches of these 8x8 1m square tiles next to each other and hook them up to a drive PC using 100Mbit Ethernet (pics of this are at the bottom of this page).

Programming such small devices reminded me that sometimes you should keep things simple and compact... and that's what prompted this article

In one of my old jobs, I was designing a commercial version of the First East Disco Dance Floor. My final prototype hooked up to a PC via RS232 and provided an 8x8 grid. The production model was going to use an Ethernet interface so we could lay bunches of these 8x8 1m square tiles next to each other and hook them up to a drive PC using 100Mbit Ethernet (pics of this are at the bottom of this page).

So thic could actually be done. I have similar idea in my head for quite some time. But for my idea I would probably need a bit bigger circuit as I would use bunch of Unltra Bright LED's (about 1200) on each panel. (basic RGB capability)
So for this ethernet version would it be posible to automaticaly specify IP adress using router so that each board has its own IP.

BTW Do you sell your circuits across EU. I might have saw an electronic circuit designed by you once. I cant remember for what it was for. But that Christina Loise Warne thext on electronic circuit seems verry familiar to me.

So thic could actually be done. I have similar idea in my head for quite some time. But for my idea I would probably need a bit bigger circuit as I would use bunch of Unltra Bright LED's (about 1200) on each panel. (basic RGB capability)
So for this ethernet version would it be posible to automaticaly specify IP adress using router so that each board has its own IP.

BTW Do you sell your circuits across EU. I might have saw an electronic circuit designed by you once. I cant remember for what it was for. But that Christina Loise Warne thext on electronic circuit seems verry familiar to me.

The PIC I was looking at using for the dance floor had a built in Ethernet driver, all I had to do was add a socket with the various inductors etc. in that match the line to the circuit. Based on this, I have to assume it has a unique MAC address and thus, you could implement DHCP to provide a specific MAC address with a specific IP address. A lot of PICs have flash memory on board that you can store basic config in, but adding a dedicated config memory chip would cost you less than say £1 per PIC. Depending on volume of config you could probably get away with a single FRAM chip. Use one of your SPI/I2C channels for that, then all you need is a chip enable line (I prefer SPI for memory chips).

Driving the LEDs, I used the MAX7313. This is an I2C chip, that can drive 16 intensity controlled channels. You can pop 64 of them on a single I2C bus using their addressing mechanism, so that works out at 21 per color (don't mix colours on one chip). That yields 336 pixel capability if you were to fully load a single I2C bus.

As for selling my stuff... nope, I don't sell anything like that yet... I've not ruled it out, but to date I haven't sold anything. The difficulty with that sort of thing is cost of manufacture. You have to be sure you can sell in volume otherwise it's a big loss.

I'm beginning to think maybe we should have a dedicated electronics forum

Absolutely it is. Whilst Pi's and Arduinos etc. are cheap, if you're going for volume it's very hard to beat one time programmable microcontrollers and electronics dedicated to the one task they have to perform. Pi's et al. are fine for prototyping, but they carry a lot of baggage that they require to make them general purpose, this adds unnecessary cost which every manufacturer will be wanting to keep to an absolute minimum. Every single component on custom boards like this should have a purpose... if not, it's added cost and should be removed.

Plus, unless you start designing your own PCBs (which kind of negates one the benefits of development boards - the fact you don't have to spend a lot of time laying the board out), you can't do funky stuff like fit the PCB to the physical constraints of whatever it is you're working on. The vendor control board had to fit within the confines of the vending unit, accommodate the primary drive gear that effectively encapsulated the motor and one or two sensor mechanisms (optical beam switches). The attachments show the prototype PCB completely with hard wired programming cable so I could program it in situ in the vendor.

Pi's and Arduinos etc. definitely have a place in the engineers toolbox. I've got a number of projects I'm looking at that would be ideal for the Pi. I'm also looking at another project I designed and prototyped that has a few design flaws in it to see if I would be better off building a board that hosts a Pi as it's brain as opposed to a big fat PIC with lots of IO. Should have gone the Pi route in the beginning, but we live and learn... as a benefit of that particular project I now understand the thermal characteristics of my toaster oven that prevent it from being a good one to use for reflow soldering