New to mikroE C

Thread Starter

R!f@@

Joined Apr 2, 2009
9,918
Never done flow chart before cause I go with the flow in my mind and get stuck.

The last box is my issue

Run mode and over current mode. that's a good idea. What do you have in mind ?

The last feature was indeed meant to be a protection feature. I wanted the supply to switch output off and stay that way if the supply is overloaded. I wanted it to reset when the user reduce the Voltage.

Right now it is labelled as overload.
In over load it checks for Max current value. It detects ADC and shuts off relay. Relay turns on when the voltage ADC is reduced to 0.

I wanted to add;
1. Power switch feature. That would keep the output relay off display Standby. There would be a Standby relay too. The display will be powered separately and not from the main Tx. So one Switch input and one more relay out. I still have 2 ports unused.

I like need to cycle through this Standby loop for ever until Stby is pressed. Once pressed the main code should begin. that is display start up msg point from the flow chart. If pressed again to power down, the msg should appear shutting down and go back to stby loop.

2. Is to display msg when overloaded and stay there until voltage is brought down. I like to display the msg as long as the voltage is not brought down and switch back to normal display mode when the output relay is re triggered by 0V setting.


The power switch feature I haven't tried coding yet but I tried few ways to do the overload display msg. Partial luck

void OverLoad(){
if(Amps>=1023){ // If Current reaches MAX 10Amps,
Rly = 0; // Output off
/*Alarm_high();
Lcd_Cmd(_LCD_CLEAR);
Delay_ms(500);
Lcd_Out(1,1,txt9a); //overload ms
Lcd_Out(2,1,txt9b); // reset msg
Delay_ms(500);
Alarm_high();
Lcd_Cmd(_LCD_CLEAR);
*/

}
if(Volts<=1) { // If Volts out is 0V,
Delay_ms(100); // Wait for 100ms before -
Rly = 1; // Switch back on Relay
}
}
This code is now what works.

The commented out code works if I replace the "if" with "while" at the beginning. but one problem.
It changes display to overload msg, and sound the alarm and stays there, it does not come out of it even the voltage is reduced. I cannot figure out a way to come out of it. The darn thing get's stuck in tht loop once overload is activated. :confused:

PS. I am not using ISR yet
 
Last edited:

Thread Starter

R!f@@

Joined Apr 2, 2009
9,918
It seems to be a protection process. I would think of it in terms of "modes", ie "run mode" and "overcurrent mode".

There are different ways to handle that but one easy way would be to use a variable for mode, then after measuring voltage and current you branch to do two different things (depending which mode it is in).

So if run mode you measure voltage and current and put (or leave) the relay on.

If in overcurrent mode you measure voltage and current, and make sure it meets your safety requirements before you can turn the relay back on.
Darn. I am slow. :(
I think I get you. :D
time for another version of the code.

I will do ur way but your input is highly appreciated on the above post.

Thanks RB.
 

Thread Starter

R!f@@

Joined Apr 2, 2009
9,918
I am still banging my head thinking how I go about what u said RB.

by branching, I am thinking that you are saying to use "if" statement.

Need a nudge here please.
 

THE_RB

Joined Feb 11, 2008
5,438
Basically you have two operating "modes";
RUN MODE; test adc, display it, if current>x go to SHUTDOWN MODE
SHUTDOWN MODE; test adc, display it, if voltage==0 safe to go back to RUN MODE

There are two ways to handle the two mode; series or parallel.

It is probably easier to understandthe serial way;

Rich (BB code):
while(1)  // main loop, never exits
{
  // RUN loop
  while(1)
  {
    read adc
    format to volts etc
    display adc

    relay=ON
    if current>x break;   // will exit this loop, and go SHUTDOWN loop
  }
  // SHUTDOWN loop
  while(1)
  {
    read adc
    format to volts etc
    display adc

    relay=OFF
    if voltage==0 break;   // will exit this loop, and go back to RUN loop
  }
}
That should be easy enough to understand, its either stuck in RUN loop handling RUN tasks, or breaks out and gets stuck in SHUTDOWN loop handling those tasks.

As you can see the bulk of the code is repeated, and is the same in both loops.

So you could change to handling the modes in parallel;
Rich (BB code):
while(1)  // main loop, never exits
{
  // common tasks
  read adc
  format to volts etc
  display adc
  delay after displaying, if needed

  // now handle one mode or the other;
  if(mode==RUN)
  {
    relay=ON
    if current>x mode=SHUTDOWN    // test and change mode if needed
  }
  if(mode==SHUTDOWN)
  {
    relay=OFF
    if voltage==0 mode=RUN    // test and change mode if needed
  }
}
This is more code efficient as you are not repeating the common tasks. But the first way can give you more power over what each mode is doing.

You will need to consider real-world timing, things like displaying the ADC value every 0.5 sec or 1 sec, and how that affects your testing. Personally I would test often (every 10mS?) and handle the mode testing more often (for safety). Then I would average the readings together, and display the average every second (for better data resolution, AND better visual timing).

Other people might suggest different ways of going about it but anyway I think that covers the two most obvious solutions. :)
 

Thread Starter

R!f@@

Joined Apr 2, 2009
9,918
I must say this is getting interesting.
Series and parallel ?
Need to study this.

I will get back after doing some more head banging.

But I admit that "Break" statement or thingy was what I was looking for
 

THE_RB

Joined Feb 11, 2008
5,438
I must say this is getting interesting.
Series and parallel ?
Need to study this.
...
They are not official terms. :)

I was talking in loose terms of flowcharting, like we were discussing. And the shape of what the program flow might look like in a flowchart.

