A thread which is to contain an account and chronicle of Plaas' bumbling quest to learn how to program the PIC16F628 chip.
I thought it was hard to find stuff on our project site. We can't hold a candle to the disorganisation over at the SDCC site. I finally found that I had downloaded a binary of SDCC that worked fine... except that it didn't have a pic folder in it. I haven't a clue what that's all about. :-s
Anyway I have a pic folder now. Back to chimpanzees on typewriters mode. :-D
I hate to tell you this, but the version you downloaded won't actually work properly.
The whole exercise of getting the firmware to build under Cygwin is a little non-trivial and I think you're opening a pretty nasty can of worms for yourself.
That's not to say it can't be done, but I'm guessing it might require a few little tweaks to the build process, which will mean learning gmake syntax and some other stuff if you're going to do it yourself. It will be a lot to learn to make a small change.
Then again, it may just build if you're really really really really lucky.
***I hate to tell you this, but the version you downloaded won't actually work properly.***
I'd pretty much figured that out. Thanks for the confirmation, though. I'm running sdcc from a cmd window with more success.
I mean, sdcc itself won't work, no matter how you run it (cygwin or cmd). It may look like it works, but the code it produces won't run.
The problem is you need really specific versions because they keep breaking and unbreaking various bits of the pic14 code. You have to get the combinations just right so that it's in a fairly working state overall. Part of what the makefile does is check out and build a version that will work, but as a consequence it complicates the whole process somewhat.
Using the makefile is probably easiest but it will require some work first. Or at least generally following the steps it uses, but that will still require checking out sdcc (requires cvs), compiling it (requires make and gcc), and so on...
Tell me again why you picked SDCC then? From your description it sounds to me like SDCC and Cygwin would be the absolute last thing you'd want to specify for an open source technology project. :-0
Well nothing on Windows makes it great for open source projects really :)
But given that isn't a variable, then cygwin is great. Nothing wrong with it, and it's not causing any problem as such here, it's just that the build process hasn't been tested on it and it often needs a few tweaks. That's not a condemnation of cygwin, it's just usual when switching platforms. On the whole cygwin does a very good job, it just hasn't been given a chance here yet.
sdcc is one thing that does cause some problems. We're using alpha versions that are not exactly ready for production development so we have to take a few curves here and there. sdcc is also an excellent project and for the other architectures it supports, it does a great job. PIC14 is slightly tricky from the outset from the point of view of compilation, so on the whole they're doing a damn fine job too.
There are no other open source or even decent free C compilers that I've seen yet for PICs.
Besides, if you hold your tongue right (ie use the makefile), it works so it's not something to be too concerned about -- we've already done the hard work to make it go so why go through that again with another compiler? There are still a couple of wrinkles to iron out in the make process even on Linux. It works great for me, but not so great for some others. It looks like a very minor issue with include files, but I can't easily fix it until I have a way of replicating it.
I will do some testing on cygwin someday soon no doubt, and we'll get it going there too.
Wow... this seems like a hell of a house of cards to build so that you can programme in C. I can understand the "free" part, but by your account its going to be pure hell to do a technology transfer if anybody else wants to get into doing embedded programming for reprap controllers.
I guess I don't understand why you didn't just go for the Microchip's free IDE. I realise that it's an assembler rather than a slightly higher level compiler like C but jeeze...
Your "slightly higher level" is a bit pessimistic. I've been programming in assembler and about ten high-level languages all my adult life, so I optimistically claim to know what I'm doing in both. But with C on a PIC I can do in 10 minutes what takes me two days in assembler.
Your "slightly higher level" is a bit pessimistic.
I guess it depends on were you're coming from The second language I learned was after Fortran II was APL. You kind of get spoiled when you can do matrix inversions with the expression...
...and the dimensions of matrices are defined by what you put in them. For you younger guys who never heard of APL, here's a fair precis of the idea of APL.
Visual Basic NET is much too low level and finicky for me these days. Visual Prolog is about where things ought to be imo.
Ah APL! That brings back memories. The language where, before you started, you had to put stickers on all your keyboard keys... A language terse to the point of complete incomprehensibility.
I think the following was written by Stan Kelly-Bootle:
There are three things a man must do
Before his time is done:
Write two lines of APL,
Then make the buggers run...
I guess my mind must be wired differently. I never had any trouble with APL from the moment I first laid hands on the keyboard. It was like something I'd always known how to do, but just never actually tried before. It was such a relief after FORTRAN 2 and "real" business languages like Cobol and RPG. :-s
"If all you have is a hammer, all problems look like nails." -- Unknown
This being said, APL, LISP, Forth, and several other languages have eluded me (and I have not had a strong enough reason to bang my head into them long enough for them to soak in.
My world of vi, assembler, C, PL/I, Fortran (but we shall not speak of the dark side languages of Cobol and RPG variants) have served me well.
I am glad to see that most people on this list have some variant languages in their past, so we will not get stuck to much in any religous battle over them!
We've had a few quasi-religious debates on computing languages with several of the various shibboleths thrown in but they haven't been too frequent, mercifully. :-)
Computer languages are nothing to do with human language, but there is this parallel: it doesn't matter if you speak French or Chinese, the Chomskyan deep structure is the same for everyone; it doesn't matter if you program in BCPL or Java, the Turing equivalence is the same for them all.
Um, actually recent work on language handling in the brain using CAT and PET scans is putting the lie to Chomsky's hypothesis. As well, I work in computational linguistics and find Chomsky's work about as useful as Lysenko's is in genetics. I actually get places if I stay with Sapir-Worf. Chomsky has been a decades-long alley. :-s
I don't have any problem with the idea that our individual languages constrain how we see the world. But that isn't mutually exclusive with the idea of a universal deep structure. Even the most die-hard Chomskyan would allow that language is a combination of deep and surface structure, and, of course, psychological and cognitive effects can emerge at any level.
Are we getting off topic here :)
***But that isn't mutually exclusive with the idea of a universal deep structure. ***
I agree. Unfortunately, it seemed like Chomsky and his acolytes had a pronounced tendency to start screaming anathema and grabbing pitchforks anytime someone expressed that point of view. :-s
Once somebody has the basic build going, it's actually *really* easy to add new reprap modules. If you use the build process, the hard part is all out of the way. Libraries exist to do the comms and potentially other stuff like eeprom state saving. To write a new module, it would normally just involve copying a couple of .c files from a template.
For example, the iobox module only took about 20 minutes to write. Extensions are easy to make too. Overall, much faster and easier development than Microchip's IDE (which I have used for years prior to this).
The only hurdle to overcome is the initial build, and then it's plain sailing. Just because that hasn't happened on cygwin yet doesn't doom the entire process.
Also remember, once we've ported it to cygwin, other people don't have to do anything special. It only needs to be done once.
We can't solve all the world's problems in an instant. Give it a little time...
So basically what you're saying is that it is impossible for now, at least, unless you're well into the arcanae of the Linux operating system to get into embedded programming for the reprap project without making a radical break from how things are done now and starting over from scratch with different technology.
Well no - the exact opposite. Simon's saying that we need to get the build working under cygwin, then stuff'll be as easy under Windows as it is under Linux. It's just that none of the rest of us use Windows, so that has taken a lower priority than getting the RepRap machine actually working.
I can't see any obvious better way of making RepRap platform-independant than the way we're going.
It's next to impossible without first learning some of the standard tools of the open source trade. So there's nothing stopping you, but I'm guessing it might be more work than it's worth for you just now. It you're willing to wait just a little bit, this will all sort itself out.
I think for an open source project, using an open source operating system is not totally insane.
I'm not going to debate about it.
Fair enough. By the way, great thread subject... Gave me a good laugh.
uh, subject title, that is :)
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.