No, but I have GFI outlets

I wasn't talking about an electrical drain. I was talking about where all the extra water goes when the system has a failure while in the fill mode and doesn't shut off. There are only two types of systems. Those that have failed, and those that will fail.

 

I wasn't talking about an electrical drain. I was talking about where all the extra water goes when the system has a failure while in the fill mode and doesn't shut off. There are only two types of systems. Those that have failed, and those that will fail.

I know, I was trying to be funny- a big enough leak would end up tripping the GFI circuit breakers in the house.

In this app, overflow to drain isn't really practical. But a water sensor would be. I've modified the design so that any overflow will drain into the bottom of my device before reaching the top of the container (basically a cutout so that the overflow is lower than the lid). At the bottom of the device I'm putting a water sensor. It won't take more than a teaspon of water, or even less, to trip this. The good thing with this is it would also capture any leaking from the valve. Since I'm going to use a PIC now I can make it pretty intelligent as well.

Thanks again.
Eric

 

I use 2n2007 and FDV301 and FDV303.

If you want to use a regular MOSFET you need an extra transistor to drive the gate.

Yes they are much better, much lower ON resistance.

If I need a regular MOSFET I often use P-channel, so I can pull down the gate with a small NPN. IRF9540 for instance.

In my circuit for instance I want to switch 12V, 2.2 Amps. I have relays here but only for 1 Amps.

I need to power a 1.3A / 16W solenoid. It looks like those devices are still a bit underpowered if I'm reading the specs correctly. After browsing around on DigiKey I ordered some RFP3055s (funny- it jumps from under-powered to over-powered, no inbetween). Does this sound about right?

 

So, it looks like I'm going to a PIC based design after all the device I got from you. I think I'll use the 8 pin PIC12F683.

This means I'll need to add a 3.3 v regulator and some caps to the circuit, but the power should be tiny even 100ma is probably more than I'll use. Thats not too bad.

I'm looking at the EasyPic v7 development board for the PIC. Adding the C compiler this is going to set me back around $400. Thanks for nothin! haha.

When I worked with PIC before, I just wrote assembly and prefer that actually. Do I really need to get a development system just to write/assemble assembly code and program it into one of these chips from my computer? Although the debugging offered by the easypic looks helpful.

thanks again.
Eric

 

Programming in assembler is possible, it's all I use. MPlab is free and contains assembler, simulator, etc. You can try it out before you buy any hardware if you like.
I still use MPLAB 8.63, but they may have made MPLAB X usable by now, I haven't tried it in a while.
Minimum programmer would be the PICKIT 2 or 3, which cost much less than $400. That, a solderless breadboard, a 100nF capacitor, a regulator, and a 6 pin header to plug the PICKIT into the solderless breadboard is all you need to have a working programmed chip.
I'd recommend the PIC12F675, the 683 has extra features, but you won't be needing them for this, so there's less datasheet to read.

 

Microchip gives away their C compilers... but sells the optimization parts.

So you get a cheap compiler but have to pay more per part for the extra memory it uses.

 

Microchip gives away their C compilers... but sells the optimization parts.

So you get a cheap compiler but have to pay more per part for the extra memory it uses.

And that's one of the nice things about C (but it may or may not apply to the Microchip compiler). The programmer can accomplish many of the optimizations by how they write their code.

If you write

C = C+1;
C += 1;
C++;

then all three do the same thing, but a non-optimizing compiler will generally not produce the same code.

C = C+1;

may be implemented the same way that

C = A + K;

would be implemented, i.e., a value from another memory location added to a constant.

C += 1;

may be implemented the same way that

C += K;

would be implemented, meaning that it may take advantage of the fact that the destination is the same as one of the operands, but not that the constant happens to be a 1.

C++;

can easily take advantage of the fact that this is simply an increment operation for which many processors have a dedicated instruction.

Now, there is nothing to prevent a compiler from implementing all three the same way (as C = A + K; ), but I suspect that very few compilers actually would.

I remember when Microchip didn't have a C compiler and you had to use third party tools. Then they bought a compiler and started selling it, despite having claimed that all of their software tools were free. They tweaked their stance saying that they would give away the tools they developed but charge for tools that they purchased until they had received enough revenue to pay for the purchase. Apparently they may still be following that model. I wonder if, some day, the optimization tools will be free.

 

Microchip gives away their C compilers... but sells the optimization parts.

So you get a cheap compiler but have to pay more per part for the extra memory it uses.

I'd go so far as to say the free versions go out of their way to "de-optimize" the code. I've seen nonsense in the output to simply waste memory or cycles or both. Not much, but a little garbage here and there.

gnu c/gcc is great, but doesn't support many chips, so the next best I've found is Sourceboost C, which is both very affordable and produces tight code.

 

As if it would be so totally easy to crank out a compiler.

It is not garbage. It exists for good reasons since the code generator is kind of generic.

The optimizer took a lot of effort to code. So they sell it.

What a difference does it make if your code takes 3K or 4K?

If you need to rely on optimization for a hobby or personal project then