If the flow occurs down the flowchart very vertically I would call it more "serial" but if there are more horizontal blocks (ie do the left block OR do the right block) I would call it more "parallel";

Rich (BB code):
(Example 1)

Run mode block here for a while

Shutdown mode block here for a while

go back to top
Rich (BB code):
(Example 2)

Common stuff here

Decision (branch left or right);
left bock        right block
Run stuff        Shutdown stuff

go back to top
That would be easier to see if it was drawn as a proper flowchart with neat boxes but the rough text flow version above should give you an idea.
:)
 

Thread Starter

R!f@@

Joined Apr 2, 2009
9,918
I made it after a few hours.

Now I can display overload when max current is reached and loop in it until Voltage is set to 0V and then exit to main loop.

This was a steep learning curve.

Good part is I figured how to switch on relay back on sound buzzer too.

Thanks RB. I couldn't have gone this far without your advice.
Thank you to rest of you too.

I ran into a funny issue though.
When I added msg to display them when overload occurred, the LCD is missing characters at start up.
And after start up I got jumbled characters running around the LCD.

So I committed the start up display scrolling on the second ROW. The first ROW startup still scrolls.

So far now V2.0 has the same as V1.0 with added overload display and function.

I still have 47.2% free DATA & 35.9% free ROM Usage.

I went for V3.0 and since I got one analog port I thought of using it. So I added the heatsink temperature sense and PSU shutdown completely until the sink cools down. I have two relay controls. On for output and one for standby.

My problem is that when I add any more msg, the LCD is again creating weird characters and they are running around.

My question is why ?

I have plenty of ROM and DATA space for that. NO?

By the way. The version 2.0 is running on 20MHz HS.

Any idea why the added msgs are creating havoc in the LCD ?
 

THE_RB

Joined Feb 11, 2008
5,438
If you are using the LCD plugged directly into the EasyPIC7 development board there should not be a hardware issue.

It's possible the other circuitry attached might be making a big noise spike, upsetting things?

In my experience when the EasyPIC LCD shows garbage it's almost always a code fault (ie my fault!).

Can you show your code for the display data conversion (from ADC to volts etc) and the code for formatting and display?

If there is something wrong with your formatting it can cause LCD garbage. The most common error is losing or misplacing the NULL (zero) character at the end of the text string, which is required to end the write to the LCD.
 

Thread Starter

R!f@@

Joined Apr 2, 2009
9,918
My code works fine so far.
That is read two ADC's, convert to voltage, current & display. Even the overload is working perfectly.

At start up the first row msg scroll to place and then the second after clearing then comes the specs and software info.
After that it clears the LCD and is ready for volt amp part.

All good.

The garbage part happens when I add any more other msg like for example using the extra ADC to read the temperature and display say "over heat"

I though the msg is messing with the othr msg's stored in the ROM.

I can show you the code if you want but I rather PM u that at the moment.(this goes for other members here that are in my friends list too).

I see that my request to be ur friend is still pending.
I don't want it to be in public domain yet
 

THE_RB

Joined Feb 11, 2008
5,438
My code works fine so far.
That is read two ADC's, convert to voltage, current & display. Even the overload is working perfectly.
...
The garbage part happens when I add any more other msg like for example using the extra ADC to read the temperature and display say "over heat"

I though the msg is messing with the othr msg's stored in the ROM.
...
Interesting! MikroC stores LCD massage strings in RAM by default, not ROM. So it could be that some of your other code is trashing the RAM contents where the message is stored.

Common causes of trashing RAM are arrays and pointers. If you have code that is writing to an array or list and it indexes wrong (pointer error) it will write to somewhere else in RAM and can trash other RAM contents (like the LCD display text).


I can show you the code if you want but I rather PM u that at the moment.(this goes for other members here that are in my friends list too).

I see that my request to be ur friend is still pending.
I don't want it to be in public domain yet
I don't have the desire or time to go through your entire code. :)

Also I don't like getting PMs and don't accept friend requests. Nothing personal, and I do consider you a forum friend :), but I just like to keep all my forum interaction public and in the threads. It's too much work keeping track of private and public conversations, and I prefer to be a public-only guy. Please don't be offended, it's just the way I roll. :)

I understand that this a secret project at this point, that's all good but it does make it a little harder to debug.

It's perfectly normal for bugs and problems to crop up as a project grows. Do you use the debugger? If not you can still track things down by commenting out (disabling) various chunks of code and seeing the result. You can soon track down if A is causing problems with B.
:)
 

Thread Starter

R!f@@

Joined Apr 2, 2009
9,918
I believe I have pointers.

Question is why the added extra Msg's are causing it.
Could it be I am running out of RAM for this project.
 

THE_RB

Joined Feb 11, 2008
5,438
Unlikely, the compiler will give you a warning/error if there is not enough RAM. It handles all the RAM allocation quite carefully.

That stats box icon at the top of the screen (little bargraph icon) will tell you about the RAM usage, and one of its windows will show the RAM locations for each of your variables and arrays.

It's good to get to know those things. :) For instance if you see your 10 byte array goes from 0x20 to 0x29, and the variable at the very next location (0x2A) is the one that keeps getting trashed, it's a good bet you are writing past the end of the array and trashing the next RAM location.

It's not a replacement for a debugger but I still think it's a good idea to get familiar with where the compiler allocates things in RAM, and where it places functions in ROM etc. The better you know your compiler the more effective you can be when something comes to the crunch (like needing to fit more stuff in a PIC which is already "full").
 
Top