 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Not teaching your grandmother to suck egg
| Author | Message | ||||
panky Guru  Joined: 02/10/2012 Location: AustraliaPosts: 1114 |
I started in electronics over 40 years ago and have been involved in everything from IBM mainframes through micros; LHF radio through SHF radar and beyond; audio, video, radio etc. etc. I've been a passionate micro fan since the 8080/6800/6502/1802 era and have spent many, MANY hours as an enthusiastic AMATEUR programmer in assembler, forth and basic. Having established that I have NO formal qualifications to provide any advice whatsoever on programming, I would like to offer the following based on my experience. When you get an idea for a new project; 1. Try to write down the basic goals or idea of what you want to achieve, 2. If you can, try to layout a flow diagram in simple form of the steps involved to step through your idea above, 3. Try to break your idea/project down into modules then try to flow chart them - ideally, each should have one entry point and ond exit point - these then become subroutines (when they don' return a result) or functions if they do, 4. Comment extensively! Even if you never plan to have anyone else use your program, you need notes so when you come back tomorrow, next week or whenever, you can prompt youself on what the devil you were thinking. 5. Use Geoff's wonderfull OPTION EXPLICIT to force you to declare (and describe with a comment) all variables and constants at the start of your program, 6. Use interrupts but make sure they are as trim as possible - ie. don't process data, just grab it and set a flag showing you have something, I am sure that many others far more experienced than me can offer other or better advice but as we are getting many new folk to our great hobby, I thought I might offer a few ideas to help them enjoy their hobby as much as I do - a very special thanks to Geoff from me for some of the most enjoyable (and frustrating when I don't follow my own advice ☺☺☺☺) hours of my life. Happy programming, Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
I agree with all of your points, although I don't always follow the first three (as I should). Especially with BASIC, I tend to jump in and write the most interesting/complex part first. Then, when that is done, I wrap it up in a subroutine and move onto the next interesting part. When I have run out of things to do the program is mostly finished!! This is just me, your way is much more robust. I especially agree with you on commenting the code. Many people thank me for the extensive comments in the MMBasic source, but I do not do that for them - I do it for myself. There is nothing more frustrating than looking at code that you wrote a year ago thinking "what on earth was this supposed to do". Geoff Geoff Graham - http://geoffg.net |
||||
lew247 Guru Joined: 23/12/2015 Location: United KingdomPosts: 1702 |
I actually didn't know what number 5 was for till I read this. Pretty good idea :) |
||||
| panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1114 |
Further to my ramblings above on programming, I would like to offer some thoughts and suggested guidelines to fault finding hardware. 1. The fundamentals:- a. Check power! Almost all equipment either needs or works better with stable power that is sufficient to supply the correct voltage at the maximum current needed. Cheap " wall warts " are notorious for being under-rated re power. b. Be methodical! Don't just jump in and arbitrarily select some component or module to change without systematically isolating it as the cause, and c. Only change ONE thing at a time! If you have determined where the problem most likely is, change just ONE component then re-test. d. The 'half-split rule'! Try to determine from end to end of the system under test, where you can 'split' the system to decide which half is faulty. Repeat until is is a choice of two possibilities. Some typical scenarios seen with the Maxi/micromites:- a. Communications! If you are trying to talk to a 'mite via USB and it's not working, try a USB to serial converter instead (eg. a CP2102 or similar). b. Communications! Isolate the PC by looping Rx to Tx on the CP2102 and checking that you can see what you type (echoing). c. Communications! Make sure you have the correct baud rate set. d. Configuration! Check, CHECK then CHECK AGAIN that you have the correct pins between the 'mite and the peripheral device you are trying to connect with. e. Configuration! Be carefull of breakout boards - they can be intermittent when using jumper leads to connect. f. Inerfacing! Windows is not all that friendly using USB, again, be methodical. A common issue that has bitten me is - i. I open a USB port in Terraterm, minimise it then start up MMEdit and try to connect? WTF, it was working just a minute ago!!! Answer-Terraterm has the port and this wn't allow MMEdit to conect! ii. Powering the 'mite off and on again will result in Windows allocating a new USB port number. Again, I offer these comments as suggestions and hope that they may give some assistance to members in the event of trying to analyse problems. Doug ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
I got so fed up with this one and having to change the config in whatever terminal I was using that I now turn this around. I use USB<-->Serial cables with the USB adapter at the PC end (and powered by it). Now I can totally disconnect the MM and the terminal stays up. There are lots of leads available with a big fat USB plug for the PC end and then some connectors (3) usually jumper-lead stylee at the other - I use a 3.5mm jack plug and have standardized all my creations to use a 3.5mm stereo socket as the connection to the 'mite. (R)ing and (T)ip nicely matches Rx and Tx and I always refer to it as "from the PC end" so the Tx <--> Rx and Rx <--> Tx is handled internally on the boards I make. Also, I exclusively use the cheapie CH340G and have dumped all other types (CP2102, PL2303... etc) for precisely the reaasons you bemoan above - I find they are rock solid and haven't had any problems at all (that's jinxed it!) I have also standardized on 9600 baud for things so I have MM.Startup with the option for that set and stashed in the library (with a few other subs & functions). This is then read back from the MM using my PicKit3 and that becomes my standard build firmware. I simply burn this into every blank PIC and it works. Firmware updates are a matter of blowing it into a PIC, loading my standard libraries and pulling it back - new "custom firmware". Everything you have mentioned in the lists is great practice. I occasionally work with other "youngsters" (20 y/o +) and it seems that what has become obvious methodology for fault finding and prototyping just isn't "in" them... I have forgotten how I was there once and how long it took me to "get it"  . They are coming along nicely - and I still learn stuff off them  |
||||
| Malibu Senior Member  Joined: 07/07/2018 Location: AustraliaPosts: 260 |
I'm sure this rings of truth to most of us that have done 'technical' stuff, even just as a hobby as needed. I heard a good phrase the other day that I had a bit of a chuckle at... "The first 90% of the program takes 90% of the time to do. The last 10% of the program takes 90% of the time to do" Maybe not mathematically true, but don't we all know that one! Good advice Doug, and yeah... OPTION EXPLICIT is something I learned to rely on a long time ago from my VB4 days! John |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5089 |
I can only support above. Write down what you want to achieve, break it into core parts. I typically engineer (program) each part individually, until I am sure I understand how it works, and what the restrictions are. I.e. sensor reading, motor driving, light control... Then I set up the framework (architecture) that can support this (i.e. interrupt driven for A,B and C, time sliced for D and E, and background for task F and G. And then the last 10% (that also take 90% of the time) starts..... Volhout P.S. and yes, I also can talk from experience only, not formal training ever. Honestly, I someting laugh and cry internally if I see what the students that do a scolarship in our company have to do. The first 3 weeks they are here they make a plan, timeline, full color interactive presentation (which they have to defend at the end of their period, and see if they meet their targets), before they even investigate the complexity of the task. shhhhhh. PicomiteVGA PETSCII ROBOTS |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
I think it's the way they've been taught. And they were taught it because... there's an attempt to deskill this / teach it as if writing software is like working on an assembly line. But it's not very suitable for software (at least not in today's world). I think too many people fail to realise there's quite a creative / visualising aspect to software. A similar approach to teaching how to paint such that you'd be a great artist would be an uphill task, too, and for similar reasons. Oh well. To defend it... we want a lot of fantastically talented software people and have no better idea (I suspect) how to get them! (Just waiting for them to self-learn or whatever is all very well but produces far too few.) John |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
