Getting going (again) with PIC programming

[aidan.f]

I'm returning to embedded programing after a break since 2009... back then I could write in assembler but appear to have had a severe memory leak..
Got all the hardware together, and my legacy MPLABx IDE works. I'm just wondering whether to persist with ASM or find some different tools

The code should be simple - to turn off a solar charge controller at  sunrise and on power up as  the unit defaults to ON and 'other people' are not good at turning things OFF

The controller has active LOW  Daylight LED and Load ON LED  ON/OFF is a pushbutton
so I add on a PIC12F683 - stays mostly in sleep, wake on GPIO change then do some 'is it daylight for a while? and 'is the load on' checks' then if TRUE pulse the ON/OFF Switch..
And on Power up wait  a while, check load state and if ON pulse ON/OFF

How hard should that be?? 

[Kim]

Having got sidelined by various Arduinos and latterly ESPs, I've recycled most of my PIC neurons.  This isn't helped by no longer having a computer with a parallel port that would drive my programmer.  (Though I'm sure that you can get cheap USB things from China that can program pretty much anything these days.)

I probably ought to look into this at some point.  I've got a little drawer full of assorted small PICs, and they're ideal for those applications where you just want something that can sit in sleep, wait for some input then generate some precisely-timed pulses.

[aidan.f]

Kim, as you wrote PIC is so useful for simples.

I'm going  to persist with  ASM  - have all the hardware working (now) having spent sometime correcting bread-board wiring  errors (no magic smoke!')
Plug n'socket  is to swap between PICkit3 programmer and testing. Once I get code tested build with pre-flashed PIC, one SMT transistor four resistors and a decoupling  cap - will fit inside the case.

[Feanor]

Ahh, this brings back memories.

In my former work, I made a converter-box to read Other-Company instrument data on our data acquisition system.
It was PIC-based.

Most of the stuff was simple enough, the channels containing simple integer count-rates and the like.
But one of the channels contained a high precision frequency measurement.
This was slowly-encoded digital representation of 24-bit 'meter reading' which wrap around, and had to be subtracted from the previous number to get the number of cycles in the previous 100mS.
Our system used a different representation for this kind of data.
This was challenging: the PIC had no floating point capability, and it was real-time-critical: the last sample had to be processed before the next one came in.

In the end, I generated a massive Rainbow Table for all the possible inputs and the appropriate output. This was held in 3 ROM chips.
The decoded data was used as the address into this lookup table, and the result was readable within a couple of machine cycles.

I could guarantee the number of machine cycles required to perform this conversion. It was always the same.

[aidan.f]

That was complicated... wish I could work out why GPIO,1 will not change state in the simulator :-|...
Think it is a simulator bug..