Hello BMorse,
I suppose I owe a big apology to you for not telling you that I was going on a business trip. It has taken much longer that I had thought. I thought it would only take a couple of days thus the reason for not telling you. This has really been my first chance to update myself with the forum while on travel. I will be back home in 48 hours time and will take it from there.
see you soon,
Bluebird

 

Hold off on ordering parts just yet, I have been doing some brain storming and I believe I have managed to get the component count down to half and still keep the same functionality.. I didn't like the fact of having too many relays and stuff, way too much power consumption, and I was planning on possibly adding a battery backup, so keeping the power hog components down to a minimum would be good.. off to go do some testing and see if I am correct in my assumptions....


B. Morse

 

Hi BMorse,
Well I am back now. I have noticed that you did ask my opinion regarding the use of the UBW32 Module to which I had no chance of replying 'cause I was away. I suppose it is too late to give a preference now but just for the record, I would prefer to use something more straight forward like a PIC16F series uC programmed in C if at all possible. Of course this modification could remain for later when the more important aspects of the project have been taken care of.
Thanks a lot,
Bluebird

 

I had managed to do some testing on the "newer" design with less components, and it is a success, I will post the new circuit schematics on here once I get them touched up and a new BOM for the phone interfaces.....

@ Bluebird:
The way the circuit is now, it can be controlled by any Pic or uc you would prefer... as a matter of fact the circuit is designed specifically to be compatible with any uc you choose, I was just going with the UBW32 since that is what I have on hand plus it has the RTCC built in for better time keeping, since you are going to have to set an "off" and "on" time for the ringer. I don't think any of the PIC16F family has RTCC built in do they? If they do, I might have missed which one.

So as far as what you wanted to do with the phone, it could easily be done without any of the other "upgrades" I wanted to include to your idea.

B. Morse

 

I definitely prefer to have the final circuit with all your upgrades. In fact it is more of a curiosity matter now and less of just a ring inhibiter case. So pls. take as long as it takes because I am really enjoying to see the growth of a small seed into a little tree!. As I have said in the past I am not exactly an expert in the field of electronics so always take what I say with a pinch of salt!! especially regarding uC matters.
So may the force be with you.
Bluebird

 

Here is the "new" less components circuit, the only issue I am trying to resolve now is the "Phone_In_Use" part of the circuit, I actually need R13 to hang accross TIP and RING in order for the system to "answer" calls, when I do this that part works, the circuit can answer or "pick up" the line, but the line monitoring opto does not switch on when the line is hung up again (the line voltage goes to about 51 volts when the phone is "on hook", and around 7.8 when "off hook"), now when I place R13 the way it is shown in the circuit, I get the "Line_In_Use" opto to work properly (Low output when line is not in use and high when in use), BUT the system can not "pick up" the line when a call comes in...... regardless I will have this resolved in a couple of days as soon as I get more time to work on it, other than that things are pretty much on their way, I still have yet to test the RTCC crystal I added to the UBW32 module.... more on that too in a couple of days.......


B. Morse

 

