Why so quiet?

Well, here's why I don't post my code here.  Very simple: I can't upload documents.  Most of my code is in the form of .zip files containing source code and documentation.  Code Exchange lets you create a 'blog or a discussion, but I can't find a way to upload source code files.

So I uploaded my code to the FPGA Group since I'm a member of that group and it allows uploads, and my XXICC project does include logic design for FPGAs.  For XXICC releases 0.0j and 0.0k I created "mothership" 'blogs with links to the FPGA group content.   XXICC has since become much more oriented towards FPGAs, so now I use the FPGA group for almost all XXICC content.

John is right about the uploading.

But there are so many other places to talk about code, there's quite a bit on E14 under various blogs, Arduino etc.

And if you want to ask a  code question like:

what's the definition of strngcmp in c (function name deliberately mis-typed !!)

you just Google and are offered zillions of results for strcmp() which is what it should have been.

So the E14 Code Exchange doesn't currently have a niche where it might usefully operate.

MK

This is primarily an electronics place with some sideline coding happening. There are other places where coding is the highlight. Plus other than johnbeetem, I do not see anyone coding here.

Clem

Clem Martins wrote:

 

This is primarily an electronics place with some sideline coding happening. There are other places where coding is the highlight. Plus other than John Beetem, I do not see anyone coding here.

I see lots of people coding here, and many code-based projects.  Two examples that immediately come to mind are Cypress PSoC 4 100 Projects in 100 Days and the enormous shabaz oeuvre.  However, coding projects tend to reside at the group associated with the project's hardware.  So you see Arduino stuff in the Arduino group, PSoC stuff at Cypress Kits, FPGA stuff in the FPGA Group, and general-purpose Embedded stuff in the Embedded group.  So is there really a need for Code Exchange, given that so few even know about it?  As mcb1 likes to point out, a lots of newbies post their first questions at Ben Heck because that's the group they find first

Regarding the "other places", I do think element14 is a nice place to ask coding questions.  In software-only sites, you often get stereotypical computer science types who are rude and insensitive: think "Malvin" AKA "Mr. Potato Head" from WarGames (1983).  I find that computer engineers with lots of practical embedded coding experience have been humbled by the process and are a lot more helpful, friendly, courteous, kind, etc.  That certainly has been my experience with the great people who hang out at element14.

JMO/YMMV

johnbeetem

Nice summary John.

I think I looked initially at Code Exchange and then probably haven't been back since.

Many of us on this site aren't software engineers, so we can sympathize with steep learning curves, and weird naming, etc.

The best suggestion I can make is make sure you do your homework/Google search before you ask us to search for you ....

Mark

I fully agree with the views on the "other places". I'm not new to coding, but often find myself looking around the internet for specific syntax related stuff or sometimes a more efficient way of achieving my results and have often seen a lot of aloof rudeness in the whole area. Being somebody who uses multiple languages, I often check myself against what others have done because it's one thing being capable of programming with  multiple languages and another thing entirely spending my time understanding just one of them by the roots like you find on forums. Sometimes signing up and starting an old thread back up can result in a mini flamewar until you drop the bombshell it's for the purposes of an embedded system lol! that tends to quiten them off!

I just wonder if the area is too vast for a linear topic approach. Maybe have sections for Python, C etc.. plus theres the issue of device capability, where some parts of code are interchangeable between devices and other parts are device specific.

One skill that Ive been building on lately is structuring programs by devising a simple overview on paper, breaking it down and then developing code around that, rather than just sitting down to a blank textfile and typing away blindly.. It'd certainly be nice to see how other people go about doing this kind of thing and would imagine there are a few different approaches. Maybe content like this would be more realistic and helpful than language or platform specific snippets of code?

Lucie

lucie tozer wrote:

 

One skill that I've been building on lately is structuring programs by devising a simple overview on paper, breaking it down and then developing code around that, rather than just sitting down to a blank text file and typing away blindly. It'd certainly be nice to see how other people go about doing this kind of thing and would imagine there are a few different approaches.

I find that most problems worth solving require a significant amount of off-line work before sitting down to code.  Many problems require walking around, preferably in nature where I'm free of 21st Century distractions.  I keep a notebook or some scraps of paper handy to jot down ideas.  Then I expand on them in a notebook when I get home.  When the ideas are starting to form, it's time to start writing them up using my favorite word processor.  I'll eventually need documentation, and doing it early means I benefit from it as a developer and it will be better documentation since I'm writing it at a creative phase of the project instead of as a hurried afterthought when I'd rather be working on the next project.  It's a lot easier to fix a problem when it's still in the word processor than having to rewrite swaths of code.

You may have noticed that I haven't started coding yet.  Well, if you do a good job of mulling over your ideas and documenting them, the coding takes care of itself.

I should mention that I learned to code in the punched card era, when you had very limited access to computers and you couldn't just hack away at a program until it seemed to work.  The latter approach would lead to long, sleepless nights and poor quality code.  Putting in a lot of careful thought early on -- including (gasp!) flowcharts -- meant you could go home early and get some sleep.

I don't get hackathons.  You kids get off my lawn!

Lol!

That is so true!

Until I learnt better, I used to just sit and start typing; getting confused, going around in circles and becoming very blinkered in a particular area which would have benefitted from taking a deep breath, a step back and looking at the problem from a fresh angle.

I've used flow charts to work out heavily conditional related pieces of code but only recently have I started fully planning software projects on paper and working them out in an easy to understand real world method. Replacing those real world methods with actual code is so much more straight forward!

Lucie

Lol!

That is so true!

Until I learnt better, I used to just sit and start typing; getting confused, going around in circles and becoming very blinkered in a particular area which would have benefitted from taking a deep breath, a step back and looking at the problem from a fresh angle.

I've used flow charts to work out heavily conditional related pieces of code but only recently have I started fully planning software projects on paper and working them out in an easy to understand real world method. Replacing those real world methods with actual code is so much more straight forward!

Lucie

I like paper to make the decisions/ideas on.

It's also so much easier than writing on the twink (correction fluid) on the screen if you make a mistake.