A) your chip choice is wrong
B) your general coding approach is wrong

For sure C has a price it is not assembler.

You write, GNU is great but does not support so many chips.

Is it so easy to support many chips? Especially as for PICs it looks difficult, there are different banking schemes, and different instruction sets (for addressing). Some chips can read from the FLASH, while other's can't.

If I work a little on a C source to decode a BMP, remap it, and sent it out serially, I can increase speed 5x to 10 times. So this is about the coding approach.

Optimization in many cases does not do so much.

You talk about addition this is trivial.

On microcontrollers, you use a complex expression + 2 memory operands. This boils down into 30 words easily.

With optimization, you can maybe do it with 20 words.

Optimization does not mean, without it, 30 words are needed, and if you have it, only 5 words. Such a magic does not exist.

Work out your code and factor out as much as possible and don't compute complex expressions more than once.

 

The difference between

C = C + 1

and

C++

can be as much as 400%, i.e. a factor of x 4.

 

I'd go so far as to say the free versions go out of their way to "de-optimize" the code. I've seen nonsense in the output to simply waste memory or cycles or both. Not much, but a little garbage here and there.

gnu c/gcc is great, but doesn't support many chips, so the next best I've found is Sourceboost C, which is both very affordable and produces tight code.

I don't know that I would buy that they intentionally de-optimize the code. I think if it were established conclusively that they were doing that then they would anger a good portion of their customer base. Given the number of other options that are available, I don't think they would court that kind of a PR disaster.

My guess is that what you are seeing is reuse of compiler code from one instruction to another by doing as simple a hack as possible. As an off-the-wall example, imagine that you write the code generator to handle A+B where A and B are both values stored in registers. Now you right the code to handle A+K where K is a constant. Instead of writing the code generator to treat this as an immediate instruction, you could first store K in a register and then proceed as before. Now, of course any compiler writer that did something this outlandish deserves to get spanked, but it doesn't necessarily mean that they did it with the intent of making de-optimized code so that you end up using pricier parts or paying for their optimizing compiler.

 

The C compiler issue alone is why Atmel processors are gaining more popularity. PIC typically have more hardware features, but the free optimizing compiler causes many to use Arduino instead.

I understand that the mid line PICs were meant to be programmed in assembler for industrial use, though the fact that the datasheets all contain assembly examples makes them appear "harder to use".

They are both decent controllers, but bang for buck wise, PIC wins. If doing a large run, the optimizing compiler is an absolute must. The cost of the larger chips alone pays for the optimizing compiler in commercial applications. When an app gets very complex, the optimizing compilers will produce better code than most of the assembly programmers around, and in a shorter development cycle.

 

All the more reason why they wouldn't want their free compiler to churn out de-optimized code.

I've always felt that hardware vendors shouldn't try to make money on their software tools. I understand the business motivation for having the software development division "pay their way" or having easy ways to show that purchasing a third party tool to distribute to your customers generates enough revenue to justify the purchase. But I think these are short-sighted, bean-counter, MBA-driven viewpoints. It's really hard to quantify whether the X dollars spent to pay software tool developers is well spent when the payoff only comes in the form of increased chip sales since it is virtually impossible to know what fraction, if any, of that increase is due to the tools that were developed. It is entirely possible that the development is paying for itself even if the chip sales are declining if the sales would have declined even more if not for the new tools. But bean counters want simple and conclusive ways to quantify returns, so they insist that the tools "pay for themselves".

I once talked to some Xilinx folks (~20years ago) and at that time they were charging $7k for their basic tools. This was before the Webpack days, so if you wanted to target Xilinx FPGAs, you needed to shell out some bucks. I went to a training seminar they had and I asked the guy if Xilinx was in the market to sell chips are to sell software. His response was that his division was in the market of selling software. At least they have partially come around and make free development tools available for a significant fraction of their product line.

If I had been Microchip, when the option to purchase the third party compiler came up my decision would have been conceptually very simple -- will buying this compiler, assuming the resources to make the purchase are available, and making it available free to people targeting my chips increase my chip sales enough to pay for the purchase over time and represent the best return on investment of the money needed to make the purchase? If the answer is yes, then buy it and if the answer is no, then don't buy it. That's not to say that doing the analysis is easy, but the decision itself is.

The same for developing tools in house. If I am in the market of selling chips, then I should be giving away ALL the tools that will encourage people to buy my chips.

 

I wrote a LED matrix timer yesterday, using a PIC 16f1824.

It took me some hours in the afternoon, and then it worked.

/******************************************************************************/
/* Files to Include                                                           */
/******************************************************************************/

#include <htc.h>           /* Global Header File */
#include <stdint.h>        /* For uint8_t definition */
#include <stdbool.h>       /* For true/false definition */

#include "system.h"        /* System funct/params, like osc/peripheral config */
#include "user.h"          /* User funct/params, such as InitApp */

/******************************************************************************/
/* User Global Variable Declaration                                           */
/******************************************************************************/

/* i.e. uint8_t <variable_name>; */

