commonCode (not exclusively for AVRs)

https://hackaday.io/project/6450-operation-learn-the-mips-pic32mx1xx2xx/log/20769-wins-and-tcnter

https://hackaday.io/project/4159-sdramthing45-logic-analyzer/log/20379-on-hold-weird-reminder-of-why

Seriously... if the "blinky" example supplied with the PIC32 compiler is as friggin' complex as it is... _commonCode's complicated makefile setup ain't *nothin*!

Have been working toward porting _commonCode to other systems for several years, now... For the most-part, it's been limited to AVR and Desktop PC applications, mainly 'cause that's what I had to work with (and experience with).

Some of my *much* older code was originally written exclusively for AVR, but when I revisited it the last time I intentionally spent quite a bit of time/effort abstracting it, despite the fact I was revisiting the code *for an AVR-project*. Kinda ironic, I guess, or something. So, in that process, I used OpenGL (on my desktop PC) to run the same code and sort-of simulate motion-control with pixels instead of an X-Y motor-based system. Really, quite backwards, but kinda interesting nonetheless, learned about OpenGL, came up with some uber-simple "game" ideas, and a few other things in the process.

Anyways, all that to say, motion-control, sensors, low-level serial protocols, etc. are *very* difficult to simulate without actual motors, or whatnot, and real-time low-level interfaces... Thus, more abstraction of lower-level commonThings like these via... #operation: Learn The MIPS (PIC32)

Been working on a script to upload commonThings... It still needs some work, but there's an initial set of results at: https://github.com/esot-eric-test?tab=repositories

I think it could work...

There's a funky-factor which isn't *really* common enough to think about, right now... but apparently some characters in filenames are not acceptable in git repository names (especially: '+'). And it doesn't tell me so, it just replaces the '+' with a '-' and acts like everything's peachy. Wee!

Another rabbit-hole, I suppose.

These uploads aren't exactly "ready for the public", but they're there. These are extracted/uploaded from https://github.com/ericwazhung/meh-heartbeat. So, I guess, when I get around to the download-aspect of the system, it should be a matter of something like downloading the heartbeat-project's makefile into a bare directory, running something like 'make getdependencies' then 'make run'...? There'll probably be a few more steps/files, a project-skeleton of sorts. I dunno. It'll be interesting.

Finally looking into some coding again! WEE!

Check out #PotentiallyUseful/Frustrating/Obscure C/GCC/Make

...wherein there's a couple new updates regarding my adventures on efforts toward making commonCode a bit more... public-ready.

Also, have a vague idea floating around my mind regarding how it might actually be doable via git. NO WAY!

Yeahp... something about scripting uploads, and having different repositories for every [public] version of every commonThing... which, really, might not be so bad... (though, frankly, it'd be easier with ftp... those days are long-gone. besides, publicly-modifiable is a pretty cool thing that ftp didn't lend itself to).

And, a vague 'something more', with using git-pull in the makefile... when a commonThing is a needed-dependency, 'make' would automatically run the git-pull request... It'd be kinda cool, but having been on a relatively-flaky 'net connection for quite some time, I wouldn't mind an all-at-once download option... that'll have to be saved for a later day.

...wherein, it starts to look even more like 'apt-get' or 'macports'... hopefully we can keep this *somewhat* dependent on only the sorts of things that don't have their entire interface changed with every version! 'make' and 'bash' have pretty standard and backward-compatible interfaces... but what about git... maybe curl, or wget? Thoughts?

NO I WILL NOT USE PYTHON. (Really, I think they should call it Cobra... isn't that the snake that hypnotizes its prey? "No, really! It'll be alright. This is the path you were looking for.")

Hey! I got my very-own entry on the HaD Blog! Thanks @Benchoff.

I'd also like to thank all the new followers and skulls, awesome!

Decided to revisit "reallyCommon3.mk" and the new file-structure...

This is the latest-version of the system, as of a few months back...

And, as-yet it's only been implemented in "hearbeat" (and the new file-structure isn't yet available to the public)

The last-status was, I looked at it and realized it was *way too complex*; this relatively-simple "blinky" example requires *dozens* of files, and several in the main project-directory, alone. So, check out the old-logs, and you'll see I've been somewhat tormented about continuing down that path.

