I just found a thread from about a year ago (https://www.ghielectronics.com/community/forum/topic?id=7723&page=1) that proposed starting a new forum area dedicated to programming practices that achieve good (maybe even optimal) performance. I’d like to add my support for this idea.
For my day job, we’ve been working really hard at developing a gizmo that has to run unattended in the ocean for years at a time and I’ve been really happy with the results we’ve achieved with .Net Micro. The process has been pretty painful at times and the people on this forum have been incredibly helpful answering my specific questions. However, searching the forum for answers is pretty hit and miss and I have a nagging suspicion that some of the lengths we have gone to to achieve what we think is robust performance may have easier or better solutions.
I think we’d be doing the entire .Net Micro community a service following up on @ leforban previous suggestion with an area on this forum dedicated to good programming practices.
This could have the advantage of being organized in a way that makes searching for answers much easier and might generally improve a lot of people’s .Net Micro programs. As a very specific example, a lot of discussion has gone on scattered around in this forum about how to read messages from a GPS receiver through a serial port and then parse the message. I can see a thread subject titled “Good programming practices: serial port” that someone starts with a post describing an approach that someone uses that works well for them. A second thread subject might be titled “Good programming practices: Parsing GPS (or any ASCII) messages” Obviously, people would chime in with comments, criticisms, alternate approaches with better performance, different functionality or whatever and this discussion would be invaluable.
I know this can be done in any one of the existing forum areas but the search results would be lost in all the other messages with “serial” , “port”, "GPS, “NMEA”, “parse” key words.
In general, on a very memory and cpu constrained device, especially one with a garbage collector, you want to minimize allocation on the heap, and wasteful practices like boxing. Pretty much everything else is just practical application of that advice.
@ Gene - I think this is a great idea. The document library provided by GHI is very good, but not all subjects are covered, and sometimes more device-specific or NETMF-version-specific information is needed.
@ godefroi -I agree with you, but for beginners, and for not-so-sharp guys like me, it’s very difficult to figure out the best or most-efficient way to do something. As @ Gene said, searching for something on this forum is like searching for a needle in a hay stack. Having separate threads dedicated to specific topics of design or implementation would make life a lot easier.
I am not sure if a forum, even when it is a seperate board is the best form for this. An index or toc would be way better than searching through a forum board. Generally a Wiki would be perfect, but as always it needs discipline and strict rules to keep it nice and clean. The GHI wiki was nice in some areas, but even GHI decided to switch to an even stricter method (which is read only for comunity I guess). Being able to write entries for the documentation sector would be nice. GHI could monitor these.
An approach like code project articles would also work. There the higher ranking comuniy members have to approove an article before everyone can see it.
Edit: It might not even be a bad idea to use something like code project ( http://www.codeproject.com ) for this. This would spread the idea of NETMF/Gatgeteer even further.
The downside is that it’s not our community who monitors new articles.
We would need to tag all articles with NETMF/Gadgeteer. By this they are easy to find.
May be we could get an arrangement with the site operators so some of us could monitor articles with that tags.
The problem I see is that a “best practices” forum is just too vague. All too often the “best practice” evolves during the course of a thread discussion about some other more specific problem. Perhaps what would be more useful would be if posts could be tagged as a “#GPS#BestPractice#Raptor” and we could then search using any combination of the three tags?
A forum is not the best place to keep best practice documentation. But, a forum would be a good place to discuss a specific practice, and when an agreement is reached, someone develops a document which is then stored in the document area of support.
@ Mike - While I understand wanting to go that direction, I think it probably would not really be populated that often. Also, I don’t believe there are that many general best practices. I always think about serial parsers when we talk about this. Just about every time I have to parse serial data the parser looks different. I think inline code samples that are included as part of the “story” (thread) would be just as useful and would take a lot less effort to implement.
Perhaps the essence of the problem that Gene is bringing up is the difficulty of finding what we want in the forum. There is a large amount of fantastic information in here, just a bit hard to find in a complete and organized manner. From Gene’s post:
“I just found a thread from about a year ago…”
“searching the forum for answers is pretty hit and miss and I have a nagging suspicion that …[there] may [be] easier or better solutions.”
“the advantage of being organized in a way that makes searching for answers much easier”
I’ll add that it is frustrating to find good info in an older post, but adding to an older post is not good practice. And new information on the topic may be posted but there is no link into the future (obviously.) Gene’s suggestion attempts to address this by opening threads that would not grow stale.
There may be a variety of ways to improve our ability to find stuff on the forum. Not sure if a more powerful search engine is the answer or not, although Google sure works on the internet at large. Tags and/or permanent threads?
Here are a few “best practices” topics that I think would be useful. There are always repeated questions on these topics from beginners and experienced members alike.
Provide NETMF 4.1 and 4.2, Premium and Open Source, regular NETMF and Gadgeteer versions of the following:
[ul]
Network Initialization
Handling network cable connect/disconnect
Handling network blocking code (with other threads, etc)
Serialization
SD card initialization
Handling SD card insert/remove issues
Serial setup and comms
CAN setup and comms
I2C setup and comms
Creating and managing large buffers
RLP tips and tricks[/ul]
If I’m reading this right, it looks like people generally agree (not everyone, but most) it is a good idea but how to do it is up for discussion. It would be great if some expert agreed to act as moderator but I’m guessing that is unlikely. As a way to start, I’ll volunteer to post a new thread on the .Net MF part of this forum titled something like “Serial Port Best Practices”. Not because I’m anything like an expert, but I’m willing to start the ball rolling and see what happens. It might take me a few weeks to get to it, but I’ll be interested to see what happens.
I’d also like to add the following to @ jasdev’s list.
Minimizing and dealing with Garbage Collection
Design Patterns (e.g. state machines, sequencers, producer/consumer, publish/subscribe, Gadgeteer dispatcher, etc.)
Anyone else willing to volunteer to start a topic?
How about adding a 3rd category to codeshare. Snipet, project and "best practice/module usage,…"
By this we would have an introduction, code, tags and a forum thred to discuss and evolve it.
A snipet with an extra tag “best practice” would work too I think.
Speaking of good programming practice, I had a look at the driver for the Temp Humidity module, it creates a thread that continually runs (with a Sleep(100)) regardless of how the client is requesting measurements, this is NOT good code :(,
Something about the suggested approach is bugging me. Seems we would be in danger of proliferating rather than organizing, e.g., I would welcome info on the topics suggested and can see you and raise you another list. I think others can come up with yet even another list and god knows what topics the future will bring. Who decides what threads to start? Is there some way to tie into the existing posts on these subjects as well as get organized for further posts? E.g., can the “best practices” be a wiki index to existing (and future) posts on the subjects, e.g., users would add links to the index as they find or post relevant info. Having permanently open threads for each subject seems a big part of the “best practice” lists. Also not convinced that an easy to use and powerful search engine would not be better than attempting to maintain best practice threads.
It seems not so easy to find the most valueable solutions.
Some Codeshare entries may be perfect code but are outdated in the meantime due to new versions of NETMF or GHI SDKs.
Some Codeshare entries may be bad programming practice but are valueable because of being the only working solution.
Some Codeshare entries are: Great that someone did it… Im sure Ill need it some day but nobody ever tried if it really works.
I agree with jasdev that there should be a list of some standard software that should be kept up to date concerning NETMF and SDK Version. As there are already the GHI NETMF and Gadgeteer Tutorials this should be the best place.
Concretely for evaluation of Codeshare entries I suggest that there should be the option for the community to evaluate Codeshare entries in three categories:
Like the idea.
Successfully tried.
Propose as Best practice
Perhaps 2) and 3) could have a link to a list with short (one line) comments
For Codeshare entries with more than 3 Best practice votes there should be links from the Tutorials section. If there is no Best practice link, there should be also links for Successfully tried with more than 2 votes.
@ RoSchmi - My quick reaction is something like that would be useful. And I could add a few more check boxes to the list:
Platform: NETMF, NETMF Gadgeteer, FEZ Medusa, FEZ Lynx
SDK version (4.1, 4.2, 2003 R3, …)
I’ll bounce the idea around here. We’re always working on something cool & new for the whole website… don’t know what priority rest of the team would give this and/or if they would like it?
May be something organised by domains of application with some recipes to have good code in term of performance. Actually something like GHI already did in the tutorials section would be a good starting point if it can be associated with a dedicated forum thread.
In others terms:
tutorials: code for readability vs code for performance
I’m pretty happy with things the way they are now. I think we should just discuss code contributions more often. And it’d be nice if GHI improved their Search feature. I’ve used Bing/Google before to search GHI’s site because I found my results fast that way.
But I think best practices are supposed to be high-level concepts. For example, these are a few of my high-level “best practices” …
Use hardware features, bitbang only when necessary.
Use interrupts and events instead of polling.
Use static variables to prevent garbage collection when appropriate.
Invoke garbage collection when you have time to spare.
If you can, put your device to sleep when nothing is happening. I use the keypad interrupt to wake my devices and there is zero noticeable lag.
Turn off everything possible (analog power, etc.) before going to sleep.
Always keep 10-20% of your memory free for the runtime and GC.
Build and use your own PK runtime.
Consider ASM, C and C++ when performance is a problem. Interop when appropriate.
Use Binary over ASCII/Unicode when possible (for example, GPS modules often support SiRF binary mode and this will be more efficient than ASCII).
Ill agree with Untitled and double down on my thought that the problem and the solution is the search engine. Frankly, the existing engine sucks and ive also tried using google instead. If we got a better search engine, than 90% of what is being suggested here would not be necessary. Plus we would enter the 21st century.