MikroC for PIC using Proteus (zuisti's solutions)

[zuisti]

( More LCD do you want to use? Or more Sw Uart? )


I work more recently in C, using the MikroC Pro for PIC v6. I've created my own libraries (so far only for the PIC16(12) family, but these are continually being improved). The completed and tested very first versions (in binary form but with working examples, projects and documentations too) I uploaded in the compiler's own forum because I thought this was the right place. Unfortunately I was disappointed there was no sense of the thing: only a few negative feedback came, which asked for the library sources. However, this I have no intention, especially in the development phase, and a such open forum.

I am convinced that a lot of beginners and advanced users can use these solutions so, that receive these new libraries in binary form.

My new libraries contain extremely simplified (much smaller code footprint) interface for
-- max two  LCD (4bit mode, 6 pins)
-- max two  LCD (using a HC595, 3 pins)
-- max four  Sw-Uart (1, 2 or 3 pins, CTS handshake)
Also some routines as Hex2out, Dec3out, CstrOut.
A separated library for using them via function_pointer.

-- PC keyboard in Proteus(!!):
To try/debug (before the construction, in Proteus) such PIC programs that use the excellent and easy to use MikroC Ps2_Library, a separated library was created. It uses the Proteus Virtual Terminal as input device to simulate the PC keyboard inputs (keystrokes).
-- all new libraries come with a working example project (also in Proteus, see the picture)
-- a workaround to debug the PIC12F683 in Proteus, using COFF (it does not work now, try it!)


If you have interest, please indicate here (for example,  with a 'thankyou') and I am going to upload them one after the other, as my schedule permits. Or, if the moderators do not complain, and do not overload the server, I can give you the links of the already uploaded things.

Regards
zuisti (Istvan K.)

[zuisti]

--------------
As promised, here is the first: the Multi Sw-Uart library is presented.

It contains interface for max. four software (bit-banging) uart,

- can be write-only (1wire)
- read function with or without timeout (hw handshake via CTS)
- no need any break() via interrupt + timer
- no any error handling (yet)
- it's small: the simplest read-write loop program (like in the help) is only 67 bytes long
- direct output routines, without any additional buffer (hex2out, dec2out, dec3out, ...)

I wrote a simple program to demonstrate the facilities of the library.
Attached the MikroC project and a well working Proteus simulation.

Note:
In my new libraries for PIC12-16 (like this) I'm not using the pin-direction declarations  because they can be calculated from the pin-declarations (only the bank must be changed).
For example:

Code:

   sbit Stx0_pin  at PORTA.B0; 
   //sbit Stx0_pin_direction  at TRISA.B0; //omitted, it is calculated  

So you need to write less  

Unfortunately this is not possible in case of PIC16enh and PIC18 families  
(respectively, can be solved using indirect addressing, but not worth, too large code).
  
Regards.

UPDATED (but this 'old' also works):
http://www.sonsivri.to/forum/index.php?topic=52263.msg161544#msg161544

[zuisti]

Very interested in PC keyboard in Proteus.

Hi George;
Thanks but please be patient, it's not yet ready for publication, a small description and some example have to be created.
To avoid any misunderstanding: this is not a new Proteus device but a simulation library that can be used on each PIC16(12) program (without changing it), which is based on the original MikroC PS2_Library. Instead simply my library must be used when compiling the project.

HW usage (in Proteus):

-   add a Virtual Terminal (VT) to your DSN (with its default 9600 Bd, or ..)
-   connect your KBDAT     (Ps2_Data)  pin to the Tx pin of the VT
-   connect your KBCLOCK  (Ps2_Clock) pin to its Rx and CTS pin as in my example projects (see picture).

That's all!
 

Currently the Multi-LCD library is prepared for upload.
zuisti

[zuisti]

Now my Multi LCD library is presented (rev 0.2  ).

   Simplified (small code) interface for
   - up to two 4bit (6 pins)  LCD,
   - up to two 3wire LCD (using one HC595 shiftreg).

For any PIC16(12) but NOT for enhanced types !!

---------
   Library functions (X: 1 or 2; w3 means 3wire)
  
      LcdX_PinInit()
  w3LcdX_Pins_Init()

(w3)LcdX_Init()

(w3)LcdX_WriteChar(char)
(w3)LcdX_Command(char)
(w3)LcdX_Clear()
(w3)LcdX_Dec2out(char)
(w3)LcdX_Dec3out(char)
(w3)LcdX_Hex2out(char)

(w3)LcdX_RstrOut(char*)
(w3)LcdX_CstrOut(const char*)

(w3)LcdX_GotoYX(char row, char column)     //row: 0-1(nonzero), col: 0-39
           for any LCD but only in the top two rows !!!

(w3)LcdX_Goto4yx16(char row, char column) //row: 0-3, col: 0-15 (for 16x4 !!!)
(w3)LcdX_Goto4yx20(char row, char column) //row: 0-3, col: 0-19 (for 20x4 !!!)
          (A 16x4 LCD to be addressed differently than the 20x4  !!!)


Detailed description in the example C source!

Notes:
- The library can easily expanded to handle more LCD, but I did not see the point.
- I prepared a 2wire LCD version too, but not built into the library, as it is only very rarely, and additional HW elements are needed (a resistor and a diode).

Attached (as usual) the MikroC demo project and DSN. Tried with 4, 8 and 16 MHz PIC clock.
Regards
zuisti

UPDATED (but this 'old' also works):
http://www.sonsivri.to/forum/index.php?topic=52263.msg161461#msg161461

[zuisti]

The PIC12F683 is one of the most useful 8pin PIC. Available almost everywhere, cheap, 2K Flash, 256 bytes EEPROM, 128 bytes SRAM ...

Unfortunately the COF file (generated by MikroC) is  defective, so the source level debugging does not possible, the  Proteus indicates an error (see the first picture). Of course the simulation is working with the HEX file, when the program is good. However, Proton COF file works fine (see attachment), so Proteus not to blame.

Well, I found a temporary solution to the problem, so we can debug the 12f683 on source level, using the "new" COF file.

    My solution is as follows:

Since we can see that the compiler generates a good (in Proteus usable) COF file using any 16F..., and there is no 16f683 (:-), I made one, so the compiler is "tricked" and generates a well working COF file.

Actually I cloned: simply used the P12F683.c and P12F683.mlk files ( in the "defs" folder), copied them to the same place, but named as P16F683.c and P16F683.mlk. Then inside these UNIX-style text files modified (using a HEX editor) the names from 12f to 16f. The newly created files are included in the RAR so simply copy them to your "defs" folder.

That's it!


Of course, the project settings must be repeated, now using this "new" PIC. Do not forget to set the fuses too (same as before).

If we compare the two COF file (RAR attachment is included both), we can see that the header of the 12f683 COF file is almost empty. I think it's wrong, but that is a matter for developers ...

I tried the above solution with several major 12f683 projects in Proteus, and it works perfectly. Of course, not at all sure that the thing works in the real world, but it is possible because the generated HEX file is the same as it was for the real 12f683 (compared !).

Do not have time for this, but it might be worth checking out the rest 12f... as well (as long as you do not have a final, official patch).

Regards
zuisti

[zuisti]

First a note:
  Seems, my previous post (12f683 COF solution) was not helpful to anyone ... never thought  

----------------

If we have more than two output terminals (like in my example) then seems here are a lot of almost
same routine, which can be solved by function pointers, to write a smaller and more elegant C code.

To do this I made the "LIb16_OutUniv.mcl" library file:
    Common output routines using a function pointer to a 'char-out' function
    So far only for the PIC16(12) family
    The pointers may be placed conveniently into an array, as in the example.    


New library functions:
     (and examples, here only with regular MikroC 'char-out' functions,  using only one char parameter)


void CstrOut_Univ(void(*ChOut)(char),const char*);

     example: CstrOut_Univ(Lcd_Chr_CP, "String in the Code memory");
                  CstrOut_Univ(Lcd_Chr_CP, cptr);

void RstrOut_Univ(void(*ChOut)(char),char*);

     example: RstrOut_Univ(UART1_Write, "String in the RAM");

void Hex2out_Univ(void(*ChOut)(char),char);

     example: Hex2out_Univ(UART1_Write, 254);     // writes out: FE (two hex digits)

void Dec2out_Univ(void(*ChOut)(char),char);

     example: Dec2out_Univ(I2C1_Write, 23);        // send '2' then send '3' (0x32 then 0x33)

void Dec3out_Univ(void(*ChOut)(char),char);       // "ddd" (3 decimal digits, max 255)

     example: Dec3out_Univ(Lcd_Chr_CP, 99);       // result: "099"

----------

Prepared (and attached) a slightly more complex example project, using 4 Sw-Uart and 3 LCD at a time.
Its picture is in my first post (in this thread), go here:
http://www.sonsivri.to/forum/index.php?topic=52263.msg150513#msg150513

The project uses (and contains) the previous libraries too;
  the MultiLCD,
  a newer (but absolutely compatible) version of the MultiSwUart,
  and a new 'consolidated' description about them.

Please write your experiences here if you tried these things.

zuisti
PS: now (later  ) already really the PC Keyboard Simulator will be the following ...

UPDATED (but this 'old' also works):
http://www.sonsivri.to/forum/index.php?topic=52263.msg160917#msg160917

[zuisti]

Your post might be useful Zuisti to some that uses PIC12F683. I guess more people are now choosing the newer, cheaper and FASTER 12F1822

Yes, and also the 12F1840...

Hi Parmin;
As I wrote above, all my new libraries are working only with  PIC12-PIC16 types (so far, and I'm working on the others like the PIC12/16enh and the PIC18 family). And the 12F683 is more compatible to the well-known 16F types, especially for those who intensive use the inline asm too (like me :-), or at least the FSRPTR - INDF ram accessing mode, which is possible and very useful in MikroC.
-----

"To do this I made the "LIb16_OutUniv.mcl" library file" It is difficult to see functions name to be called from .mcl files.

Hi zab;
I do not really understand why this is difficult. Just as the previous ones, this library also bundled with a description, a working sample code, and even in post # 6 also indicates the callable functions, along with samples.

For example the two-byte HEX output (without any temporaly buffer):
  to the USART
  Hex2out_Univ(UART1_Write, 254);     // send 'FE' (two hex digits)
  to the LCD
  Hex2out_Univ(Lcd_Chr_CP,  254);     // writes 'FE' from the current cursor position
    or, using my 3wire LCD function:
  Hex2out_Univ(w3Lcd1_WriteChar, 254);
and so on, it is working with any 'char-out' function using only one char parameter. It is therefore universal.

if possible can you share these lib file with out compilation in form of .c or .h instead of .mcl so that one can see the codes and adopt them according to specific controller and needs. it would be more helpful to the learners.

Yes, I understand, but as I wrote (in my post # 0 here), that currently I do not intended to publish the sources of this libraries. Sorry ...

Regards
zuisti

[zuisti]

As I wrote above (see post #3) this is not a new Proteus device but a simulation library that can be used
in each PIC12-PIC16 program (without any change !!), which is based on the original MikroC PS2_Library.
Instead, simply the new library must be used, while the original will be omitted, and recompile the project.

It uses the Proteus Virtual Terminal as input device to simulate the PC keyboard inputs (keystrokes).

Big advantage of the MikroC solution (and mine too) is that not interrupt driven, so any two I/O pins can
be used, in fact, the PS2_Data can even an input-only pin (eg GP3 of the 12F683).


 The solution is totally transparent and equal to the original PS2_Library:

   same (only a bit smaller) code-footprint,
   same RAM usage (a bit less too),
   same pin definitions,
   same global variables,
   same functions with same parameters,
   same results (return values);

   so no need to change your software.

   Some minor exceptions, eg not all keys (like WINDOWS) due to the limitations of the Proteus VT.
   Details in the documentation, HW usage also above in post #3:
   http://www.sonsivri.to/forum/index.php?topic=52263.msg150550#msg150550


 I created also two sample projects:

 The first is the simplest Ps2 program from the MikroC PS2 help (its screenshot is also above, in post #3).

 Second, a much more complete project (see the below picture) is a 'real' one-line LCD editor:

   Insert - overwrite mode with different cursor shapes;
   full cursor movement (LEFT-RIGHT via arrow keys, also HOME and END);
   BACKSPACE and DELETE.

All previous sample program is only intended to show how to use the new libraries (like the small programs
in the MikroC help file). However the last, the PS2 Editor's source includes useful details too, I hope.
For those who do not want to use my new LCD library, the program uses just 'official' MikroC LCD functions.


In this way it is possible to use the Proteus source-level debugging too, when a PC (PS/2) keyboard is used.

-----

Please look at also my prev. posts in this thread and write your experiences here if you tried these things.

Thanks,
zuisti

UPDATED (but this 'old' also works):
http://www.sonsivri.to/forum/index.php?topic=52263.msg158269#msg158269

[zuisti]

This year I gave to my students three programming tasks as the condition of 'graduation'.

They are free to choose from:

-    a 8pin PIC port-expander (24 in and 24 out bits) with an LCD and a remote serial display (see the picture).

-    an RS232 controlled MMD circuit using a 8pin(!) PIC12F683, pixel scroll to left, to right.

-    a PS2 keyboard controlled MMD circuit using a PIC16F628A.

Students may use only the free (2k) mikroC PRO v6, it is also enough. They were provided with all three Proteus projects (hex only), to specify the conditions (the expected properties). Gave and can be used my own libraries (such as the PS2 keyboard Simulator, the multi LCD or the multi SwUart, can be found above in this thread, in binary form).

My basic level PIC programming course is approaching completion, therefore if interested, I can upload the well working Proteus projects (only with HEX firmware, have to understood ), to try writing the program from scratch. Later I'll upload my own complete versions (not the solutions written by my students, since it is their intellectual property).

To inspire here's a screenshot of the first project what can be uploaded even tomorrow if interested. The rest still need to prepare for post, sorry, I'm working on it but only later.

Regards
zuisti

[zuisti]

Here's the first task's well working hex-only Proteus project (attached in rar). See my previous post.

Meantime found the pictures of the other two tasks (also attached). Still looking for their DSN and hex files ...
An additional info for the MMD circuits: the scroll speed and direction is also stored in the Pic's Eeprom (used at next power-on).

Greets
zuisti

[zuisti]

Here are all three tasks (well working hex-only Proteus projects), attached in rar. See my previous posts in this thread.

The first two task's main problem is of too few (five I/O and one input-only)  PIC pins, but that is why they are also nice jobs.
The easiest task is the third, the PS/2 controlled MMD,"only" should be resolved the timings and to fit into this 2k PIC.

Some additional infos for the MMD circuits:

- the message lenght is min. 70 chars
- 'on the fly' settable the pixel by pixel scroll speed and direction; start-stop control
- the speed and direction is also stored in the Eeprom (used at the next power-on)
- the display refresh rate is min. 70 Hz (8pin, 8MHZ), min. 140 Hz (PS/2, 16 Mhz)

Note:
Also I know it's much easier to use the known custom VLSI circuits (for example the Microchip MCP23017 port-expander IC or the excellent Holtek HT1632C LED display controller/driver chip), and also complete solutions can be found on the net. However, this was not the goal but to learn the program writing from scratch. Therefore students have to write programs only for one of the three given DSN.

Thanks
zuisti (Istvan K.)

[zuisti]

Here is the (my) solution of the first task, the 8pinPortExp, see above. The two MMD programs (for some reasons, at request) remain unpublished yet. The full Proteus-only project is attached, the MikroC source too. Note this is just one of the possible solution, try to write your own program for the given DSN if you want.

The program uses the own libraries and (to avoid the 12f683 cof problem) my workaround too. See my previous posts here. The source is not as simple, a bit tricky, try to understand it. Since the Proteus project uses COF (not the hex file), you can debug it also at source level. To build apply pullups for any input switches and use the original MikroC PS2 Library (instead of my KbSim).    
But - sorry - no any 'support', I don't have time now. This is an 'as-is' program.
Good luck.

Thanks
zuisti (Istvan K.)

[zuisti]

If anyone still had not found it ...

On the mikroC forum I published some (think) useful routines from my newly prepared libraries, now in pure C language, like:

- Dec_Bcd
- Bcd_Dec

- BcdOut2Uart1
- Dec2Out2Uart1
- BcdOut2Lcd_CP
- Dec2Out2Lcd_CP

- SetLcdPos
- BcdOut2Lcd
- Dec2Out2Lcd

Here you'll find:
http://www.mikroe.com/forum/viewtopic.php?f=88&t=57387
Unfortunately there was no sense of the thing, I do not got any feedback. Maybe here?

Rgds
zuisti

[zuisti]

** UPDATED Ps2 simulator library ** (02.01.2014, Happy New Year).

Now separated libraries for the three PIC families (pic12/16,  pic12/16_Enh  and  pic18).
Heavily hand-optimized for speed, and to minimize the code size, stack and ram usage.
The Ps2_Key_Read_ND (no keyname display) function is also added for time-critical applications.
In the attached RAR the description and the example projects are also actualized.  

zuisti
PS:
I would like to receive feedback!

[zuisti]

Does PIC18 series require a lot of alteration in your code? Do you have to rewrite the whole thing if you want to adapt it to another PIC version in the same family?

From the same family any PIC can be used. For example, my "p18_KbSim.mcl" library is good for any PIC18..., only properly have to define the port pins (like anyway also, look at my demo projects).

While you are using only pure C instructions (no inline asm) in your program, do not worry about the different PICs, the compiler knows, what it must to do. Only the project properly have to set.

[zuisti]

Thanks Ichan for your comments.

I would like to comment, but:
1. I do not use MikroC

In this case my libraries and other codes are really worthless for you (but see the title of this topic).

2. I can't see the code as it is in library form

Yes, but I think there is no point to publish the in asm written sources (see below).

3. I have no proteus installed on my pc anymore

My answer is the same as for your first comment: the Keyboard Simulator is working only in Proteus (since therefore made), it is also worthless for you.

... isn't that more common to convert numbers to string then kicking it out by a kind of string out function?

It may be more common, but sure it uses more ram (and stack depth), much slower and much longer in final code compared to the heavily optimized, almost full (family-specific) inline asm functions, which written by me, first only for private use, now I published them to use others too. Sorry.

[zuisti]

Two variants: high (80 pts) and low (48 pts) resolution.
Heavily hand-optimized for speed, and to minimize the code size, stack and ram usage.

The library contains two functions to create 16char wide bargraph(s):

void Bargraph_Init(void);

-    to create bargraph UD chars (2-7), 0 and 1 are free (empty),
-    and also 2,3,4 can be used (redefined) if no HiRes (see below).
-    It is small and fast (no any const char array).

void Bargraph(char HiRes, unsigned value);

-    value: 0 - 1023; if HiRes != 0 then 80pts else 48pts:
-    overrun protected: if value > 1023 then it displays 1023
-    always prints 16 chars (from the current cursor position !!)
-    Extremely fast and small (only 8bit arithmetics).
-    Resolution dependent proportional division with rounding.

-----

Separated libraries for the three families (pic12/16, pic12/16_Enh and pic18):
    there are three library prefixes:
    p16_    p16e_     p18_   
eg for a PIC16F1847 use the "p16e_Bargraph_MeLCD.mcl".

The "_MeLCD" postfix means that it uses (calls) two MikroE LCD libary functions:
     extern void Lcd_Cmd(char);
      extern void Lcd_Chr_CP(char);
However, you can write your own functions too :-) but use the same names.

The attached RAR contains demo projects too.

An improved, expanded version is also uploaded (but this 'old' also works):
http://www.sonsivri.to/forum/index.php?topic=52263.msg160361#msg160361

[zuisti]

            NEW,  ALL-IN-ONE Bargraph library

The library contains a function which allows to create parameterized bargraph(s) on an HD44780 compliant LCD.

-    Scalable, configurable via predefined mode constants.
-    Any width can be used, it's limited by the LCD line lenght only !!
-    8 different mode (variants): 3-5-7 segments and 35 pixels, all twice.
-    No any init function since the used custom char is on the fly defined
-    Max. 8 independent (even 1..4 char vertical) bargraph can be used on
          the same LCD (because there are only 8 custom chars).

Separated libraries for the three families (pic12/16, pic12/16_Enh and pic18).


     USAGE:

LCD_BarGraph(char cc,                     used custom char (0...7), must be unique !!
                       char pos,                   starting position, eg _LCD_THIRD_ROW + 3
                       char mode,                variant (use one of the predefined constants)
                       char width,                 number of chars, determines the full-scale
                       unsigned value);         will be displayed

The "LCD_" tag means that it uses (calls) two mikroE LCD libary functions:

      extern void Lcd_Cmd(char);
      extern void Lcd_Chr_CP(char);

and you have to use the usual LCD pin definitions and the Lcd_Init func
      (but you can write your own functions too, using the same names).


Animation shows how to operate the different modes:

      

Four different 14ch horizontal, three different 4char vertical Bargraph, full scale = 1024 counts:

      

I created several Proteus projects (attached with C sources) to show the possibilities.
The circuit is always the same, the "8chVoltmeter_4v9.DSN":

      

The outputs of the specific demo programs:

      
  
Enjoy (see attached)!
zuisti

[zuisti]

Upon request, I created an improved variant (add to my BarGraph library DEMO programs):

-  SW filtering:   four measurings/channel then average value will be calculated but only
   when it detects a difference compared to the previous (stored) average value, else the
   fast scanning (appr 9 ms / 8 channels) will be continued.
    - an improved 50 Hz noise suppression also can be used (with appropriate delays)

-  on the fly switchable high-res (pixel) bargraphs, now with rounded voltages
   and channel-number displaying (not the best but the space is limited)
 

   As before:

-  no floating arithmetics (fast)

-  small code (my all-in-one BarGraph function is only 213 bytes long on a P16)

-  full scale = Vref (VCC, now 4.9 V), with SW correction: see the docs.

-  resolution = 0.001 V (but 0.01 V with bargraph, after rounding)

-  accuracy   = +-0.1% (max 5 mV), plus the PIC's own ADC error, of course :-)
 

The entire mikroC project is attached, with the C source (detailed comments) and the DSN file. In Proteus (I tested only here !) it uses the COF compiler output so a source-level step-by-step debugging is also possible.

The pictures show the simulated circuit and the bargraph displaying (same input voltages).

zuisti

[zuisti]

There are 12 routines ("..." is the distinctive prefix, see below):

Code:

   String output:

...RstrOut (char* rptr)               //write out a string stored in Ram
...RstrNout(char* rptr, char N)       // the same but max N char(s)
...CstrOut (const char* cptr)         //write out a string stored in Code memory
...CstrNout(const char* cptr, char N) // the same but max N char(s)


   Direct conversion (without any temporary buffer):

...BcdOut (char)     //  "dd", char: max 0x99 (153), with leading zero(es)
...Dec2out(char)     //  "dd", char: max 99,                  -"-
...Hex2out(char)     //  "hh", char: max 255,                 -"-
...Hex4out(unsigned) //  "hhhh", max 65535,                   -"-

       Justified direct conversion
       (controlled by an additional "just" parameter):

       just = -1: (ie just.B7 = 1) no alignment (with leading zeroes)
       just =  0: leading zeroes will be supressed (left  justified)
       just =  1: leading zeroes will be a space   (right justified)

...Dec2out_J(char onebyte, char just) //    "dd" (or "d" or " d"), max 99 !!
...Dec3out_J(unsigned wrd, char just) //   "ddd", max 999
...Dec4out_J(unsigned wrd, char just) //  "dddd", max 9999
...Dec5out_J(unsigned wrd, char just) // "ddddd", max 65535

See the "COMMONFUNCS_DOC.H"

These heavily optimized (using family-specific inline ASM) functions are included in my two new libraries (presented now):

   "p*_UART1-LCDouts.mcl"
       prefixes: "UART1_" and "LCD_"    (see the "UART1-LCD-DOC.H")

   "p*_Out_Univ.mcl"
       prefixes: "Ptr_" and "Usr_"           (see the "OUT_UNIV_DOC.H")

For all 8-bit PICs, using different library prefixes (p*):

    p16   : PIC 12/16 (non-enhanced) family
    p16e : PIC 12/16  enhanced family
    p18   : PIC 18       family

For example use the "p18_UART1-LCDouts.mcl" for any PIC18 chip.

[zuisti]

This is the third part of my new library collection (the already published parts are the "Bargraph",
"PS2 Keyboard Simulator" and the "Common output functions").

Same way usable (uniformized) LCD libraries. Every precompiled lib allows you to manage up to
four HD44780 compliant LCD. For all 8-bit PIC.

"..Lcd" prefix is used to distinct the type of the interface:
     where ".." may be: (none)  B  w3  w2  w1  N8  B8  (eg p16e_w2Lcd-4.mcl)

  1.     Lcd      the usual nybble (4-bit) interface (most used)
  2.   BLcd      the same but with Busy flag checking (faster)

          using HC595 as a port expander (3 separated libraries):

  3. w3Lcd     3-wire interface
  4. w2Lcd     2-wire
  5. w1Lcd     1-wire

  6. N8Lcd     the normal full (8-bit) interface (smallest code)
  7. B8Lcd     the same but with Busy flag checking

So there are seven different library (sum 7 * 3 = 21 "p*_....-4.mcl" file, in
accordance of the three different PIC family; p* = p16, p16e or p18).

Every library contains 6 'fundamental' functions for the four (0...3) LCD:
   Init - WriteChar - Command - UserChar - GotoYX - GotoYX_16x4
using a specific, library-dependent prefix (eg w1LcdX_Init, where X = 0..3)

In addition, they contain the 12 'common output' functions for the ..Lcd0:
   CstrOut - CstrNout - RstrOut - RstrNout - Hex2out - Hex4out
   BcdOut - Dec2out - Dec2out_J - Dec3out_J - Dec4out_J - Dec5out_J

Detailed description in the "LCD-libs_DOC.H".
A demo project is included to show the 1-, 2- and 3-wire interface circuits.

[zuisti]

This is a newest member of my new, same way usable (uniformized) library collection
  (the already published parts are the "Bargraph", the "PS2 Keyboard Simulator",
  the "Common outputs" and the "Full LCD" libraries).

SwUart library v3.0.

Improved, expanded but almost full downward compatible version.

Allows you to handle 4 independent software (bit-banging) Uart.

Now also for all 8-bit PIC (pic12/16, pic12e/16e and pic18), so it is three different library
("p*_SwUart-4.mcl" file), in accordance of the three different PIC family; p* = p16, p16e or p18.

The library contains  5  'fundamental'  functions  for the four  (0...3)  Sw Uart:
   InitW - InitT - Write - ReadW - ReadT (now also 'zero' char too !!)
using the specific prefix "SUartX_", where X = 0...3

In addition, it contains the 12 'common output' functions for the "SUart0":
   CstrOut - CstrNout - RstrOut - RstrNout - Hex2out - Hex4out
   BcdOut - Dec2out - Dec2out_J - Dec3out_J - Dec4out_J - Dec5out_J

Detailed description in the "SWUART_DOC.H". A demo project is also included.

Istvan K. (zuisti)

[zuisti]

Memory manipulation function set. In addition, some simplified arithmetic
and bit-handling routines. All in one library named as "p*_Mem-Arithm.mcl".
For all 8-bit PIC  (pic12/16, pic12e/16e and pic18): p* = p16, p16e or p18.

My goal was to create some simplified routines (not so universal but much smaller
and faster as the official libraries) to manipulate strings, bits and memory.

Optimized for speed, and to minimize the size, stack and ram usage.
Very often used (family-specific) inline asm codes too.

The library contains a total of 45 function:

  sprint-like common output routines. S..., Si... (string insert): no end sign:

SHex2 - SiHex2 - SHex4 - SiHex4 - SBcd - SiBcd - SDec2 - SiDec2 - SDec2_J
SiDec2_J - SDec3_J - SiDec3_J - SDec4_J - SiDec4_J - SDec5_J - SiDec5_J

  string lenght (max 255):

RstrLen - CstrLen
  
  string manipulations:

SpaceStr - iSpaces - AllSpaces - iChr - ChrApp - LefTrim - RighTrim

  string/memory copying (from RAM to RAM):

RstrIns - RstrNins - RstrCpy - RstrNcpy - RstrApp - RstrNapp - RmemCpy

  const string/code memory copying (to RAM):

CstrIns - CstrNins - CstrCpy - CstrNcpy - CstrApp - CstrNapp - CmemCpy

  in addition, 4 simple 8-bit arithmetic functions:

Dec_Bcd - Bcd_Dec - DivMod10 - MiniMul_10

  and two bitmask functions (for the attached "pic_BitMacros.h"):

R2BitMask - R2BitMaskW

------

Just for example, the 16e "LefTrim" function is 5.39 times faster (64 vs 341 cycles)
and 2.9 times smaller (21 vs 61 bytes) than the original "Ltrim" routine, while working
on the same, 8 chars lenght string with 5 leading blanks.

Detailed description and some example in the "MEM-ARITHM_DOC.H"
Istvan K. (zuisti)

[zuisti]

Special request I made (and now publish) this 'simple' MMD.

- 67.5 Hz refresh rate at 40 MHz clock (in ISIS 30.4 Hz to avoid display flickers).
- 4 in 1: handles four independent char-lines (fix texts), common run/stop key.
  (using a timed state machine with six different phase)
- A bit tricky addressing of the two 4_to_16 demultiplexers (2 * hc154).
- Written in pure C, resizable and easily portable, verbose comments.
- Works with my 'good old' row-scanning algorithms.
- also detailed shows how to calculate the timings (using timer2)
  to get always the same brightness (switched on time) for every row.

Attached the complete mikroC project (with all sources) and also the
Proteus DSN file (it uses COF so the program is step-by-step debuggable).

 Tried only in Proteus !!

zuisti (Istvan K.)

[zuisti]

Code:

char GetParity(char ch) {
	R0 = ch;
	asm {
	   swapf R0, W
	   xorwf R0, F
	   #ifndef P18   // ie each P12, P16 and P16 enhanced
	     rrf R0, W
	   #else
	     rrcf R0, W  // the mnemonic is different  in P18 !!!
	   #endif	
	   xorwf R0, F
	   btfsc R0, 2
	   incf R0, F
	   movlw 1
	   andwf R0, F
	}
	return R0;      // there 1 means ODD and 0 means EVEN parity
}

[zuisti]

                    Compiler: mikroC Pro for PIC v6.01
         Proteus-only projects, using 2x16 LEDs and/or a 4x20 LCD
                        © Istvan K (zuisti), 2017

I made four projects that are in different folders:
  16F88_LED            18-pin PIC, 2x16 leds, exact timed multiplexing
  44K22_LED            40-pin PIC, non-multiplexed (direct) led control
  16F684_LCD          14-pin PIC, 4x20 LCD
  44K22_LCD-LED     LCD and LEDs, both at a time (see the video)

Common features:
- runtime switchable characteristic:
   lin:   6 to 100 %
   log: -36 to +12 dB, 3 dB/step
- a real wav audio file is used as an input (cannot be heard in Proteus)
- adjustable input LEVEL (sensitivity)
- 250 Hz refresh rate (4 ms)

LED bargraph:
- level-dependend LED colours (12 green, 3 yellow, 1 red; a total of 16 leds)

LCD:
- 16 chars wide bargraph using User Defined Chars (UDCs)
- always visible scale-line (part of all UDCs)
- displayed audio channel (R and L) and current unit (% or dB)
- displayed scale values (second line)
- level-dependend shapes (UDCs) to imitate the different led colours
- runtime switchable 3 different sets of shapes (UDCs): three diff. modes
- the first line shows the current characteristic (lin-log) and mode (0-1-2)

For more description see the included "README_FIRST.TXT" (and the source) files.
--------------

A video to show how to works the simulated LED and LCD VU meter
(the "44K22_LCD-LED" project was used, its circuit is attached as a GIF):
https://youtu.be/9ftmeEKwxGA
 
The included wav file greatly increases the size of the RAR (because it is not
really compressible). Therefore, I uploaded the complete RAR to the 4shared page:
https://www.4shared.com/rar/UHvcPpHKei/VUprojs_up.html

[zuisti]

So far 17 downloads and no any feedback (and only 3 thankyou   ), although I worked hard on it.
I would like to thank someone for a better (more effective) peak-hold algorithm than what I wrote and published.

Since then, I've made a 'one-line' stereo VU meter project, which only uses the bottom line of a 16x2 LCD.
The picture of the working simulation is attached, but I do not want to publish the entire project, sorry.

zuisti

[zuisti]

16-stage stereo peak hold/decay VU meters, see my post #25 above.
  Attached the expanded and improved version 2.1.

What's new ..

Two new projects:

   the 'one-line' stereo VU meter, in the "ONELINE" folder (see my prev. post)

   on request a 2x10 LED version, in the "16F88_2x10led" folder. See this topic:
   http://www.sonsivri.to/forum/index.php?topic=64785.msg186112#msg186112


Fixes:

   The displaying of the text "lin/log" on the upper LCD line now changes already
   at runtime too (according the jumper).

   New, faster and smaller Lcd_Goto functions (see the "LCD_Lcd0.h").

   Separated "poscalc.h", so it is easier to create multiple instances with
   different names (and different, own static variables).


Each project was recompiled. Read more in the new, improved "README_FIRST.TXT".

Note:
To decrease the size of the uploaded RAR the "test.wav" file is missing in the "wav"
folder (as I wrote it is not really compressible). Please copy from the previous RAR.
Likewise, the video (the AVI file) is also missing as it has not changed.

Greeting,
zuisti

[zuisti]

My forgotted promise (I apologize) but now I post the full version of the two MMD tasks.
Each "Proteus-only" project is completed with its C source file(s) and the DSN.
The projects were written in mikroC v6.01, using the "case sensitive" mode.

8pin_MMD   rs232 (and CTS) controlled, using a 'virtual' PIC16F683 (due of the COF).  
MMD_Ps2    PIC16F628A MMD circuit, controlled via real/emulated/simulated PS2 keyboard

Read more in my prev. posts (#8 to #11 in this topic).
-  for example see the pictures here:
http://www.sonsivri.to/forum/index.php?topic=52263.msg152862#msg152862

But - sorry - no any 'support', I do not have time. These are 'as-is' projects.

  A question:
- Would you be interest for the source of my PIC18_MMD project? This I've written a
long time ago (in 2012) yet in Proton BASIC. This link shows the features:
http://www.sonsivri.to/forum/index.php?topic=42842.0
If so, I will look in my archive ...

Edit: Found it, uploaded, here you go:
http://www.sonsivri.to/forum/index.php?topic=42842.msg186534#msg186534

Thanks
zuisti (Istvan K)

--------
pickit2: Please Keep this Topic Clean - make replies to posts here:
http://www.sonsivri.to/forum/index.php?topic=64785.0

[zuisti]

I'm constantly working on my new mikroC libraries. As usual I'm using
family-dependent asm optimizations so the libraries remain closed as before.

Now my new Button library is presented, and attached a complete demo project
which detailly shows the usage. Here is the C source:

Code:

/* Button_demo.c (to show how to use my new Button library)

  © Istvan K (zuisti), Apr. 2018

Tried in Proteus using the "628_button_demo.DSN" (PIC16F628A)

  Do not select the standard Button library (name conflict !!), instead
  my new p*_Button.mcl (now p* = p16) is used locally (found in 'lib' folder).
  Simply add the library to the 'Binaries' node in the IDE's 'Project Manager'.

The library allows to use three functions (see also below, in the program):  */

extern char Button(char* port,         // port address (&PORTx)
                   char  pin,          // pin number (0..7)
                   char  DtimeMs,      // debounce time in ms (0-255)
                   char  wantedstate); // 0 or 1
/* exactly the same as the original function (see help) but
   it produces much less code and more useful return values:
if the pin was in the wanted state for the given period then (as the original)
it returns with a nonzero value (and Z_bit will be 0) but this (always nonzero)
value is the internally calculated pin-mask, which is more useful than the 255
(the demo program shows an example how to use this feature).
  Otherwise (ie if no match) it returns 0 and Z_bit will be 1 so this flag
can be tested instead of R0 (less code)  */

extern char WaitPress(char* port,
                      char  pin,
                      char  timelimit, // in 20 ms unit, longpress limit
                      char  pressedstate);
/* blocking function: wait for the keypress with debouncing, 'measures'
the lenght of the keystroke then waits for releasing also with debouncing.
 Returns 1 (and Z_bit = 1) if the lenght is less than the given 'timelimit'.
Otherwise, in case of a 'long' press, it returns 2 and Z_bit will be 0.  */

extern char isPressed(char* port,
                      char  pin,
                      char  timelimit, // timeout and longpress limit
                      char  pressedstate);
/* non-blocking function: wait for the keypress with timeout and debouncing.
The parameter 'timelimit' is used as timeout value also, and if it does not
detect a valid keypress in this time interval (time is off) then returns 0 
and Z_bit will be 1. Otherwise, as the above, it 'measures' the lenght of the
keystroke then waits for releasing also with debouncing. In this case Z_bit
is zeroed and returns 1 if the lenght is less than the given 'timelimit', and
returns 2 in case of a 'long' press (lenght of the keypress >= timelimit)   */

// ------------

// a (not so useful :-) demo program to show the usage of the above functions:
void main(void) {

  NOT_RBPU_bit = 0; // portb pullups on (active 0 buttons)

  // WaitPress() is a blocking function so it is placed outside of the main loop
  R7 = WaitPress(&PORTB, 5, 25, 0); // on Rb5, 25*20=500 ms timelimit, 0 active
  // its return value (R7) is watched in Proteus (in the 'Watch' window)
  // ** depending on the specific value we can create more program branches here

  while (1) { // loop time is appr 0.5 sec due to the isPressed() timeout

   if (isPressed(&PORTB, 6, 25, 0)) { // on Rb6, 25*20=500 ms timelimit, 0 active
      R8 = R0; // watched too (1 or 2)
   } 
   // next line shows the usage of the Z flag as return value (0: matched)
   else if (Button(&PORTB, 7, 20, 0), !Z_bit) { // Rb7, 20ms debouncing, 0 wanted
      R8 = 0;  // clear the last isPressed() result (apply a long press !!)
   }
   // continuous watching the four dipswitch states using only one variable (R9)
   R9 = 0;
   R9 |= Button(&PORTB, 0, 20, 1); // Rb0, 20ms, 1 wanted  *** and so on ***
   R9 |= Button(&PORTB, 1, 20, 1);
   R9 |= Button(&PORTB, 2, 20, 1);
   R9 |= Button(&PORTB, 3, 20, 1);
   // eg. this is what the new return value (pin-mask, instead of 255) allows.
  }
}

I hope it will be useful also for you, try it out.
zuisti
Here is the Proteus screenshot and the project ZIP

[zuisti]

My new "LCD ready" Keypad libraries can be divided into two main categories:
- 4x4 keypad libraries
- 4x3 keypad libraries (having one free port-pin which can be used as LCD_EN)
Both have two versions:
- using column pulldown resistors
- using column pullup resistors (may be internal !)

Of course, all the libraries were made in 3 different versions according to the
3 different PIC families (p16, p16_Enh and p18).

The Keypad libraries are "LCD-ready", which means that the same port can be used
to control an alphanumeric LCD, using the standard mikroC library.

For detailed description look at the attached "8pinKeypad_lib_DOC.H" file.

Attached also a complete demo project to show how to use my new Keypad library.
"LCD, 4x3 (phone) keypad and two momentary buttons: all on one 8-bit port"
- switchable numeric/alpha (upper and lowercase) keypad characters,
- displays a '!' warning char while a button (key) pressed and does not released,
- Proteus simulation, using a standard 4x3 "phone" keypad device and a 16x2 LCD.
A screenshot is also attached.

I hope it will be useful also for you, try it out.
IstvanK

[zuisti]

On request I wrote (in 2015) a PIC program to decode and display the standard RC5 remote contoller's signal. As I do not have such controller, to try the program I made also an interactive (8-button) EasyHDL script generator in Proteus to emulate the remote contoller:
one-shot or repeating, idle: HI, true toggle-bit handling, also extended commands ...

For details see the C source file in the attached project.

[zuisti]

As on the old (non-smart) phones each keypad button allows us to choose more (here: six) variants.  For example:
-   to choose the 3rd variant (char): short keypress 3 times,
-   6th ie the last variant (often a digit): 1 long keystroke
The 6 variants per button allow you to use the full English ABC and all the punctuation marks.

By default, letters are uppercase (can be changed any time), the lowercase letters in the table (f,b,s,c,t) execute a command. See the picture below and the C source files.
I made a complete Proteus project (attached) to show how to use it. The project is full with sources, it uses only standard mikroC libraries.

[zuisti]

The program is waiting for a key to be pressed and then emits its code to the serial (TTL-level RS232) output. After releasing the key, it sends a zero character (in the Proteus an 'r' letter).

Selectable (by a jumper) 4x4 or 4x3 keypad output codes: see picture.

The switchable p12 keypad library (written by me, using a lot of assembly codes) is attached in binary ie MCL form. The operating program is written in mikroC, so it is easy to customize.

This small circuit can be built as a backpack for an existing 4x4 keypad.

[zuisti]

Full function alarm clock using a DS1307:

- (only) two-button treatment, 16x2 LCD with I2C 'backpack', blinking alarm LED
- adjustable RTC time-date, the (abbreviated) name of the day too
- settable alarm (status, hours and mins), stored also in RTC user ram
- restore alarm settings at next power-on (remember it if we have RTC battery)
- the alarm lasts for 1 min but can be switch off at the touch of a button
and so on, see the picture, the source files, and try the working simulation.

It's not a big deal to write a program with the above features if you have an MCU with many ROM and RAM, but this little PIC was a real challenge.

The PIC12F629 I'm using is really small, having only 1024 program words and 48 bytes RAM. The program (written in mikroC) occupies almost all the resources:
- Used ROM (program words): 1019 (100%), free: 5 (0%)
- Used RAM (bytes): 41 (85%)  Free: 7 (15%); according to the compiler's "log" file

To do this, I had to use own (very small but fast) Sw I2C and LCD functions, and the applied algorithms are also new (for example, there are no bcd-dec and dec-bcd conversions). True, in this digit-oriented algorithm, the programming of the limits (for ex. the month can only be 1-12) is a bit cumbersome and also the code space is too small so this is not complete but can be used (pay attention).

Even so, I used also some tricks with the FSR (named also as FSRPTR, which is an 1-byte C pointer in the non-enhanced p12/p16 world: less code !) and the INDF (treated as a char pointed by the FSR).

The program itself is very concise, not so easy to understand, although I tried to make many comments. Only for experienced PIC programmers, sorry.

The here applied Sw I2C and LCD functions I tried also in the real world (in another program), they worked well.

----------
However, since I find so that here is no real interest in my simple PIC projects, now I uploaded only the Proteus simulation and the HEX file (compiled especially to taking into account how works the simulated DS1307 device), and look forward to the comments from those who have tried it.

I would be delighted if someone would write a better clock program for this little PIC, but I would also like to welcome any suggestions. Thanks in advance ..

Istvan K (alias zuisti)

[zuisti]

  In my previous post I uploaded the working Proteus simulation of my first solution (with PIC12F629), hoping to get some feedback. Well, so far 27 downloads (with 6 thankyou's, thanks :-), but no any response, comment nor advice. That is why I do not upload the entire project, it makes no sense.

  In the meantime, I've been upgrading (finishing?) the Clock project, that I want now to show. As the supplements were not fit in the small PIC, I used the larger PIC12F683, having 2k code memory. Perhaps this may be more interesting, but at least try it out:

Alarm Clock with auto day-of-week calculation:

- the program works as well with the DS1307, DS3231(M) or DS3232 chips (using same HEX)
       to show this, I made a switchable Proteus simulation also (do not switch RTC while runs)

- auto day-of-week calculation and display (also while day, month or year is modified)

- the alarm settings are saved (and restored at next power-on)

- different buttons to increase/decrease the selected value, using its specific limits:
     sec, min: 0 to 59
     hour: 0 to 23 (24 hours mode)
     day: 1 to 31 (or 28 or 29 or 30, depends on the month and year, calculated)
     month: 1 to 12
     year: 1 to 99 (2001 to 2099), leap-year handling

- auto back repair (an interesting problem I faced to, hope it's solved):

 Not as often, but modify of the month can be resulted also an invalid day-value. An example: if the date is 31-12-18 and we modify the month to 11 (November is a 30-day month), then the resulting date (31-11-18) would be invalid. In such cases the program will step back to the day's adjusting (to signalize the repair) and automatically corrects the day's value (in our example the invalid 31 will be 30), so the final date (30-11-18) also will be valid.
This is my solution, the "back repair". Try it out.

I'm really looking forward to your valued comments and advices.
Regards,
Istvan K (alias zuisti)
PS:
I apologize for the bad English.

[zuisti]

The newest update of my RTC project is the "Multi-Alarm Clock", that I want now to show.
Here are the new features (but also look at my previous posts) :

- three independent daily alarms (a-b-c), choosable displaying
- alternating date and temperature display (can be off)
- button sounds (acoustic feedback, can be off)
- the settings are valid until power-off but can be stored
- forced cold start (without battery detach):
    set the C alarm to 00:00, it is working fine until
    power-off, but the next power-up produces a cold start.
    Alarms A or B work well at 00:00 also, so use them if
    you really want to wake up daily at midnight :-)

It works well with Ds1307 and also the Ds3231M (see photos), using the same HEX.
This HEX is also used by the included Proteus simulation, which shows the treatment
in detail (see GIF images). This way you can test the Clock without building it, so
I'm looking forward your valued comments and advices.

---------

The circuit was built on a breadboard, using cheap chinese modules I bought on Aliexpress:

16x2 I2C LCD module (using a PCF8574 I2C 8-bit port-expander backpack)
Its I2C address is 0x4E (in 7-bit form: 0x27), fixed: A0..A2 tied to VCC

RTC modules, using a 3.6v LIR2032 accu (just one RTC module is used at a time :-)
- "ZS-042" RTC module (mine is Ds3231M, unfortunately)
- Tiny RTC I2C module (Ds1307)

An experience with the Tiny RTC module:
 Due to the 3.6v accumulator, the "original" Ds1307 module uses a high-impedance
voltage divider, that makes it susceptible to interferences and can cause startup
problems. A small filter capacitor (47-100nF) on the BAT terminal solves this problem.
 Or - modify the module (in a way that can be found on the net) to be use a 3v CR2032 coin cell.
But .. due to my weak vision (I'm 75) I didn't do this.

Note:
The Ds3231M is less accurate, but has an advantage also: it updates the temperature
registers every 10 seconds while the Ds3231SN only every 64 seconds.

Regards,
zuisti
PS: Sorry for the bad quality photos ..

[papy_bidouille]

hello zuisti
would there still be some room to put an alarm on the temperature .temperature at 1 or 2 degree C ° "frost free" even this one is fixed at the compilation
cordially

[zuisti]

.. would there still be some room to put an alarm on the temperature .temperature at 1 or 2 degree C ° "frost free" ...

  An interesting idea. Using this small processor this is not feasible as it is already almost full, but it is possible when we use a larger processor eg the 12F1840. I do not promise anything, but if I have time and energy, I will try.

 Otherwise, what do you think? Don't need the three timed alarms, but warns if the temperature measured by the DS3231's built-in sensor falls below the editable set value?
And what about hysteresis?
And can the temperature alarm be turned off?
  and so on ...

Note: you know, there are many much simpler solutions to this task on the net.
zuisti

[zuisti]

This is a small but useful extension for the 3-alarm clock (see my post #35 and #36).
The circuit (and its handling) remained unchanged, only the name (and operation) of the 3 alarms were modified as follows:

- W alarm (on Working days only, Monday through Friday)
- R alarm (on Rest days, Saturdays and Sundays only)
- A alarm (simple daily Alert, same as the alarm C in post #36 above)

  The pre-set (but adjustable) alarm times (at start all three are off):
w 07:00 (hour:minute, lowercase 'w' = disabled)
r  07:30
a 08:00 (usually this is not used ie remains off)

  Of course, the distinction between work days and rest days only works properly if the RTC time and date is set correctly on the first power-up.

  To try it, simply use the supplied new HEX, either in the Proteus simulation (using the DSN attached to my post #36), or in the real circuit, after re-burn the PIC.

Best regards,
zuisti

[towlerg]

Just object, no source? is this code proprietory?

[zuisti]

Just object, no source? is this code proprietory?

No, of course the entire code is mine and it is not patented (though not a bad idea :-)

I apologize, but - as I wrote also in my post #34 above - I'm unsatisfied that so many people download my projects, but I don't get any feedback. In future I don't want everyone (even a whole new member) be able to download the entire project.

Those who are really interested in the projects will find a way to get in touch with me, and so I always know who got the whole project (strictly for their own use).

I have to say that these RTC clock programs are not very simple and transparent, because I wrote them primarily to myself (using mikroC v6.01). But ... they work well also in reality.

One more note: my programs use a lot of assembly instructions (due to higher speed and less code). Even so, for example the last project (the weekly alarm clock) code leaves a total of 1 (one !) free program word out of 2K.

In short, I suggest these programs only for experienced PIC users.

Regards:
zuisti

[towlerg]

Zuisti, of course you are entitled to protect your work. I have no interest in the project per say but it's useful to see how different people deal with the interface to the various components used in your project.

I hope you don't think this is patronising, but very nice work.

[zuisti]

  My last project (the Weekly Alarm Clock, see above, the post #39) has been built by several of my friends and is still being used with satisfaction.
  Now I present my latest job, which is also useful in practice, I think so.
That is a 8-output Weekly Switch Clock (like the previous ones, this is also a HEX project that can be built, but it can be tested also in the attached Proteus simulation).

Short description:

The system can handle a total of 52 independent scheduled events (operations).
Each event has a unique name (A..Z, a..z) and has 4 editable attributes:
- action type; the given output bit(s) will be:
    '+' (HI) 
    '-' (LO) 
    't' (toggled) 
    '.' --------- the event is disabled
- the output bit to be modified (0..7, 8: all)
- the executing time: hours (in 24 hrs form) and minutes
- the day(s) when the event is executed:
    'Su' or 'Mo' or ... 'Sa' (only on the specific day of the week)
    'wD' (on working days only, Monday through Friday)
    'rD' (on rest days, Saturdays and Sundays only)
    'eD' (every day)

  Initially all events are set to ".1 12:00 eD" (disabled !, outbit=1, hour=12, min=0, every day), but all changes will be saved (in a compressed form) when we exit from the event editor. I use the I2C EEprom on the RTC module to store the 52 events, but they are copied to the PIC RAM too, for quick time-comparing.

  The attached HEX is assuming the Chinese DS3231 RTC module (named as ZS-042, see the post #36), the DS1307 Tiny RTC module I2C EEProm's address is different (0xA0, instead of 0xAE). This also can be used, and the DS3232 too (without EEprom as it has enough free RAM, but that is not a PDIP device). I have also created and tested these HEX files (one for the DS1307 Tiny module and the other for the standalone DS3232), on request I can send them.
  The 8-bit output is also a Chinese module: a PCF8574 I2C port expander with 3 address switches. If necessary, use a buffer IC too.
     
  The system stores all changes (including the settings and the status of the outputs) immediately, and after a power failure it restores everything: real warm restart.
  The last executed event is also stored (and displayed, in abbreviated form, eg C+3).
If it was a full 8-bit set/reset (using the buttons or initially) then "++8" or "--8" will be displayed as that is not a real timed event.
  Because of the finite (though very long) EEprom lifetime, the above immediate "backups" use the RTC RAM.

  In addition, the display shows the time and the day of the week, while the second line displays the status of the output bits.
  The full date and the measured temperature are displayed when we change the beep, ie turn on (or off), but only for cca 2.5 seconds (I think this is more than enough).

Look at the picture of the simulation for details.

Build it!
zuisti

[FranzW]

Upon request, I created an improved variant (add to my BarGraph library DEMO programs):

-  SW filtering:   four measurings/channel then average value will be calculated but only
   when it detects a difference compared to the previous (stored) average value, else the
   fast scanning (appr 9 ms / 8 channels) will be continued.
    - an improved 50 Hz noise suppression also can be used (with appropriate delays)

-  on the fly switchable high-res (pixel) bargraphs, now with rounded voltages
   and channel-number displaying (not the best but the space is limited)
 

   As before:

-  no floating arithmetics (fast)

-  small code (my all-in-one BarGraph function is only 213 bytes long on a P16)

-  full scale = Vref (VCC, now 4.9 V), with SW correction: see the docs.

-  resolution = 0.001 V (but 0.01 V with bargraph, after rounding)

-  accuracy   = +-0.1% (max 5 mV), plus the PIC's own ADC error, of course :-)
 

The entire mikroC project is attached, with the C source (detailed comments) and the DSN file. In Proteus (I tested only here !) it uses the COF compiler output so a source-level step-by-step debugging is also possible.

The pictures show the simulated circuit and the bargraph displaying (same input voltages).

zuisti

Hello zuisti,
Thanks for your post. The three files seem to be corrupted. Would you  please upload them again?
Best regards,
FranzW

[sphinx]

here you go

[zuisti]

Hello zuisti,
... The three files seem to be corrupted. Would you  please upload them again?

@FranzW: the corrupted file is uploaded (attached) again.
But note: this is a very old solution written by me :-)
Hi there,
zuisti

[zuisti]

This project is an improvement of my LCD clock programs (see the posts #35 and #36 above, in this thread). It uses the same hardware, complete with a PNP transistor that allows the LED and BUZZER to be controlled independently (see the schematic).
 
Large-digit hour-min display using user-defined chars. These chars also use the lowest,ie the 8th pixel-line (see photo), which Proteus cannot display due to an error of the LCD model. For this reason, the simulation runs with a modified HEX file in which the UDCs are using only 7 pixel-lines. Because of this, the large digits are not as 'beautiful' but recognizable also in Proteus.

The system can be customized at runtime (almost everything is adjustable).
New  settings are saved, using the RAM of the RTC and (for the corrs) the PIC's EEPROM.

At startup, all settings are displayed for one sec (or while INC is  hold down).
This also can be turned off (using DEC):

Code:

     S/s: suppress zero '10hours' on/off
     | T/t: alternating Temperature-Date displaying on/off
     | | B/b: button sounds (acoustic feedback) on/off
     | | | A/a: alarm beeps (ringing) on/off
     | | | | F/f: star/T flashing on/off
     | | | | | U/D: snooze/timer count up/down
     | | | | | |    (elapsed /remaining time display)
     | | | | | |
Set: s t B A f D    >>  default (initial) settings
Corrs: 05 01 -14    >>  defaults, the -1.4 ppm is an empirical value
       |  |   |
       |  |   .1ppm (RTC align: aging reg's value, -99 to +99 * 0.1 ppm)
       |  len_A (alarm ringing time, 0 to 99 minutes)
       snooze duration, 1 to 99 minutes; the timer also uses this value

There are three different alarms:
   A0 (w): on every workday (Monday to Friday)
   A1 (r): on every rest day (Saturday or Sunday)
   A2 (e): on every day of the week, or only once ('s'ingle), changeable
Their actual type (state) appears also on the normal display (eg WRe: A0 and A1 are active but A2 is not)

The DSN captions show the treatment in detail, except for the following:
    Changing the type of A2 is a bit tricky:
  In the alarm editor choose A2 and then press INC:
  now only the type changes ('e'very <> 's'ingle) as there is no A3 :-)

- Visual feedback of any button press or while alarm (LED flashing).
- Acoustic signals (beeps), can be turned off

- Classic snooze, can be started only while alarm; restartable and deletable.
- General up/down timer, can be started at any time except while alarming.
- The snooze/timer is interrupted by an (other) alarm scheduled for its duration.
- Priority order: A0(A1) - A2 - snooze/timer expiring

- Forced cold start (see post #36) is moved to A1 (set 'r' alarm to 00:00)

-------
Attachments:
- a photo of the clock constructed (see the large digits)
- the complete, well working Proteus simulation (try it).

[zuisti]

Further development of my last project (see above, the post #47):

        HW changes:
- 4x20 LCD (instead of the 2x16): larger display, more info.
- rearranged port bits (to use HW I2C routines instead of the old SW I2C).

        Missing (omitted) features, compared to the previous one:
- snooze/timer elapsed time displaying (count up),
    now always the remaining time is displayed (countdown).
- forced cold start.

        New functions:
- 16-sec timeout in each editor, can be off.
- clock's ticking (short LED or buzz signal, once per sec), can be off.
- changeable fonts for the large clock digits (thin:0 - bold:1 - huge:2);
    As long as you hold down the DEC key, each short press of SET selects
    and displays the name and nr of the next font (cyclic: 0-1-2-0-1 ...).
    Release the DEC button to display the clock in the last selected font.

The assembled circuit (on a breadboard, see photo) is working properly.

Note: The very short (10 msec) tick signals work perfectly in the reality
    (both for LED and Buzz), but this short LED signal is not visible in
    Proteus while the Buzz signal works well. Maybe a Proteus setting ??
Edited: the issue is solved, look at this new topic:
http://www.sonsivri.to/forum/index.php?topic=69802.msg202463#msg202463
In that topic I answer questions about how simulation works.  

        About the source:
I wrote it for myself (using mikroC v6.01, without the compiler's closed libraries),
and I'm constantly working on optimizing. The included code is the (well-functioning)
last version that is still relatively easy to read (and understand).
  Subsequent optimizations make it increasingly difficult for other people to
understand the code. But, with these I have achieved significant RAM and FLASH
savings (important for in the future planned improvements).

The code itself is quite large and complicated (many unusual asm tricks).
Since I wrote it to myself, there are relatively few comments (sorry).
Therefore, I only recommend it to really experienced PIC programmers.

This is an "as-is" software (no any support), sorry but I do not have time.

** To get all source files first read the "src_readme.txt" file in the attached RAR.

Regards:
zuisti

[sphinx]

https://www.sonsivri.to/forum/index.php?topic=52263.msg159103#msg159103

https://www.sonsivri.to/forum/index.php?topic=52263.msg159103#msg159103

i know these files are sort of old in these posts but ask if it possible to repost the file if possible
thnx in advance

[zuisti]

Hi sphinx,
First, your two asked links are the same.

Second, I found in my archive (and attached) the "BarGraph.rar"  which is corrupted in the original post while a server-change.

Good luck.
zuisti