I finally got around to testing the RTCC crystal and caps I salvaged from another board, it seems the caps might have gotten damaged when I removed them from the old pcb (The crystal wouldn't oscillate unless I had one of my meter probes on one of the osc pins), I ended up having to replace the caps, and now the RTCC is up and running on the UBW32 module .....

So now we are off to do the "fun" stuff .

I ended up downloading the HelloUSBworld.zip from the UBW32 site and used that as the template for this project, it still utilizes the bootloader, but the code for the USB UART is at a minimum, which in our case we do not have a need for all the USB bit whacking they had in there, but we will leave in the USB UART code for later use (in case we need to add some other functions, and possibly have an interface to a PC so functions and programming could also be done from there, that is another future expansion for this project...)

So am I going too fast on this or would you guys rather see me just get it done and you will build it from there once I have the basic functionality finished?

B. Morse

 

Any approach that you feel comfortable with suits me fine. Keeping us up to date from time to time would of course be appreciated. I just want you to know that all your efforts are appreciated heartily.
Cheers
Bluebird

 

I prefer the published brainstorming/boardstorming method, myself. Keeps me interested during the build.

 

I prefer the published brainstorming/boardstorming method, myself. Keeps me interested during the build.

Well then here's one for ya,
I have been playing around with the code and getting things situated with the RTCC, I have everything working on it and I had gone ahead and wrote a routine to set the alarm on it and have it turn off an led when alarm goes off, I also had set the external RTCC output pin to toggle when the alarm goes off, well the pin toggles, all code seems to work except for the interrupt routines.... I did some digging and for some reason they have the bootloader disabling the ISR's and supposedly you can't use interrupts, but I wanted to use interrupts for the Ring_Detect and a couple of other's, so now I have to dig into the code for everything including the bootloader files to see if there is a workaround on this.....

If anyone has a way to enable interrupts with the UBW32 or figure out how to reroute the ISR's to the new vectors please chime in, it will save me the headache!


P.S.
I already googled my a$# off and can not find anything on this, the only thing I found on the Microchip forums was that they had modified the Core Timer ISR to do what they want and poll the other Interrupt flags from there, but that is not a "real" interrupt if you have to poll it!!
B. Morse

 

So are you going to scrap the bootloader?

 

Well, If I do that, then I will have to use my Real ICE to do the programming (can't use Pickit2 in MPLAB with Pic32 uc's for debugging), and then we are getting to the point where it will start getting expensive for people to follow along.....

I think I am going to find a way around this interrupt issue instead, since no one has a solution to it, might as well try to come up with one.

I found this info, I guess it will be a good start, although it seems to relate to the PIC18 more so than the Pic32...

Bootloader Entry Method: As currently configured, the bootloader firmware resides in program memory in address range 0x00-0xFFF (on PIC18 devices, different for PIC24 and PIC32 devices). Almost immediately after coming out of reset, the bootloader firmware checks an I/O pin. If the I/O pin reads logic low, the microcontroller will enter the bootloader firmware. If the I/O pin is logic high, the bootloader will immediately exit the bootloader and go to the main application firmware “reset vector”. The specific I/O pin that will be checked is different for the various versions of the firmware projects. As configured by default, when used with one of the Microchip USB related demonstration boards/platforms, the I/O pin that is checked will have a pushbutton attached to it.

In other words, at startup the bootloader effectively does this:

//Device powers up, and comes out of POR
if(I/O pin pushbutton is not pressed) --> goto 0x1000 //main application “reset vector”
if(I/O pin pushbutton is pressed) --> goto/stay in the HID bootloader firmware.

Effectively, the “reset” vector for the main application firmware is at address 0x1000. In the main application firmware project, the user should place a “goto _startup” at address 0x1000. This will allow the C initializer code to execute, which will initialize things like the software stack pointers and any user “idata” variables. For an example, see one of the USB device firmware projects, such as the “HID - Mouse” project. By default, most of the project varients are already configured to be able to generate .hex files that can be used with the HID bootloader.

In the MCHPFSUSB v2.4 release, the PIC18F87J50 family and PIC18F46J50 family versions of the HID bootloader firmware also contains an alternative software only entry method into the bootloader. If executing the main application (non-bootloader) software, the main application may enter the bootloader by:
1. Clearing the global interrupt enable bit (INTCON<GIEH>
2. Execute the instruction: “_asm goto 0x001C _endasm”
It is not necessary to have the I/O pin in the logic low state when using this software entry method.


Vector Remapping: As currently configured, the bootloader occupies the address range 0x00-0xFFF (on PIC18), which means it occupies the PIC18 reset, high priority, and low priority interrupt vector locations. The bootloader firmware itself does not enable or use interrupts. In order to make interrupts available for use by the main application firmware, the interrupt vectors are effectively “remapped” by placing goto instructions at the actual vector locations. In other words:

Address 0x08 (high priority interrupt vector), contains a “goto 0x1008”.
Address 0x18 (low priority interrupt vector), contains a “goto 0x1018”.

For example, if a high priority interrupt is enabled and used in the main application firmware, the following will occur:

1. Main application enables the interrupt source.
2. Sometime later, the interrupt event occurs.
3. Microcontroller PC jumps to 0x08.
4. Microcontroller executes a “goto 0x1008”.
5. Microcontroller executes the main application interrupt handler routine, which has an entry point at address 0x1008. (Note: The interrupt handler routine itself is not required to be at address 0x1008, instead another bra/goto may optionally be located at 0x1008 to get to the real handler routine)

Note: When using the HID bootloader for PIC32 only (not applicable to other devices), it is important to modify the procdefs.ld file to relocate the sections of code that will hold the bootloader and those sections that will hold the user application. Example modified procdefs.ld files have been provided with each project. This file is currently named “Procdefs.ld.boot”. When using the example project with the bootloader it is required to remove the “.boot” section of the file. This will allow MPLAB to use this file instead of the default linker file. Once the linker file is renamed, however, the project will no longer work without the bootloader. Please rename the file in order to get the project working again with PIC32.

got that from here >>> http://www.schmalzhaus.com/UBW32/FW...ng the Device - USB Device - Bootloaders.html

So I just have to figure out this Vector remapping and it should work, hopefully.
B. Morse

 

So if you want to skip the bootloader, you can keep that IO pin pulled low and operate as normal. But that does hinder the functionality.

 

So if you want to skip the bootloader, you can keep that IO pin pulled low and operate as normal. But that does hinder the functionality.

The bootloader function is nice to have, since this lets you update your "firmware" via USB without special programming tools. After reading up on using the bootloader, there is a way to use the interrupts.... but it might take some finessing using the vector code they supplied....

In the template file they have a couple of Private Prototypes declared:

void YourHighPriorityISRCode();
void YourLowPriorityISRCode();

and this is where I am supposed to put another goto statement to get to the actual interrupt vector for the ISR's, but it still doesn't work though...

I am going to do some more tinkering with this....

I have a pretty good idea that if I figure out the code below for the pic32, I just might get it working....

/** VECTOR REMAPPING ***********************************************/
#if defined(__18CXX)
    //On PIC18 devices, addresses 0x00, 0x08, and 0x18 are used for
    //the reset, high priority interrupt, and low priority interrupt
    //vectors.  However, the current Microchip USB bootloader 
    //examples are intended to occupy addresses 0x00-0x7FF or
    //0x00-0xFFF depending on which bootloader is used.  Therefore,
    //the bootloader code remaps these vectors to new locations
    //as indicated below.  This remapping is only necessary if you
    //wish to program the hex file generated from this project with
    //the USB bootloader.  If no bootloader is used, edit the
    //usb_config.h file and comment out the following defines:
    //#define PROGRAMMABLE_WITH_USB_HID_BOOTLOADER
    //#define PROGRAMMABLE_WITH_USB_LEGACY_CUSTOM_CLASS_BOOTLOADER
    
    #if defined(PROGRAMMABLE_WITH_USB_HID_BOOTLOADER)
        #define REMAPPED_RESET_VECTOR_ADDRESS            0x1000
        #define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS    0x1008
        #define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS    0x1018
    #elif defined(PROGRAMMABLE_WITH_USB_MCHPUSB_BOOTLOADER)    
        #define REMAPPED_RESET_VECTOR_ADDRESS            0x800
        #define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS    0x808
        #define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS    0x818
    #else    
        #define REMAPPED_RESET_VECTOR_ADDRESS            0x00
        #define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS    0x08
        #define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS    0x18
    #endif
    
    #if defined(PROGRAMMABLE_WITH_USB_HID_BOOTLOADER)||defined(PROGRAMMABLE_WITH_USB_MCHPUSB_BOOTLOADER)
    extern void _startup (void);        // See c018i.c in your C18 compiler dir
    #pragma code REMAPPED_RESET_VECTOR = REMAPPED_RESET_VECTOR_ADDRESS
    void _reset (void)
    {
        _asm goto _startup _endasm
    }
    #endif
    #pragma code REMAPPED_HIGH_INTERRUPT_VECTOR = REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS
    void Remapped_High_ISR (void)
    {
         _asm goto YourHighPriorityISRCode _endasm
    }
    #pragma code REMAPPED_LOW_INTERRUPT_VECTOR = REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS
    void Remapped_Low_ISR (void)
    {
         _asm goto YourLowPriorityISRCode _endasm
    }
    
    #if defined(PROGRAMMABLE_WITH_USB_HID_BOOTLOADER)||defined(PROGRAMMABLE_WITH_USB_MCHPUSB_BOOTLOADER)
    //Note: If this project is built while one of the bootloaders has
    //been defined, but then the output hex file is not programmed with
    //the bootloader, addresses 0x08 and 0x18 would end up programmed with 0xFFFF.
    //As a result, if an actual interrupt was enabled and occured, the PC would jump
    //to 0x08 (or 0x18) and would begin executing "0xFFFF" (unprogrammed space).  This
    //executes as nop instructions, but the PC would eventually reach the REMAPPED_RESET_VECTOR_ADDRESS
    //(0x1000 or 0x800, depending upon bootloader), and would execute the "goto _startup".  This
    //would effective reset the application.
    
    //To fix this situation, we should always deliberately place a 
    //"goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS" at address 0x08, and a
    //"goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS" at address 0x18.  When the output
    //hex file of this project is programmed with the bootloader, these sections do not
    //get bootloaded (as they overlap the bootloader space).  If the output hex file is not
    //programmed using the bootloader, then the below goto instructions do get programmed,
    //and the hex file still works like normal.  The below section is only required to fix this
    //scenario.
    #pragma code HIGH_INTERRUPT_VECTOR = 0x08
    void High_ISR (void)
    {
         _asm goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS _endasm
    }
    #pragma code LOW_INTERRUPT_VECTOR = 0x18
    void Low_ISR (void)
    {
         _asm goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS _endasm
    }
    #endif    //end of "#if defined(PROGRAMMABLE_WITH_USB_HID_BOOTLOADER)||defined(PROGRAMMABLE_WITH_USB_LEGACY_CUSTOM_CLASS_BOOTLOADER)"

    #pragma code
    
    
    //These are your actual interrupt handling routines.
    #pragma interrupt YourHighPriorityISRCode
    void YourHighPriorityISRCode()
    {
        //Check which interrupt flag caused the interrupt.
        //Service the interrupt
        //Clear the interrupt flag
        //Etc.
    
    }    //This return will be a "retfie fast", since this is in a #pragma interrupt section 
    #pragma interruptlow YourHighPriorityISRCode
    void YourLowPriorityISRCode()
    {
        //Check which interrupt flag caused the interrupt.
        //Service the interrupt
        //Clear the interrupt flag
        //Etc.
    
    }    //This return will be a "retfie", since this is in a #pragma interruptlow section 
//end of the PIC18 vector remapping section
#elif defined(__C30__)

#endif

B. Morse

 

I poked around the code last night (seemed like all night!!) still can not get any of the ISR's to fire with interrupts, so I had emailed Brian (The creator of the UBW32) to see if there is a workaround with his code..... at this point I am about to say screw the bootloader, and just use the pickit2 to do all the programming, since I ended up putting header pins on the module for the ICSP last night (I ended up having to reload the original bootloader code after I messed it up poking around with the re-vectored addresses, almost thought I bricked my module last night good thing I got it working again )

so regardless to say, I don't think we need a bootloader if everyone has a pickit2 (As long as you will be using the Pickit2 version 2.61, and the newer device files or else you will spend a couple of hours trying to figure out why the module is code protected and you can not program the pic!!) If you don't have a pickit2/3 then its about time you got one .

So for right now I will just do a polling method on the I/O's to monitor for a Ring signal or for the phone being picked up.... those are the only 2 functions right now that I was going to use interrupts on.... so we will bypass interrupts for now and get on with this thing using the module the way it is so people won't have to modify too much, and I will figure this interrupt issue out later on (Sounds like a whole other project in itself)....

B. Morse

 

I will be using the ISP on the EasyPIC6. I gave a pickit to a friend who wanted to get started in uC programming.

Hopefully Brian has the info on the interrupt problem. That would be nice to not have to worry about tossing the bootloader.

Maybe it is time to put together a BW32 that is interrupt capable. I suppose the bootloader holds the key.

 

I will be using the ISP on the EasyPIC6. I gave a pickit to a friend who wanted to get started in uC programming.

Hopefully Brian has the info on the interrupt problem. That would be nice to not have to worry about tossing the bootloader.

Maybe it is time to put together a BW32 that is interrupt capable. I suppose the bootloader holds the key.

Microchip actually provides the bootloader, I wouldn't be suprised if there are errors in the file stacks and library's they provide a (since they are originally for the C18/24 uc family and was just ported over to pic32), when I used the SD_MMC library, I spent a few days along with some other people trying to get it to work on the pic32 starter kit, we got it figured out but it took days for several people to comb through the lines of code to find the errors and fix them.

I tried polling the RTCC interrupt flag to see if it ever fires, but it never does even after the RTCC toggles the output pin once the "alarm" goes off.... which is a bummer!! So I guess this means "so long Bootloader. til next time!"

B. Morse

 

I did not get any response from the email I sent, (Possible spam filter intervention). But I did get a response (from him??) through Sparkfuns forum..... so we will see what he has to say, maybe it is me, he is going to take a look at my code so far and see what the problem is, he says there should not be an issue with the interrupts on a pic32..... so we will see....

B. Morse

 

In lieu of having issues with the interrupts, I went ahead and started coding anyway, and I will figure out this interrupt thing later on (maybe), So for right now I will be doing the polling method to check my Ring_Detect and Phone_Off_Hook inputs (with a 80Mhz uc, polling I/O's shouldn't be too bad....)


So as an update, here are the physical IO connections to the module from the phone interface circuit....

DTMF Decoder to UBW32 Module

1. DATA0 - RD1
2. DATA1 - RD2
3. DATA2 - RD3
4. DATA3 - RD4
5. DV - RD0

Phone Line to UBW32

1. Ring_Detect - RE8
2. Phone_Off_Hook - RE9
3. Phone_In_Use - RG15

System Relays

1. DTMF Relay - RD12
2. Phone Relay- RD13

The outputs that I have chosen are all 5 volt tolerant pins, so we do not have to worry about interfacing 5 volts to the 3.3 volt inputs on the pic.

These are just the basic inputs and outputs the system will need to function, I will add some LED's also to indicate different system modes, phone ringing, line is use, etc..... (I will update schematics later).

As it is now, I believe a Display, or keypad would be almost useless, since this system is intended to be mounted where the phone line comes into the home and then connects to the existing lines in the house, so a display, or keypad would not be needed, all programming and functions can be done from any phone.

I also think that notifying the user with some audible prompts would also be needed to be implemented, so I have been looking at adding a Chipcorder (I have an ISD2560 on hand) so messages can be programmed into the IC to be used as prompts for the user (the messages can be programmed via external mic / line in or any phone.....)

more later...................

B. Morse

 

Still have not heard from anyone about the interrupts, but good thing I got it working properly, it was an issue with one of the USB CDC libraries from Microchip, but finally past that hurdle ......

Anyways, have a lot of the routines and functions written, doing some more coding this morning with a pot of coffee........ I will post some of the code on here later on with some updated schematics, and possibly pics of the latest prototype....


B. Morse