#define c_PC_data LATCbits.LATC2
#define c_PC_clk LATCbits.LATC1

#define c_button1 LATCbits.LATC4;
#define c_button2 LATCbits.LATC5;

unsigned char v_line,v_pattern;

unsigned char v_secs;
unsigned char v_mins;
unsigned char v_hours;
unsigned char v_on_hr;
unsigned char v_on_min;
unsigned char v_duration_hr;
unsigned char v_duration_min;

unsigned char v_mode=0;

unsigned char v_key0=0;
unsigned char v_key1=0;

const unsigned char v_phase_bits[]={0b00011110,0b00011101,0b00011011,0b00010111,0b00001111};
const unsigned char v_phase_bits_2[]={0b00001111,0b00010111,0b00011011,0b00011101,0b00011110};

unsigned char key_tst(unsigned char k)
{
    if(k==0){if(!(v_led0&0x04))k++; return(k);}
    if(k==1){if(v_led0&0x04)k++; return(k);}
}

void do_reset()
{
 v_secs=0;
 v_mins=0;
 v_hours=0;
 v_on_hr=0;
 v_on_min=0;
 v_duration_hr=0;
 v_duration_min=0;
}

void send_data(unsigned char v_line,unsigned char v_pattern)
{unsigned char i;

 for(i=0;i<8;i++)
 {
  c_PC_data=v_line&0x01;
  c_PC_clk=1;
  c_PC_clk=0;
  v_line>>=1;
 }

 if(v_phase==2){v_pattern=0;}
 if(v_phase==3){v_pattern=0;}
 if(v_phase==4){v_pattern=v_mode;}

if((v_mode==0)||(v_mode==1))
{
 if(v_phase==0){v_pattern=v_hours;}
 if(v_phase==1){v_pattern=v_mins>>1;}
 if(v_phase==2){v_pattern=v_secs;}
}

if((v_mode==2)||(v_mode==3))
{
 if(v_phase==0){v_pattern=v_on_hr;}
 if(v_phase==1){v_pattern=v_on_min>>1;}
}

if((v_mode==3)||(v_mode==4))
{
 if(v_phase==0){v_pattern=v_duration_hr;}
 if(v_phase==1){v_pattern=v_duration_min>>1;}
}

for(i=0;i<5;i++)
 {
  c_PC_data=v_pattern&0x01;
  c_PC_clk=1;
  c_PC_clk=0;
  v_pattern>>=1;
 }

}

/******************************************************************************/
/* Main Program                                                               */
/******************************************************************************/

uint8_t main(void)
{
    /* Configure the oscillator for the device */
    ConfigureOscillator();

    /* Initialize I/O and Peripherals for application */
    InitApp();
    do_reset();

    LATCbits.LATC3=0;
    
    /* TODO <INSERT USER APPLICATION CODE HERE> */

    while(1)
    {
        if((v_led0&0x02)==0x02)
        {
            v_line=v_phase_bits[v_phase];
            send_data(v_line,0);
            v_led0&=0xfd;
            v_phase++;
            if(v_phase==5)v_phase=0;

            v_led0&=0xfb;
            if(PORTCbits.RC4)v_led0|=0x04;
            v_key0=key_tst(v_key0);
            v_led0&=0xfb;
            if(PORTCbits.RC5)v_led0|=0x04;
            v_key1=key_tst(v_key1);

            if(v_key0==2)
            {
             v_key0=0;
             v_mode++;if(v_mode==7)v_mode=0;
            }

            if(v_key1==2)
            {
             v_key1=0;
             if(v_mode==0)v_hours++;
             if(v_mode==1)v_mins++;
             if(v_mode==2)v_on_hr++;
             if(v_mode==3)v_on_min++;
             if(v_mode==4)v_duration_hr++;
             if(v_mode==5)v_duration_min++;
             if(v_mode==6)do_reset();
            }

        }
        // LATCbits.LATC3=1;
        if((v_led0&0x01)==0x01)
        {
            v_led0&=0xfe;
            v_secs++;
            if(v_secs==30){v_secs=0;v_mins++;}
            if(v_mins==60){v_mins=0;v_hours++;}
            if(v_hours==24){v_hours=0;}
        }
    }

}

It is using 15% of the FLASH program memory. I run it at 2 MHz.

It does the job. Maintain a 24 hours timebase, and be able to program on-time + duration.

It was programmed for a specific job and does the task 100% sufficient.

It is a small $1 chip with 4K FLASH. There is not any need to save space or to use tricks or to rely on optimization.

Using assembler...such a program may well require a few days and 500 to 800 lines.

The matrix display is a bit punk, as it only can display 2 EXP 5 on each line, so 32 is the max. value.

Solution was to display 2-minutes increments.

Most likely the display is never read at all, is only programmed once.

One thing I have learned by working with 8bit PICs: Don't implement functionality which is not needed.

I also bought a nice LCD timer from China. It arrived Friday.
8 buttons, large LCD, very good to use.

It runs from 230V AC. And it cares for weekdays and to select between different programs.

I also use this timer box for a different purpose.