Learning C

[augustinetez]

Just going back to your previous comment about not being able to use it in polling mode.

I'm trying to learn C by converting an existing project written in asm - the existing project polls the encoder and some switches constantly until something happens and then goes of and processes that. It then returns to polling the encoder.

There is an interrupt process in my original program that saves any changed data after a time delay (setable between 1 & 255 seconds at compile time).

So I would like to keep any C functions in their seperate little boxes corresponding to how the asm file is laid out to make it easier for me to get my brain around how indiviual bits work - if that makes sense.

 

[KeepItSimpleStupid]

I'm trying to learn C by converting an existing project written in asm - the existing project polls the encoder and some switches constantly until something happens and then goes of and processes that. It then returns to polling the encoder.

The appropriate thing to do is likely leave the encoder routine as is and use C around it with inline assembly code.
There is nothing wrong with doing that.

 

[Pommie]

So I would like to keep any C functions in their seperate little boxes corresponding to how the asm file is laid out to make it easier for me to get my brain around how indiviual bits work - if that makes sense.

That makes sense. It could be polled but would need to be very quick and would miss counts while doing the processing. An alternative would be to leave the ISR running to keep count and then have a routine that polls the value from the interrupt. Other interrupts can be added for timing etc.

One thing with using C, is that routines that are many pages long become 1 line of C. For example, the check for out of bounds would become,

    if(count>UPPER_LIMIT)
        count=UPPER_LIMIT;

So, it doesn't really make sense to make this a separate function but could be.

Mike.

 

[augustinetez]

OK, let me break this down, my current asm file does:-

Inialisation

Defines of various things related to the DDS module and EEprom data

Setup Ports, various registers and read EEprom data and apply to respective registers, initialise DDS module and external LED indicator if fitted

Main

Put PIC to sleep (just realised I've left this out of the latest asm version - it should be there)

    Enter encoder routine when encoder moves or switch pushed via wake on interrupt

            If seperate  interrupt timer has timed out - save current data to EEprom (frequency, step size and which LED currently on)

    Poll encoder and switch

        Adjust a register if switch pushed

            Increment/decrement LED's on an external circuit <- this takes around 12.4mS longest and 10.2mS shortest duration

    Returns to main when encoder moved

Start timed interrupt routine - used to save data to EEProm if data has changed after a delay of 1-255 seconds (set at compile time)

Adjusts size of frequency inc/dec (corresponds with switch push above)

Calculate DDS tuning word - inc/dec freq depending on which  way the encoder moved

Checks tuning word is within limits other wise sets hi/lo limit

Send the DDS tuning word to the DDS module

Puts the PIC to sleep and waits for encoder movement or button push

!!! There is an independent calibration routine that is only entered using a specific button sequence and only at power up that uses the encoder in a continuous polling mode !!!

As for the encoder missing steps when the code is off doing something else - not important - what is, is that the other code gets executed in full and not be interrupted by - an interrupt - the timed interrupt in the above only sets a flag, it does not run any other code and is disabled during certain parts of the code.

The appropriate thing to do is likely leave the encoder routine as is and use C around it with inline assembly code.
There is nothing wrong with doing that.

While I realise this is a legitimate way of doing things, it is not useful for this exercise of me trying for the 10,000 and oneth time to learn C - which as you can see, is not going well

 

[augustinetez]

In fact, that's it, I'm pulling the pin on this.

I will stay with ASM.

 

[Pommie]

I will stay with ASM.

Your loss. What you described above can be easily done with C and with a lot less typing.

Why would code being interrupted cause a problem? It's running at 32MHz so the interrupt will be over in a microsecond and not change anything except not missing clicks. I don't understand where the problem is?

Mike.

 

[augustinetez]

On the contrary, there is no loss, I did learn some things.

The most important of which is, no matter how hard I try, I will never be able to get my head around the twist and turns of the C language.

Thanks for all you help Mike.

 

[augustinetez]

Forgot to answer your question re interrupts causing a problem - some of the code makes writes to EEprom - as per the datasheet for most PIC devices, interrupts must be turned off during this process.

 

[Pommie]

Forgot to answer your question re interrupts causing a problem - some of the code makes writes to EEprom - as per the datasheet for most PIC devices, interrupts must be turned off during this process.

Two ways around that, turn them off or do the write in the interrupt. They (interrupts) only have to be off for half a dozen instructions. Writing to EEPROM on interrupt is very efficient as you don't have to wait for the write to complete.

Mike.