Man, I am so proud to be in association with some people - eg, the 3 last repliers.
People that respect the skills of rats, and jump in & over(?) commit to a new unknown technology.
And I won't mention the arrogance of people who go from unawareness to a built circuit within weeks - it's taken me 10 (or 20??) years to go from "yeah, I should get into that" to construction - and that was merely soldering an SMD 08 onto a PCB before I figured out it was not the intended chip (a pre 08M version).
BTW - I'm assuming AutoWiz was jesting - surely it could not be worded so well if it wasn't? We did get off to a shaky start which was entirely my fault (I came in mid thread oblivious to the context AND confused OP with repliers, etc - another typical MY bad) but I suspect that's come good. Except for his need to show me up of course! (:wink: :;)
Let the rats rule!
of course I am OS. wouldn't be so bothered by your opinions if I didn't respect them and you. maybe not kidding about building a third autolamp module, or i might just cut one wire at a time and re solder to make more straight lines. feedback means a lot to me. it is how we all learn and grow. I have only built hardware at this point. I am now working on learning picaxe basic enough to make this thing work hopefully in the same fashion as my original. the way I wrote the sketch for what i'm running now, every time the loop cycles through if the light is above a certain level it will subtract 1 from this number, and if the light is below a certain level it will add 1 to this number. when this number hits 80 the parking lights come on, and at 100 the headlamps will turn on and subtract 1 from this number. when this number gets down to 20 it will turn the headlamps off and when it hits 0 it will turn the parking lights off and add 1 to this number. this sketch has worked beautifully and the lights are stable they don't turn off when I go into well lit parking lots or pass under street lamps, and to have a delay between parking lamps coming on and headlamps coming on I think is just cool.
A sketch? Why would you draw a program with a pencil? Ha ha - IMO funny jargon some of these newtechs. Not as bad as "pins" versus legs though...
But again, congrats. Your program sounds good. As usual, if it does the job... But what I like is the alternative methods (as one gets experience) and that if there was some design shortfall, it's a mere program mod & download instead of a circuit mod which can often be very complex.
IMO a good example of PIC or uPC etc versus circuitry is soft turn on or off lamps or LEDs in particular - ie ramp up & down. To do either with a 555 etc is pretty easy, but to have both... It sounds easy, but without latches etc that switch components else other novel circuitry, it's pretty tricky. But to program that stuff is easy - ONCE you've plunged into uPCs etc.
And I think you see the size (and price) advantage of the PICAXE 08M2 over an Arduino etc.
And to think I once designed an all electronic ignition system using a 68HC11 - that can now be done by an 08M2. (At least I think so - I haven't yet bothered - but the old limitation was program space and the M2 solves that issue. For larger (more legs) PICs I preferred to stick with uPCs etc since they could be expanded infinitely for added features.)
Anyhow, it's been a blast seeing your work and development. I think I needed a bit of a win or lift after some recent head jobs (as in bashing my head....).
And to think this comes from you - ie, I was so rude initially. Thanks!
But enuff of this love affair - I'll make people sick!
BTW - I too reckon lighting delays or effects can be cool, AND very functional. It was yesterday I first noticed an Audi that dimmed its white LED strips (DRLs) whist its adjacent amber LEDs flashed. I've been bothered by the vehicles that do NOT do this - surely the designers or authorities realise(d) how difficult it can be to resolve adjacent flashing LEDs? (Incandescents are merely a brightness/contrast issue.)
Anyhow, that stuff is so easy and cheap with an 08M2 etc.
wires are attached and ready for programming/testing. to keep wires to a minimum I am only using 4 wires. +5v out of carpc's m4-atx 250w dc-dc ps, the vehicle's chassis ground, and 2 outputs, 1 for markers, and 1 for headlamps. the transistors are sending chassis ground to the car's 12v relays for lights.
at this point OS, I can already see that not having a usb or other actual physical connector on this module is gonna be a hassle. i'm going to need to have this connected to laptop in car mounted where it will be at different times of day to figure out my calibrations. also I have 6 computers in my home. 3 power hungry gaming rigs I built for small scale lan parties with my friends, 2 laptops, and carpc. and not a single serial or parallel port between them. easily rectified as I found a usb adapter to program with. but this must go down as a mark against the picaxe chip because down the road, if I want to recalibrate when the lights turn on or off, or if I wanted to add a dimming feature to the markers, it is going to be a process. whereas with the arduino board it's a usb cable and whatever few seconds it takes for the arduino program to load up on carpc. then with serial monitor I can actually see what numbers the ldr is reporting back to arduino so I know what changes to make to my sketch. and the whole process can take place inside of single digit minutes. and gives me the feel that it is integrated with carpc.
The lack of usb is an advantage for some - merely one pin plus GND to program; no "big" micro-usb connector etc. Plus the cheaper PIC price.
LED reading can be read via serial (serout) or i2c if not the memory locations themselves. But usually such stuff is not required - it's a calibration based on environment & set-point rather than "internal" readings.
As I recall, variable should be as readable on a PIC as a uPC. The main difference was that the PIC can be part or fully read protected. And of course there is no address & data bus reverse engineering.