Jump to content

jimbab

EstablishedMember
  • Content Count

    8
  • Joined

  • Last visited

Everything posted by jimbab

  1. I tried the code with the IDE debugger and the interrupt always works as planned. I understand that the program is to preform an action if a correct code is entered on a matrix keyboard but have some problems understanding what porta.0 and porta.1 are for. The program could be a lot easier to understand and debug if the variables have more explict names like key_count instead of just k. Same goes for things like clear_bit(portb.6);. You can use a # define statement to make the code a lot more readable for anyone. Something like #define open_door clear_bit(portb.6);. A line like open_door; m
  2. Could you let me know what is the target PIC. I assume that in the main function you start out with a call to a function that will do the basic start up setup of the Pic with things like assigning what pins are inputs and outputs. That is where the init lines have to go. If you do not use a function to set up the PIC then the lines should be towards the start of main() before you get into code that the program is doing. The only reason to use an interrupt is to make sure that whatever is happening gets stoped when an event happens (your transition from 0 to 1 on a pin) You will have to
  3. Not sure that all Pic's have it but the ones I have used have RB0 as an interrupt input. It can be programed to trigger either for rising or falling edge (0 to 1 or 1 to 0). The four top bits of PortB can also be used to generate an interrupt on any change on any of them. You cannot select the rising or falling edge on these and have to read them to find out which pin changed. On a 16F84A you can set up the use of the RB0 interrupt by making RB0 an input and using the following lines in an init routine: trisb.0 = 1; // make RB0 an input clear_bit(intcon,I
  4. jimbab

    Ide Bug

    Hi Dave, About an hour before seeing your message I did a complete reinstall of SourceBoost. The problem no longer happens. I am a bit puzzeled as to why the problem was there. Also seeing another message with the same problem seems to indicate that it was not just on my system. I am using Windows 2000 ( build appears to be 5.00.2195) SP4 installed on an AMD Athlon XP2400+ with 512 K ram. ( A French version of Windows 2000) I used Boostc for about a week in the "Free" version before buying the license "Full". During the Free period I cannot recall seeing the problem but n
  5. I have been developing an application that requires reading a small table from EEPROM on a 16F876 and writing it back to another area of EEPROM. I was using the library functions in eeprom.pic.lib. Here is the loop that I use : for (z = 1;z <= 8; z++){ y = eeprom_read(temp_orig); eeprom_write(temp_start,y); temp_orig += 1; temp_start += 1; } With this version I was getting rubish written to the new location. It appeared to be a timing problem and ended up putting in a delay of 15ms just after the call to write. The problem was solved but still seemed as
  6. jimbab

    Ide Bug

    I just installed the package on a portable under XP. The problem does not appear under XP. The Windows 2000 machine has SP4 installed. The IDE is the only program on the machine having this problem. While writing this I have the IDE open. No problem going to the IDE and focus goes to the file in the edit window. Going back to the forum window the the file in the edit window loses focus as normal. Back to the IDE, focus goes back to the file in edit but still no way to do anything in the edit window not even close it. No way in the blocked state to go to the menu or shift focus to the
  7. jimbab

    Ide Bug

    I have a problem with IDE ver 6.35. I have only tested it with BoostC but it may happen with other toolsets. The system used is under Windows 2000. When you start the IDE and it loads in the previous project worked on, use of the "File" "Open" menu function will open the selected file but you can not do anything on the file, not even close it. The menu bar stops functioning also. The work around is to open up a file already in the project by double clicking in the workspace window. This problem does not occure if under Menu "File" one of the previously used files is selecte
  8. Are you using the one wire lib functions or the one wire c and h files from the sample programs ? I have just started doing a lot of programming for a number of one wire device types (ibutton,temperature, GPI) and ran into timing problems with both the lib and c+h files. Not much to do concerning the lib but at least you can modify the c file to adjust. If you look in the sample file you will find a lot of "nop" to adjust both read and write timing on the one wire bus. If it is correct for a 20Mhz clock it will not be for a 4Mz. Best thing to try is to have a look at the data shee
×
×
  • Create New...