Application Notes

[geezer88]

Having read this forum for a couple of years now, I'm impressed with knowledge folks are sharing on a whole bunch of topics. While search will bring up tons of posts, only a few are likely to be really useful. So here's a suggestion for Technical or some other of the Gurus: Write up some application notes that discuss a particular topic. Here's two examples:

Serial Communications: Over time the PicAxe has evolved in serial port capability. A thorough review of the capabilities of the various port commands, what they are best suited for, and lots of code examples would be great. Have all the tricks, tips and advice distilled down into a single document.

Timing / Counting: These fundamental tasks are constantly being discussed in the forums, with great advice sprinkled all over. Related is the math needed to calculate rates. Ie. rpm, mph, or widgets per fortnight. External vs internal clocks. Do I count ticks of a rotating shaft, or use pulsein for periods of rotation.

There are probably several more application notes that would be very useful, but these are the two that seem to have the most mystery to me.

Anyhow, I'm not asking for help with any specific problem, but rather would like to see if someone could put together some really comprehensive notes on focused topics.

tom

 

[mrburnette]

Tom,

Wow, I had the same thoughts when I first joined the forum. What I have learned, however, having worked inside the forum for months, I have come to realize that 'categorizations' simply cannot cover all the aspects. Communications sound like a simple topic and there is a specific forum for thus, but if you review that forum, you will see that the scope is very huge... I2C, bit-banging, RS232, Infrared, Morse, WiFi....

The PICAXE is just too versatile to be narrowly pigeon-holed into a few accurate categories. I have found myself taking my iPad and just reading posts, using the bookmark feature to build my own categories of interest and my own code sample libraries.

- Ray

 

[inglewoodpete]

It is a topic that I have been contemplating recently. I may or may not be considered one of the "gurus" so please bear with me if I am deemed 'not'.

The topic that I was tossing around was the one of serial comms. There are so many facets to be considered:

• PICAXE <--> PICAXE ^
• PC <--> PICAXE ^
• Foreground/BackGround ^
• Handshaking (forground) ^
• Balanced/UnBalanced bearers (RS232 ^ or RS485)
• PC Software development ^
• Link supervision ("lost synch" indication) ^
• Multidrop networking
• Minimal Hardware solutions

I have experience in many (^) of the above points but not all. So, to write a comprehensive document, I would need to do research and development of possible solutions in the areas that I do not have practical experience. What is required by the forum is not a theoretical paper but a practical one with hardware and software examples. With a full-time job, a family and several PICAXE projects in the pipeline, the whole subject becomes a bit daunting!

Don't get me wrong, I'd love to write a document on serial comms for PICAXEs. However, I'm doing a redevelopment of my PICAXE-based home theatre controller at the moment and Santa gave me a PIC32 development kit that I have bearly touched since Christmas. Maybe I need counselling - I want to do too much! I imagine there are many forum members that could tell a similar story and I commend everyone who does take the time to write the App Notes.

 

[srnet]

Problem with applications notes is that whilst its an easy suggestion to make, it can represent a huge amount of work. I have written some explanatory notes for some programs I have written, and such documents usually represent a couple of days. Fine if you have that spare time.

There was a time when Engineers relied on application notes and datasheets, in the days before the Internet there was no other way. These days I think they have lost their usefullness, most people dont read these things anymore (or manuals!!!!). Its just too easy to ask a question on a Forum to get others to do your research for you.

 

[westaust55]

Problem with applications notes is that whilst its an easy suggestion to make, it can represent a huge amount of work. I have written some explanatory notes for some programs I have written, and such documents usually represent a couple of days. Fine if you have that spare time.

There was a time when Engineers relied on application notes and datasheets, in the days before the Internet there was no other way. These days I think they have lost their usefullness, most people dont read these things anymore (or manuals!!!!). Its just too easy to ask a question on a Forum to get others to do your research for you.

Those who do the research keep their mind more active which may lead to faster and improved/retained mental skills.

 

[tinyb]

As someone who is going throught the process of rewriting some documentation to fit the picaxe - it is not an easy task. the coding and playing is easy, but the writing and formating take time. there have been many discussions along these lines over the years (on this forum for a while now). the best suggestion would be to write up your little trick / skill / knowledge base and put it in the appropriate finished project forum or write a blog in the new section just opened up last year - or even enter it into the monthly picaxe contest.

thanks to all the peolple asking the questions but a big thankyou to the people answering them..

thanks
tiny

 

[hippy]

Problem with applications notes is that whilst its an easy suggestion to make, it can represent a huge amount of work. I have written some explanatory notes for some programs I have written, and such documents usually represent a couple of days. Fine if you have that spare time.

As someone who is going throught the process of rewriting some documentation to fit the picaxe - it is not an easy task. the coding and playing is easy, but the writing and formating take time.

That really is the bottom line; it takes a lot more time to create documentation than it does to read it and the amount of effort isn't always appreciated until one does it.

One of the hardest parts can be being in the right frame of mind that the words flow fluidly, and then there's getting photographs, diagrams and circuit diagrams as well when appropriate, and of course code has to be tested and hardware built to do that.

For simple examples it may be reasonably to moderately easy, but as one goes more in-depth, covers more alternatives and possibilities, that can create an exponential explosion of work and there's an increasing danger of 'burn-out' or 'writers block' before it is all completed.

And all that work has to be fitted in with other tasks and it's not usually something one can schedule as simply as setting aside an hour and knocking-out good documentation. Some people are better disposed to crafting documentation than others but for most it does unfortunately come down to 'easier said than done'.