Creators of Surreal Environs - est. 1999
Well, I was racing the clock, trying to finish this project up before I TOTALLY lost interest. I haven't lost interest, but it has certainly slowed down, as I scramble to get my taxes in order, and get my Vespa up to snuff. I'll be dead in the cold, cold ground before I let the first 75 degree spring day happen without my Vespa in running condition. So, look for a new project blog about that shortly.
UGH! I FINALLY got the stupid radial line drawing function to work (see video). I ran it on the arduino and it worked fine, so I was blaming the PIC C compiler for just not working. Turns out I was half right. I thought I'd included the math.h library, where all the sin, cos, tan functions are. I actually didn't have it included, but the compiler never gave me an error that it didn't recognize the functions when I was calling them! ARGH! In hindsight, I could have troubleshot this much more effectively by just plugging static values in where the angle calculation functions were. I would have seen immediately that it wasn't a problem with float or integer conversions or anything, and I would have narrowed it down to the trig functions in short order. Lesson learned.
No watch work done today, aside of course from the heavy lifting of picking up my new milling machine (product page). FedEx guy called while I was like 8 minutes from home but didn't want to wait, so I had to go meet him at 45th and Spruce and wait for him to finish some other deliveries. Then I had to ge the damn thing upstairs and now I have a splinter in my left index finger that I can't see but that hurts like a bastard.
The box for this thing was incredible. It looked like the kind of thing you'd carry an Ark of the Covenant in (file photo).
Spent most of today working on radial lines. That is to say, a function so I can say, draw the hands of an analog watch easily. The equations aren't that hard, but this chip goes bonkers when I try and do sin and cos functions. I do all the math on my macbook's calculator and get nice values, like 1.57, then I look at the stuff I'm getting from the chip, and it's like -67489. So, the C18 compiler is starting to show some seams. The sprintf() funtion also won't handle floats, which is a drag for debugging this particular thing. Hopefully the 24F will be better at this sorta thing, but it's hard to say. Tonight I'm going to try doing the same function on the arduino and see what values it comes up with.
Also talked with Tadge a lot about the challenges of the watch case and what chips we might use in the end. The 24f's are super powerful, but enormous (1cm square!) and only a few of them have USB. I still am adamant that the watch needs to be programmable with just a USB cable and nothing more. I don't want to have to produce breakout boards or require people to have pickits. We had a decent little rue about AVR vs PIC. I love the arduino dev environment, and how portable/easy to use it is (the PIC is going to require windows for programming, though we will have a firmware updater that runs cross-platform). Tadge's argument being that anybody who will actually know what they're doing would have windows, but I couldn't disagree more. In the end, there's lots of pros and cons to be weighed, not just with the capabilities of the chip, but also with the quality of its development environment, and ultimately its accessibility to the Make and Instructables crowd. Again, it's all in C, so it really wouldn't be too monumental to redesign this watch for a different CPU later on down the line.
Today I'm getting this actual journal up and running, because I know I'll spend the whole weekend messing around with Django instead of programming. So here we are. Very simple. I'll probably make it wiki-ish later, that seems like a pretty no-nonsense way to keep this thing editable. Not sure about source code, I might zip it up every day after I'm done and throw it on here. I should look into SVN or one of those things. Everybody seems to use it. Or maybe google code or something like that.
Supplemental: I got a good bit of work accomplished on the printing of strings. C, it turns out, hates
strings. So, I have found another use for pointers. Basically, since there's no real stdout or anything, what we've gotta do is
dump string info into a buffer array, and then we can pass a pointer to the buffer to a function that can iterate through
it and print each letter, advancing through the line. Also, I discovered what the sprintf() function in the C18 stdio.h library can
do for me, which does nice translations from int/float to strings, including prepended 0's and all that good stuff. So, the code for a
time display page is nigh. Here's an example screen. The time at the
bottom, for example, was built with this:
sprintf(Buffer, "Mon, Feb 22 %02d:%02d:%02d", hourTime, minTime, secTime);
printString(Buffer, 11);
...which is a whole lot cleaner than having a line for each character and if statements to prepend 0's and junk. But now, I have earned sleep. Adeiu.
Today I got the circle algorithm working (see video). It is pretty good, but it would be nice to get partial circles, and filled circles working too, which is apparently a bit more complicated, and I'm starting to wonder how much of a drawing API we really need initially. Started sketching out some possible screens for the watch, including sunrise/sunset and length of day seemed like a good idea. It's expensive as hell to calculate, but luckily it only has to happen once every day. I found a whole ton of javascript at NOAA that has all the functions I'd need. I started re-coding them into C, but quickly filled up the entire 16KB I have to work with on the current chip. It's not a huge deal, as the production model will have 256K. I have a few other pieces of source that might work better, but this astronomy stuff is important to me to include. Moonphases and sunrise and sunset are required. In the sketches, I had toyed with calculating Jupiter's moons' positions, but that's really pretty impractical information. But moonphase? We could corner the werewolf market.
But all that said, sunrise/sunset isn't easy to calculate. TONS of floats and trig and stuff to deal with. Thank god for the internet. So far there really hasn't been much I've had to re-invent. Working in C with the basic libraries is great. There's so much source that can be pretty easily adapted for the PIC. I still wonder if the AVR wouldn't be a better choice just because of Arduino. It would be way more inviting to a broader audience. I wish there was a gcc for the pic. Since we're writing in C, porting this over to an AVR chip shouldn't be a monumental task. I just wonder about the Arduino's power saving/sleep capabilities.
Also, did a lot of work with interrupts. Using the PORTB Int on change seems like a good way to go for the joystick etc. Still having some debouncing troubles with mode switching. Sometimes it'll skip two, and putting a delay in etc doesn't seem to help. I'll look into it more.
Also, big breakthrough on the mode-switching. Right now, each function has a while(1) loop to keep drawing the screen. This was initially so that I could declare local variables with starting values in each function, and then let the function run and modify them. The problem was that when you'd switch a mode with an interrupt, the program would never break out of that loop. But otherwise, you can't set default values for those functions and still have them loop. What is the answer to this, you may be wondering. I'm about to tell you. Instead of while(1), each function now has a while(!mode_change), which is a global variable that the interrupts throw to break the while loops. So now, each function can be wonderfully self-contained, with its own locally initialized variables and a standardized structure, but an interrupt will break it and let the watch switch to a different function. Hell yes. Science.
Did some more work today on the line algorithm, cleaned up my bread board, and got rid of a whole bunch of stupid large global variables. Doing so seems to have kept everything a lot more stable. It's too bad it doesn't give me real errors when I'm using too many globals. It just randomly starts acting weird. I broke all of the display functions out into a separate header file, so it's started to get a bit more organized. I keep trying to read about over-arching c design theory so I can get the file structure and function organization right. I'm stillo not really using pointers for much, and those are supposed to be really important, right? I think they're the right way to go for the mode-switching, keeping an array of all of my function modes.
There was a lot of development that happened here, but I didn't have this site up yet, so none of it is all that clearly documented. There are lots of photos of the whole project, with some of them dating back to the time in question. Someday, historians may be able to piece together the details of this early development period.
This is where I try and document the watch I'm working on with the help of my good friend Tadge. Here's some photos of the project: