Jump to content

mikew

EstablishedMember
  • Content Count

    61
  • Joined

  • Last visited

Everything posted by mikew

  1. mikew

    Adc Problem

    After a lot of head-scratching I think I've found the bug that prevents the ADC in the 16F877A from returning the correct value. To cut a very long story short, below is a fragment from the listing file. I notice that in one place ADCON0 is given the address 9F (wrong?) whilst further down it's given 1F (correct?) I admit that I'm not 100% clear on this matter, but it's the only difference I can find between this code and a previous one using an earlier version of compiler for a 16F876. Also, it seems unlikely that such a bug would not have been found earlier by others, or have I missed something? I'm using BoostC Vers. 6.85. Perhaps you could let me know? (BTW, the hex code is as shown in the listing.) 0584 30C7 MOVLW 0xC7 0585 059F ANDWF gbl_adcon0, F <-------------here 0586 3007 MOVLW 0x07 0587 0556 ANDWF gbl_channel, W 0588 00FD MOVWF CompTempVar564 0589 0DFD RLF CompTempVar564, F 058A 0DFD RLF CompTempVar564, F 058B 0D7D RLF CompTempVar564, W 058C 39F8 ANDLW 0xF8 058D 00D6 MOVWF gbl_channel 058E 0856 MOVF gbl_channel, W 058F 049F IORWF gbl_adcon0, F <--------------or here 0590 141F BSF gbl_adcon0,0 <-------------and here 0591 3002 MOVLW 0x02 0592 00FD MOVWF delay_ms_00000_arg_del 0593 2015 CALL delay_ms_00000 0594 151F BSF gbl_adcon0,2 <-------------and here Regards
  2. For the sake of anyone considering this post, an update. I have a test program designed for use with the module I'm using. It's really designed to verify the USB connection but also allows access to some limited features of the '877A, including ADC channels. Using this test program I have determined that the ADC channels work as expected, so the PIC is not pickled!! About the only difference I can find between this tester and my code is that it uses the internal clock for ADC operation. The PIC has a 20MHz clock, which I have used with the 64 divisor. According to the data sheet this should be OK at 20MHz - so what am I doing wrong?? Next step will be to modify my code to use the internal clock and see what happens. Any comments from PIC experts welcome. Regards, Mike W
  3. Thanks for all your help, but I'm still a little confused. I have scoured my Microchip data sheet for the 16F87XA PICs but cannot find any reference to the features you mention over-riding the ADC; can you be a bit more specific? I have ADCON0 and ADCON1 set up correctly; having tried a few variations on the code to read the ADC the only firm conclusion is that only channel 0 is read, that is, reads of channel 1 - 4 all return the same value as channel 0. I'm really beginning to suspect that my PIC is fried! Regards, Mike W
  4. Many thanks for your response. I hadn't realised there could be any conflict with other functions; I'll need to take a closer look at the data sheet. Are you referring to the Compare/Capture function? Regards, Mike W
  5. This is perhaps not directly related to a programming issue, so I have not posted any code. I am using a 16F877A ADC channels; I'm fairly sure I've got all the configuration register set up OK, as much of the code has been 'upgraded' from my previous version run on an '876. My problem seems to be more hardware related; I am using all 5 ADC channels on Port A, leaving the 3 on Port E as digital. As the project progresses, I have only 3 of the channels connected to an analogue source - two are LM335 temp. sensors with calibration pots and the third is a potential divider to a backup battery. The 2 remaining channels presently only have the pots. connected, no temperature sensors, giving about 4.0V at the PIC input. The problem is that each channel returns the same value, more or less, i.e. about 20 deg C as room temperature. I can vary the input voltage to the channel connected to the potential divider over the range 0 - 5V, but the ADC value remains unchanged. I had noticed this effect when I previously had only one channel connected to an analogue source and the rest 'floating' when the unconnected channels gave the same value as the one with a true source. But I did not expect this behaviour when all channels connected to some source. Is my PIC pickled??!! ( I hope not, its a TQFP on an expensive module!) Any suggestions welcome.
  6. I must confess that I've found the FTDI documentation less than helpful. After a lot of experimenting with some startup code, taking the C source supplied with the DLP module as example I discovered a way of getting the FT245 chip to resume reliably (this was before the other problem, and before I decided to re-program the FT245 EEPROM) Asking FTDI for advice on if the approach I had taken was OK their response was - 'we haven't put that information in the documentation because we don't think that method should be necessary'. The documentation, at least that I've found, leaves out a lot of detail; I had expected that forcing a reset of the FT245 would be a solution to re-enumeration; but there is no detail of the reset timing, nor the reset state, and I could not get reproducible results when used. I didn't bother FTDI Chip again, as I get the impression they are only interested in commercial users, which I am not.
  7. Not sure if the previous has given you the answer, but if you are using TMR0 should you not be resetting its interrupt flag? I.e. clear_bit(intcon,TMR0IF); to avoid continuous interrupts.
  8. Many thanks for your suggestions, but after a lot of puzzling I've discovered the 'fault' lies in the source code supplied with the module. I simply used the USB portion and added my own extras. Briefly, the program as given expects that enumeration will only take once and the device will remain connected for the duration. At startup there is a section that is used to purge the FTDI FIFO; re-connecting will not do this, and a false read occurs, returning a garbage value. Fortunately, the read seems to be from a floating bus, and returns a value of 255. Since my program only ever expects buffer size values (the returned value) no greater than 16 I simply reject anything greater and problem solved. Regards, MikeW
  9. I agree, but I have complete control over power selection. The module I am using has a FET controlled by a signal from the FTDI USB chip that is intended to cut power to the external electronics when the USB is in suspend mode. This is what first made me aware that the intention with USB devices is that they are powered down when disconnected from the port. Although you say this should not be necessary, my experience is that enumeration will not take place unless the peripheral is powered down and re-powered on enumeration - thus defeating the object of my design!! I've tried using the PIC to reset the USB interface, hoping this would force a re-enumeration, but the system just 'hangs'. My expectation that all the details of the USB protocol could be ignored by using a dedicated sub-system have proven to be false; no doubt my time now could be better spent swatting up on the very thing I hoped to avoid - arrrrgh!
  10. There seems to be a lot of interest in USB implementation with PICs, so I thought some expert out there may help shed some light. Being put off by the apparent difficulty of implementing USB on a PIC that supports it I decided to try a different approach. It seemed like a good idea to 'offload' all the USB stuff onto a dedicated sub-system and use a (non-USB) PIC with which I am familiar - 16F87X. So I chose to use a DLP Design module that uses an FTDI chip for USB and comes with Win32 drivers, either for DLL's or (my choice) Virtual Com Ports. This module has a 16F877A which I intended to use for the main program. The problem I have now discovered, mainly as a result of my ignorance of USB, is that it seems impossible to re-connect to a USB host correctly once it has been disconnected, but with the PIC still running its program. Hence (at last!) my question; can anyone tell me if my deduction is correct - that once a USB device has been connected to a host and enumeration has taken place, disconnection and then re-connection and consequent re-enumeration requires that any program (running in the PIC) requires a reset/restart? I am wondering if a PIC with USB would allow this problem to be circumvented, although it seems inherent in the USB protocol - that is once a USB connection is made it must be maintained and if lost or removed enforces a complete restart. Apologies for a long post, but I am hoping to avoid wasting any more time and money before pursuing an alternative route.
  11. This sounds like a student project? I agree with the previous post; give a little more information about the hardware and if you have made any progress with programming then it may be possible to make helpful suggestions.
  12. I have been trying to use a structure in BoostC for a PIC 16F876, but without success. In an attempt to get a handle on the cause of the error messages I copied an example from my textbook. This still produces the same error(s), which surprised me, since I obviously expected it to compile correctly. Below is the program: (there is an associated header file with the usual PIC stuff) On building, the error message "missing right paren" for line 28 is generated; line 28 contains update(t) Perhaps some kind PIC C expert can point me in the direction of a solution to my problem? ....................................................................... int buff[8]; //this is/was in the .h file struct tm { int hours; int minutes; int seconds; }; main(void) { struct tm time; time.hours=0; time.minutes=0; time.seconds=0; do { update (&time); display(&time); } while(1); } update(t) { (*t).seconds++; if ((*t).seconds==60) { (*t).seconds=0; (*t).minutes++; } if((*t).minutes==60) { (*t).minutes=0; (*t).hours++; } if((*t).hours==24) { (*t).hours=0; } delay_s(1); } display(t) struct tm *t; { sprintf(buff,"%2d",(*t).hours); sprintf(buff,"%2d",(*t).minutes); sprintf(buff,"%2d",(*t).seconds); }
  13. I've looked at the manual and done a cursory search of forum topics but am unable to answer my own question - is it possible to pass parameters into an ISR? I appreciate that it cannot be passed from the calling routine, since there is none, but I wonder if there is some way in which a parameter may be collected from memory? My hope is to pass a pointer to a struct in order to update it in the ISR. As a poor C programmer I am aware that I am in danger of getting in over my depth!! Any suggestions welcome, but preferably not of the 'forget it, dimmo!' type.
  14. Thanks for your suggestion, zzjoki. I am only able to be guided by the Manual (Ver. 1.28, is there a later version?) which gives 16F87X as suitable targets. Changing the project target from '877A to '877 makes no difference to the error message for this routine, although it does throw up quite a few others that I would not have expected. I think I need to look further into the differences between the two types - I had thought they were more to do with silicon than functionality. Best regards, Mike W.
  15. mikew

    Boostc Ver. 6.84

    I can see that any further input from me would be superfluous! Apologies for not providing the essential bits of info., but it was late and I had spent an hour looking for bugs in my VB 6 code, because I 'knew' the PIC C was OK!! Regards, Mike W PS Any thoughts on the non-appearance of flash_loadbuffer?
  16. mikew

    Boostc Ver. 6.84

    The following fragment is copied from the source. This compiles and works as expected in 6.70 and compiles without error but does not work under 6.84. Displaying the contents of buffer[1] to an LCD (another part of the same code) shows that it contains the sent values, eg 0xA7 etc., but they are all ignored and default is always executed. (BTW, although the comms is via USB from a PC using virtual comm ports, all that is handled by a FTDI FT245 chip, not the PIC) I have reverted to 6.7 and all is now OK, so no urgency on my part!! Over to you.... do { if(!test_bit(porte,1)) //byte received in USB FIFO buffer... { receive_packet(); //collect packets into buffer switch(buffer[1]) { case 0xA7: //set time { day=buffer[2]; hours=buffer[3]; minutes=buffer[4]; break; } case 0xA8: //set hw times { ON_time_hours=buffer[2]; ON_time_mins=buffer[3]; OFF_time_hours=buffer[4]; OFF_time_mins=buffer[5]; break; } case 0xA9: //boiler temp. { Boiler_temp=buffer[2]; break; } case 0xAA: //hysteresis { hysteresis=buffer[2]; break; } case 0xAB: //read 4 temps. { temp1=ADC_Read(0); delay_ms(2); send(temp1); temp1=ADC_Read(1); send(temp1); delay_ms(2); temp1=ADC_Read(2); send(temp1); delay_ms(2); temp1=ADC_Read(3); send(temp1); delay_ms(2); break; } case 0xAC: //set HW return temp { HW_return = buffer[2]; break; } case 0xAD: //set CH return temp { CH_return = buffer[2]; break; } case 0xAE: { for (n=0;n<255;n++) { send(eeprom_read(n)); delay_us(10); } break; } default: //changes to default show buffer[1] content correctly { lcd_goto(40); lcd_puts("ERR "); sprintf(message, "%X", buffer[1]); lcd_puts(message); delay_ms(100); } } } etc......
  17. mikew

    Boostc Ver. 6.84

    do { if(!test_bit(porte,1)) //byte received in USB FIFO buffer... { receive_packet(); //collect packets into buffer switch(buffer[1]) { case 0xA7: //set time { day=buffer[2]; hours=buffer[3]; minutes=buffer[4]; break; } case 0xA8: //set hw times { ON_time_hours=buffer[2]; ON_time_mins=buffer[3]; OFF_time_hours=buffer[4]; OFF_time_mins=buffer[5]; break; } case 0xA9: //boiler temp. { Boiler_temp=buffer[2]; break; } case 0xAA: //hysteresis { hysteresis=buffer[2]; break; } case 0xAB: //read 4 temps. { temp1=ADC_Read(0); delay_ms(2); send(temp1); temp1=ADC_Read(1); send(temp1); delay_ms(2); temp1=ADC_Read(2); send(temp1); delay_ms(2); temp1=ADC_Read(3); send(temp1); delay_ms(2); break; } case 0xAC: //set HW return temp { HW_return = buffer[2]; break; } case 0xAD: //set CH return temp { CH_return = buffer[2]; break; } case 0xAE: { for (n=0;n<255;n++) { send(eeprom_read(n)); delay_us(10); } break; } default: { lcd_goto(40); lcd_puts("ERR "); sprintf(message, "%X", buffer[1]); lcd_puts(message); delay_ms(100); } } }
  18. mikew

    Boostc Ver. 6.84

    Please provide a short example of exactly what you believe is failing, or is difficult for us to help. Regards Dave
  19. I recently changed to BoostC Version 6.84, mainly to see if it would correct the flash_loadbuffer problem. Now I find that a program that was working perfectly well under the previous version fails due to the switch-case not being actioned. I have debugged as far as determining that all the desired switch values are ignored and the program falls into the default case. (The values are to be taken from a buffer and range from 0xA7 to 0xAE ) OR.. What am I doing wrong? (is 6.84 not really out of beta?) Regards.
  20. More for curiosity than anything else I have tried using the flash_loadbuffer routine in a program. Despite including the flash header and the library the compiler reports an 'unknown identifier'. The same response is also produced by the read and write routines. The target PIC is a 16F877A. I am using BoostC Ver. 6.84, recently installed, but the error occurred on my previous version. What am I missing? Is it because I don't have a 'full' licence? Your observations most welcome.
  21. Hi, This may be a digression from what you are seeking, but I wonder if you have considered the DLP Design modules, rather than the straight PIC route to a solution? (www.dlpdesign.com) FYI, they offer a number of modules that use the FTDI chip (www.ftdichip.com) for handling all the USB stuff, and can be used with Virtual Com Port drivers, so that they may easily be driven by a PC from a VB (Visual Basic) program with MSCOMM for the serial link. The module I have used with students for robotics has a 16F877A on board that may be used as is, programmed with a token I/O system, or re-programmed via ICSP to suit your needs. This is the DLP-245PB-G module. There are some minor issues with this system, such as the so-called User Manual from DLP for this module has some mistakes, but otherwise allows a system to be up and running quickly. Regards, Mike W.
  22. Perhaps someone more conversant with the PIC 16F877A may be able to help. I am attempting to port a USB utility program written for the CCS compiler to BoostC, in order that I may extend it into a new project. I have the C source for CCS, but not the actual compiler! The USB part of the problem is not the issue, as this is dealt with by an FTDI chip; the '877A 'simply' has to read and write into its fifo buffer. The translation from CCS is simple enough, but the final result does not work! The problem seems to revolve around two issues; 1. The CCS version includes use of the watchdog timer, seemingly to reset the PIC if the program should hang. I left this out of my version, which is why it doesn't work. To prove the point, I disassembled the CCS ROM code, re-assembled using MPLAB, and hence was able to create a program with the WDT off and, hey presto, the original CCS program ceases to operate, ie no responses to USB writes - but why? I feel there is some arcane feature of the use of the WDT that I have not yet found in the Microchip data. 2. The CCS version uses 2 lines on Port E and B for handshaking and Port D for data transfer. But the startup code sets TrisE bit 4, PSPMODE for Port D, but ignores the assigned handshake lines on Port E for this mode, (Parallel Slave Port). So the question is, why does this work at all? Hopefully if you have read thus far you may still be motivated to suggest some ideas for further research!! ( I have refrained from including wadges of code, but could do so if it helps.) Regards, MikeW
  23. Thanks for that, Dave. In which case it's Hi-Tech that is non-standard, as sprintf produces upper case hex for both x and X......
  24. This apology relates to my query posted in the wrong place! Having spent quite an amount of time looking in the wrong place for the problem arising from porting a fully working Hi-Tech C program, I discover the reason no output was appearing on the LCD was in the line: sprintf(msg,"%2x",io_buf[5]); anyone who has read the manual will notice that 'x' should be 'X' !!! Surely, this is non-standard (ANSI, K&R or whoever) or just another case of RTFM!!!
  25. Thanks for the response, perhaps we could exchange notes - I have no commercial interests, its a personal project. No, the hardware is fine; I've got it rigged up to an ECU from a GM Sonoma. The Hi-Tech code works fine, but it's the almost identical ported SB code that fails to catch the data from the ECU. I'm at a bit of a loss to know where to start the debugging process....
×
×
  • Create New...