(the "reallyCommon2.mk" system had fewer necessary files, but they're also somewhat impossible to comprehend...)

...

This time... well, maybe it's not *so* bad.

Sure, it takes quite a few files... that's kinda the point of reusable code.

The main thing that bugged me, I think, was how many files are in the main project-directory... the number of files which have to be modified to begin (unless you're using the default-specs/devices).

But, really, it's not *that* bad... Some of those files are really little more than explanation with a few lines of code/options that can be reused from project-to-project.

And, again, this phase of the project is less about the actual code "libraries" than the means for distributing/implementing/centralizing it.

That part of the system is what I think makes this somewhat unique (though I recently found something similar through one of my new followers, actually a prize-entry from last year, and quite-possibly more sophisticated, that I need to look into a bit more).

Anyways, the commonCode system could be a useful sort of cross-platform [not limited to embedded] design tool... Sure "heartbeat" *does* little more than a typical "blinky" example project, but it's the entry-level project for the same commonCode system that has enabled larger projects that I consider significantly more sophisticated (including some desktop-based OpenGL projects). Once the system is understood, it should be applicable to nearly any coding-project, embedded or otherwise, and many of its "libraries" are already device-unspecific.

So... I dunno, it's a bit [maybe significantly] higher-level than setpin/clearpin used in most beginner blinky-projects. But I guess it sorta straddles the low/high-levelness of things like libmath, stdio, and runtime-libraries... But I guess that's kinda where embedded projects lay.

Still a bit to be contemplated/done before I consider heartbeat/reallyCommon3.mk/new-file-structure ready for alpha-testing.

(You may have seen heartbeat on my github... Apparently that's based on reallyCommon3.mk, but doesn't implement the new file-structure, which was a huge change, the one I'm still debating. Among other things, it's *supposed* to allow for a device-unspecific distribution... the same download would be usable for both an ATtiny85 AND a desktop/console-based test-application via simple configuration-option... Anyways, there's a bit to think about, and a reminder why I'd been contemplating whether this system is distributable via something like gitHub. Hey, if you've got an ATmega328p and want to give the old-version a try, it's still up!).

A Brief Implementation Note:

This project aims to use only tools which are available on most development-systems... It relies on Bash, Make, [GC]C, and a few others.

The "distribution-system" aspect is handled by make-commands, a few (bash) shell-scripts, and some calls to things like rsync.

Though, I'm trying to keep its dependence on things-that-change-often to a minimum. (E.G. Why bother using a scripting-language when its basic-interface changes with every version?!)

(This'll probably be moved to the project Details section, but I can't figure out where to put it right now).

2015 HaD-Prize Entry Notes:

Decided to submit this as a 2015 Hackaday Prize entry. Why not, eh?
After all, it is probably the most potentially-world-changing project I've done.

I don't really know how this'll go... I've been in a project-slump for quite a while, now. Also, this particular project last went in a path that might've been counter-productive... at least as far as making it public. Again, it's a core-piece of nearly all my projects, so tends to get updated (on *my* side-of-things) almost as often as any projects I may be working on (which is none, lately), and so-far seldom gets developed *solely* for its own development... Who knows, maybe this'll be that motivation.

Also, there's the issue of making it public...

I like the idea, believe me... but I don't know how to go about it. It's "my baby," yahknow? I'm sure suggestions could come through that could take it on entirely different paths, plausibly using entirely different tools, potentially bloating it beyond my aims, potentially creating "branches" that are no longer compatible, possibly even others taking some lead... If I was in "normal-project mode" that's *the last* thing I'd want to have to deal with, as I'd rather just be *using* it for the project. I've gone out of my way to make this system backwards-compatible every step of the way, while also trying to prevent bloating... We'll see. Maybe when/if it comes to the point of a single-distributable-system, I'll be less clingy.

Revisiting "polled_uat", which is the bit-banged UART code (without a receiver)...

This one goes back a bit... its test-code is based on "reallyCommon.mk." A couple project-logs back I was referring to "heartbeat"'s test-code is now being used to develop "reallyCommon3.mk"... and, yeah, there's usually a year or more between each "reallyCommon#.mk", so apparently "polled_uat"'s test-code is a bit behind the times.

It doesn't *really* matter, in the grand-scheme-of-things... or maybe it does matter, there, but not in the tiny-scheme-of-immediate-things... or something.

But, what it does mean is that I've been developing [with] this test-code all day, and appear to have run into an old bug that was *very* seldom run-into... so seldom I almost completely forgot about it... so "almost completely forgotten" that I've, quite literally, been scolding the universe for playing games with me for... are we at hours now?

Granted, I'm somewhat certain "the universe", whatever that entails, is in fact playing games with me, and deserves a good hours-long-scolding quite often (maybe even more-so than I do, even though I do-so very often)... just, maybe not in this particular case.

[And, quite literally, when I hit enter after "just maybe not in this particular case" my computer 'blue-screened'. Something it hasn't done in over a week. "UNIVERSE!" Actually, I'm starting to think this so-called "Universe" is masochistic and sadistic all at once... It seems to get a kick from constant scoldings, and seems to get a kick out of earning them in sadistic ways. What, then, can someone neither into sadism nor masochism--and certainly not into them enough to justify not being able to hold down a damned job or otherwise earn enough income to cover the bare-necessities and a tiny bit of extra for a sense of independence and freedom from time-to-time... What, then, is a person in such an undesired sadomasochistic relationship with "the universe" supposed to do? Please, I really am looking for suggestions.]

(Oh, and thank you to "Lazarus" for resurrecting what would otherwise have been lost, here... I was a bit heart-broken at losing that, I found it a bit funny. Not the experience, the writing of it. I still do not forgive you, for most everything, "universe".)

So, where was I...?

Oh yeah, so I was kinda unexpectedly thrust into the position of updating to the newer "reallyCommon3.mk" in "polled-uat"... after, of course, hours of scolding the universe.

And then it hit me...

"reallyCommon3.mk" was supposed to be *the thing* that was going to be distributed... I put a lot of effort into that jump from 2 to 3, sheerly for the sake of making it public. And... now I'm reminded (again, after scolding "the universe" for hours), why "reallyCommon3.mk" isn't really ready for the public. Nor, really, is it even ready to be implemented in another "commonThing," at all. Nor, really, is it even ready to be revisited... In fact, part of me kinda feels like scrapping it entirely. Which... frankly, would be heartbreaking. And, in fact, is a bit of a (mental, at least) set-back as far as whether this thing is anywhere near public-worthy. And, in fact, is a big blow to my idea that maybe one day its making-public-[ready] could be crowdfunded.

But, yahknow, heartbreak, broke-ness, hours-long-scoldings... I guess I'm getting somewhat used to this sadomasochistic relationship with "the universe"... like the way rats get used to being in cages and experimented-on... Yahknow, in that way in which, I'm pretty certain, if the rats had a say in it, they'd almost certainly choose to wander sewers and even risk the occasional run-in with temptation from a "rat hotel", rather than be experimented-on in horrendous manners... THAT kind of "used to it."

It would seem...

Google-Code is doomed to doomedness.

WTF.

Don't get me wrong... It sucked from the moment I linked my account.

But.

It's Google.

So. I'da thought...

It'd've been 'round for a while.

So, forgive me... I looked at that email as though it was nothing but a trojan... plausibly a joke.

But, it has since been proven to me.

That... Yes. The Big G... Is not the Leader Of The Free Software Revolution (anymore).

I learned some shizzle in the process.

(wasn't there a lady in potential for tonight...? WTF am I doing here, fighting some werid-ass (yes, that's the word I typed over a minute ago) so, backspace is darn-near impossible... esptiptes only 75% CPUusage.... WTF is going on..........?)

... wasn't there a lady in potential tonight...? WTF... The Spurious CPU-usage has seemed to drop dramatically since I acknowledged that said-lady is probably already closing-shop for the night... Dare I relate these concepts...?

ANYHOW:

I learned something tonight... Linus Torvoldez himself allegedly developed GIT for the very purpose of Linux-Kernel-Development.

No Joke. This was ... not quoted-from... but understood-from: (...apparently the very page that's bringing my CPU-usage to darn-near 100%.... ...two minutes later... can I copy-paste...? Project Hosting on Google Code will close on January 25th, 2016.

...is not what I copied. And... where is this 100% CPU usage coming from...?

NO FRIGGIN' JOKE... 20MIN LATER:

Git Ready

How to explain this paradox? It's all about Git, the "version control" software on which GitHub is based. Linus Torvalds, the creator of Linux, created Git in 2005 as a better way to build Linux. Git made it easy for many people to work on the same Linux code at the same time—without stepping on each other's toes.

In short, Git let anyone readily download a copy of the Linux source code to their own machine, make changes, and then, whenever they felt like it, upload those changes back to the central Linux repository. And it did this in a way that everyone's changes would merge seamlessly together. "This is the genius of Git," DiBona says. "And GitHub's genius is that they understood it."

GitHub created a site where any other software project could operate much like the Linux project—a site the average coder could easily grasp. "GitHub is just really smooth," says Rob "CmdrTaco" Malda, who lived through the open source revolution as the editor-in-chief of the tech site Slashdot. "It's a sexy, modern interface."