Jump to content

mityeltu

EstablishedMember
  • Content Count

    95
  • Joined

  • Last visited

Everything posted by mityeltu

  1. I have not seen any new product for win7 win8 from this group. Is sourceboost dead? Should I start looking for a new compiler/ide for the future?
  2. I am in the middle of implementing a circuit that uses multiple switched inputs. What I need/want to know is if there is a better way to debounce and verify switch position. The following is a skeleton of what I am doing with each switch input: if porta0 is high then wait 50mS if porta0 is still high do a bunch of stuff end if end if The point of the nested if's is to make sure that the first input was a 'real' input and not just abarrent noise or something. Is there a better way to check for the validity of a switch input or button press? Thanks for the help.
  3. UPDATE: The problem is not with SourceBoost. I have purchased an older (much older) and considerably slower laptop running windows xp in order to program some older equipment whose software will not run on the new 64-bit machines or under windows 7. I decided to test BoostC on this machine using the same program that took so long to compile previously. No changes were made to the program and no changes were made to the default operating systems load profile. BoostC compiled the program in just under 6 seconds. That is a VAST improvement over the several minutes under microshaft's win7. To the originators of BoostC: Please look into this and see if there is a way to optimize Boost for win7 to improve compile times. I don't know why it is so slow on the new win7 laptop, but it is truly unacceptably slow there and altogether faster on win xp. There must be something to that. Anyway, I am glad to know I can start using BoostC again for my Pics.
  4. OK. That worked, albeit still very slow. I turned off the antivirus on both machines and it sped up the compile by about 8%. Not much improvement considering the size of the file. Your software is my choice to use, but it is simply unusably slow on my laptop - which makes no sense whatsoever. My laptop is faster than my desktop, yet with this software, the compile time is still increased by almost a factor of 5. I still say this makes no sense. I will simply have to wait till Sourceboost improves or switch compilers and spend another small fortune (for me) to get one that works on this machine. I sincerely appreciate your replies and the help in getting the buildserver working. It is genuinely kind of you. You have my gratitude, but I am going to put sourceboost away until the next major revision and hope that the speed is improved. kindest regards.
  5. I installed 7.22 and received the following error: Building... "C:\Program Files (x86)\SourceBoost\boostc_pic18.exe" music.c -t PIC18F452 -idx 1 -pp localhost:5584 -obj Debug -d _DEBUG error: unsupported toolchain error: remote build failed BoostC Optimizing C Compiler Version 7.22 (for PIC18 architecture) http://www.sourceboost.com Copyright© 2004-2014 Pavel Baranov Copyright© 2004-2014 David Hobday Single user Lite License (Unregistered) for 0 node(s) Limitations: PIC18 max code size:8192 bytes, max RAM banks:2, Non commercial use only music.c BoostBuild Client Version 7.21 http://www.sourceboost.com Copyright© 2010-2014 Pavel Baranov Copyright© 2010-2014 David Hobday connecting to server connection established requesting server info server info received done failure error: failed Done Not only did it not work, it is now unregistered.... again. Is there not an EASY way to gt this thing to work?
  6. It apparently connects, but I am getting the following output: Building... "C:\Program Files (x86)\SourceBoost\boostc++_pic18.exe" 18F452.cpp -t PIC18F452 -idx 1 -pp localhost:5584 -obj Debug -d _DEBUG error: unsupported toolchain error: remote build failed BoostC++ Optimizing C++ Compiler Version 7.21 (for PIC18 architecture) http://www.sourceboost.com Copyright© 2004-2013 Pavel Baranov Copyright© 2004-2013 David Hobday Licensed to ------------- under Single user Pro License for 1 node(s) Limitations: PIC18 max code size:Unlimited, max RAM banks:Unlimited 18F452.cpp BoostBuild Client Version 7.22.1 http://www.sourceboost.com Copyright© 2010-2014 Pavel Baranov Copyright© 2010-2014 David Hobday connecting to server connection established requesting server info server info received done failure error: failed Done Is there something I need to change or do to the port settings to make it work right?
  7. Well, I'm going to try this one more time and then I'm abandoning sourceboost. I need help setting up this buildserver. I tried opening the port (5584) for both inboard and outboard on both machines. I added the -pp localhost:5584 line to the compiler options, but it won't connect. I have no idea what I'm really doing with this. I'm not an expert, or even a novice, when it comes to pc communications stuff. Is there anyone who can walk me through this? I have windows7 and the compiler runs amazing slow on my laptop. If I can't find a way to speed this up, I'm gong to have to give up on it and go with MikroC or something. I don't want to do that, but this thing is running too low to be of any use. 5 minutes to build a 1.5k program is way over the top. If anyone can help me, I would be very appreciative. thanks.
  8. Well, I tried to use the remote build server, but can't get it to work. The ports are open on both computers, as far as I can tell. I have added the -pp localhost:5584 to the build command and I get the error that the server has rejected the connection. I really don't understand this server stuff. Is there not some good reason why my laptop runs this program slower than my desktop? I mean, the desktop has less ram and a slower processor. This laptop should be flying through all this. I just don't get it. I had an old - I mean really old - laptop that was till running xp and it makes this new laptop seem like a dinosaur in terms of build time. I just don't understand that.
  9. I know this is an old topic, but I just bought a new laptop for mobile compiling of the sourceboost programs. The laptop is an Intel Core i7 2nd Gen. 2670QM, 8GB ram. This thin is faster than my desktop. My program that I just compiled on the DESKTOP took all of 23 seconds. On the laptop it too 307 seconds. You guys out there are alot smarter than me, so can anyone tell me how in the world to speed this thing up? This is unbearably slow. The program is only 1.5k for crying out loud. There MUST be some kind of solution to this. Any ideas?
  10. OK. I have banged on this for many hours, but I finally have not only a working master and slave, but I have them talking back and forth to one another. I could not find a decent example that didn't use a bunch of built in routines that don't let me know what's really going on. SO. Below are the codes for the master and slave along with the hex files and the schematic I used to make this work. The CPP files can be copies directly into a stand alone project and should compile withouit any trouble. I hope this helps someone else struggling to learn how SPI works. 18F4520-SPI-Master.cpp 18F4520-SPI-Slave.cpp SPI-Schematic-Working.pdf 18F4520-SPI-Master.hex.txt 18F4520-SPI-Slave.hex.txt
  11. Allright, well I took out the delays and replaced them with timer 3 interrupt routines and now it neither sends nor receives. Timer 3 is using 1:8 prescaler and an interrupt count of 5 giving me about the same delay as the delay_ms() routnes. Any other ideas?
  12. davidb, I appreciate the guidance. I'll attempt to implement these ideas this week. I disable the interrupts to prevent additional interrupts from occurring while in the ISR. I guess from your post this is superfluous. I didn't realize this. I will change that today. The reason for the massive delays is that it would not operate without them. I originally had very short delays (20uS), but the slave would only pickup about every 10th or 15th transmission. Once I added the delays, it began only missing a few. Then with these massive delays it misses about 1 or 2 out of 100. As to the interrupts, I am trying to keep the runtime out of interrupt as much as possible, I see your point on scanning as opposed to interrupt though. I also didn't know the delays were blocking. I assume you mean they block the interrupts the firware is looking for. I don't understand what you mean by the following: I'll modify the ISR to read directly and remove the delays. A possible problem is that the timer may interrupt in the middle of my spi transmission. Will that not cause a dropped byte or possible bus collision or overflow?
  13. OK, well, dead silence again. Well, I modified my code to remove most of the fluff and just bit bang the whole thing out and managed to fix everything (almost). All this does now is decrement port B on the master and send the updated port B value to the slave to display on the slave's port B - not exactly glamorous, but I'm juet trying to figure this out right now. Apparently my bit timing was off. I added a longer delay between the slave selct bit going low before loading the sspbuf register. I also discovered that one of my 20MHz resonators had died and was no longer timing anywhere near 20MHz. I had to switch to 16MHz resonators since I didn't have a replacement. The master slave are now communicating regularly, but the slave still drops about 1 out of every 100 messages. Is there something that someone can recomment in either hardware or firmware that might account for the 1-2% dropped bytes? I really want to get this to work 100%, but I don;t know what else to try. Any suggestion will be appreciated. The code follows: Master Code: #include <system.h> /* SPI Master 18F452 16MHz resonator */ #pragma DATA _CONFIG1H, _HS_OSC & _OSCS_OFF_1H #pragma DATA _CONFIG2L, _PWRT_OFF_2L & _BOR_OFF_2L #pragma DATA _CONFIG2H, _WDT_OFF_2H #pragma DATA _CONFIG3H, _CCP2MX_OFF #pragma DATA _CONFIG4L, _LVP_OFF_4L & _DEBUG_OFF_4L #pragma DATA _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L & _CP3_OFF_5L #pragma DATA _CONFIG5H, _CPB_OFF_5H #pragma DATA _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L & _WRT2_OFF_6L & _WRT3_OFF_6L #pragma DATA _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H #pragma DATA _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L & _EBTR2_OFF_7L & _EBTR3_OFF_7L #pragma DATA _CONFIG7H, _EBTRB_OFF_7H void interrupt(void); void setup(void); //Global Variables char flags, int_cnt; void main() { osccon = 0x00; setup(); while(1) { delay_ms(50); int_cnt++; if (int_cnt == 1) { if(test_bit(porta,5)) { clear_bit(porta,5); } else { set_bit(porta,5); } set_bit(flags,1); portb --; } if (test_bit(flags,1)) { delay_ms(200); clear_bit(portd,0); delay_ms(200); set_bit(portd,0); delay_ms(200); clear_bit(portd,0); delay_ms(200); clear_bit(flags,1); clear_bit(pir1,3); // clear spi flag clear_bit(portd,1); // select slave delay_ms(255); sspbuf = portb; // send byte while (!test_bit(pir1,3)) {} // wait till send complete delay_ms(255); set_bit(portd,1); delay_ms(200); set_bit(portd,0); delay_ms(200); clear_bit(portd,0); delay_ms(200); int_cnt = 0x00; } } } void interrupt() { } void setup() { portd = 0x00; portc = 0x00; intcon = 0x00; intcon2 = 0x00; // interrupt on rising edge, pull ups enabled intcon3 = 0x00; // int1, int2 enabled ccp1con = 0x00; // capture/compare off sspcon1 = 0x00; // spi/i2c off adcon0 = 0x00; // a/d off adcon1 = 0x06; // digital io trisa = 0x0f; // high nibble = output, low nibble = input trisb = 0x00; trisc = 0x00; trisd = 0x00; // d1 = slave select pin trise = 0x07; portb = 0x00; portc = 0x00; portd = 0x00; flags = 0x00; int_cnt = 0x00; // SPI Configuration set_bit(portd,1); // slave select is active low sspcon1 = 0x20; // spi enabled, master mode, fosc/64 sspstat = 0x40; // data sampled in middle, tx on rosing edge trisc = 0x10; // set per book page 216 portc = 0x00; clear_bit(trisd,0); // slave select pin clear_bit(rcon,7); //disabled int priority } Slave Code: #include <system.h> /* 18F452 16MHz resonator */ #pragma DATA _CONFIG1H, _HS_OSC & _OSCS_OFF_1H #pragma DATA _CONFIG2L, _PWRT_OFF_2L & _BOR_OFF_2L #pragma DATA _CONFIG2H, _WDT_OFF_2H #pragma DATA _CONFIG3H, _CCP2MX_OFF #pragma DATA _CONFIG4L, _LVP_OFF_4L & _DEBUG_OFF_4L #pragma DATA _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L & _CP3_OFF_5L #pragma DATA _CONFIG5H, _CPB_OFF_5H #pragma DATA _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L & _WRT2_OFF_6L & _WRT3_OFF_6L #pragma DATA _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H #pragma DATA _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L & _EBTR2_OFF_7L & _EBTR3_OFF_7L #pragma DATA _CONFIG7H, _EBTRB_OFF_7H void interrupt(void); void setup(void); //Global Variables char flags; unsigned char ssp_dat; void main() { osccon = 0x00; setup(); while(1) { if(test_bit(flags,0)) // data received { ssp_dat = sspbuf; clear_bit(pir1,3); portb = ssp_dat; clear_bit(flags,0); clear_bit(sspcon1,7); clear_bit(sspstat,0); clear_bit(sspcon1,6); set_bit(portd,1); delay_ms(100); clear_bit(portd,1); delay_ms(100); set_bit(portd,1); delay_ms(100); clear_bit(portd,1); delay_ms(100); } } } void interrupt() { clear_bit(intcon,7); clear_bit(intcon,6); if (test_bit(pir1,3)) // spi int flag { clear_bit(pir1,3); set_bit(flags,0); } set_bit(intcon,6); set_bit(intcon,7); } void setup() { portb = 0x00; portc = 0x00; portd = 0x00; porte = 0x00; intcon = 0x00; // ints disabled intcon2 = 0x00; // pull ups enabled intcon3 = 0x00; // int disabled ccp1con = 0x00; // capture/compare off adcon0 = 0x00; // a/d off adcon1 = 0x06; // all digital io trisa = 0xff; // trisa5 must be input for slave select bit trisb = 0x00; trisc = 0x18; // set spi io and clk pins page 216 trisd = 0x00; trise = 0x07; flags = 0x00; //set spi for slave sspcon1 = 0x24; // spi enabled, slve mode sspstat = 0x40; // tx on rising edge set_bit(intcon,6); set_bit(intcon,7); set_bit(rcon,7); // priority level int enabled set_bit(ipr1,3); // spi int high priority set_bit(pie1,3); // spi int enabled }
  14. I gave up on the I2C com for a while and started tinkering with SPI istead. Figured if I can get the simpler one to work, I'll be able to get the harder one later. The master program has a heartbeat on timer0 and periodically gets an a/d conversion on AN0. I convert this to a single byte and transmit this to my slave which then displays the byte on port b leds. Both master and slave are 18F452, master sdi to slave sdo, master sdi to slave sdo, sck connected together. 20MHz resonator for clock source, sck set for Fosc/64 (just to make sure I'm not overclocking the slave). The wierd part is that it works... sometimes. The a/d conversion works every time. My scope is not good enough to show everything going on, but the fact that it works aperiodically just doesn't make sense. I moved my sdi/sdo lines as far away from the resonators as possible (approximately 1 inch) and the sck line away from the sdi/sdo lines by about an inch. I just don't know if this is a hardware or firmware problem. Coupld one of you with alot more expoerience please check my code to see if it SHOULD be working correctly? I'd really appreciate it. Thank you. Here's the master code: #include <system.h> /* SPI Master 18F452 20MHz resonator */ #pragma DATA _CONFIG1H, _HS_OSC & _OSCS_OFF_1H #pragma DATA _CONFIG2L, _PWRT_OFF_2L & _BOR_OFF_2L #pragma DATA _CONFIG2H, _WDT_OFF_2H #pragma DATA _CONFIG3H, _CCP2MX_OFF #pragma DATA _CONFIG4L, _LVP_OFF_4L & _DEBUG_OFF_4L #pragma DATA _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L & _CP3_OFF_5L #pragma DATA _CONFIG5H, _CPB_OFF_5H #pragma DATA _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L & _WRT2_OFF_6L & _WRT3_OFF_6L #pragma DATA _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H #pragma DATA _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L & _EBTR2_OFF_7L & _EBTR3_OFF_7L #pragma DATA _CONFIG7H, _EBTRB_OFF_7H void interrupt(void); void setup(void); //Global Variables char flags, int_cnt; short adr; void main() { setup(); while(1) { if (test_bit(flags,0)) // tmr0 int -> heart beat { clear_bit(flags,0); if (test_bit(porta,5)) { clear_bit(porta,5); tmr0h = 0xe0; tmr0l = 0x00; } else { set_bit(porta,5); } if (int_cnt == 50) { set_bit(adcon0,2); // start a/d int_cnt = 0; } } if (test_bit(flags,1)) // a/d int { delay_ms(255); clear_bit(portd,0); delay_ms(255); set_bit(portd,0); delay_ms(255); clear_bit(portd,0); delay_ms(255); clear_bit(flags,1); MAKESHORT (adr, adresl, adresh); adr = adr/256; portb = adr; clear_bit(pir1,3); // clear spi flag set_bit(portd,1); // select slave delay_us(20); clear_bit(pie1,6); // disable a/d int sspbuf = adr; // send byte while (!test_bit(pir1,3)) {} // wait till send complete clear_bit(portd,1); clear_bit(pir1,6); // clear a/d int flag set_bit(pie1,6); // re enable a/d int delay_ms(255); set_bit(portd,0); delay_ms(255); clear_bit(portd,0); delay_ms(255); } } } void interrupt() { clear_bit(intcon,7); clear_bit(intcon,6); if (test_bit(intcon,2)) // tmr0 int { clear_bit(intcon,2); set_bit(flags,0); int_cnt++; } if (test_bit(pir1,6)) // a/d int { clear_bit(pir1,6); set_bit(flags,1); set_bit(portd,0); } set_bit(intcon,7); set_bit(intcon,6); } void setup() { portd = 0x00; portc = 0x00; intcon = 0xe0; // tmr0 int enabled, intcon2 = 0x80; // interrupt on rising edge, pull ups disabled intcon3 = 0x00; // int1, int2 enabled ccp1con = 0x00; // capture/compare off sspcon1 = 0x00; // spi/i2c off adcon0 = 0x01; // a/d on, channel 0 adcon1 = 0x0e; // only an0 analog set_bit(pie1,6); // a/d int enabled trisa = 0x0f; // high nibble = output, low nibble = input trisb = 0x00; trisc = 0x00; trisd = 0x00; // d0 = slave select pin trise = 0x07; portb = 0x00; portc = 0x00; portd = 0x00; t0con = 0x82; // tmr0 on, 16bit, 1:256 prescaler flags = 0x00; int_cnt = 0x00; adr = 0; // SPI Configuration sspcon1 = 0x22; // spi enabled, master mode, fosc/64 sspstat = 0x40; // data sampled in middle, tx on rosing edge trisc = 0x10; // set per book page 216 portc = 0x00; clear_bit(trisd,0); // slave select pin clear_bit(rcon,7); //disabled int priority } Slave code: #include <system.h> #pragma DATA _CONFIG1H, _HS_OSC & _OSCS_OFF_1H #pragma DATA _CONFIG2L, _PWRT_OFF_2L & _BOR_OFF_2L #pragma DATA _CONFIG2H, _WDT_OFF_2H #pragma DATA _CONFIG3H, _CCP2MX_OFF #pragma DATA _CONFIG4L, _LVP_OFF_4L & _DEBUG_OFF_4L #pragma DATA _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L & _CP3_OFF_5L #pragma DATA _CONFIG5H, _CPB_OFF_5H #pragma DATA _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L & _WRT2_OFF_6L & _WRT3_OFF_6L #pragma DATA _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H #pragma DATA _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L & _EBTR2_OFF_7L & _EBTR3_OFF_7L #pragma DATA _CONFIG7H, _EBTRB_OFF_7H void interrupt(void); void setup(void); //Global Variables char flags; unsigned char ssp_dat; void main() { setup(); while(1) { if(test_bit(flags,0)) // data received { ssp_dat = sspbuf; clear_bit(pir1,3); portb = ssp_dat; clear_bit(flags,0); } } } void interrupt() { clear_bit(intcon,7); clear_bit(intcon,6); if (test_bit(pir1,3)) // spi int flag { clear_bit(pir1,3); set_bit(flags,0); } set_bit(intcon,6); set_bit(intcon,7); } void setup() { portb = 0x00; portc = 0x00; portd = 0x00; porte = 0x00; intcon = 0x00; // ints disabled intcon2 = 0x80; // pull ups disabled intcon3 = 0x00; // int disabled ccp1con = 0x00; // capture/compare off adcon0 = 0x00; // a/d off adcon1 = 0x06; // all digital io trisa = 0xff; // trisa5 must be input for slave select bit trisb = 0x00; trisc = 0x18; // set spi io and clk pins page 216 trisd = 0x00; trise = 0x07; flags = 0x00; //set spi for slave sspcon1 = 0x24; // spi enabled, slve mode sspstat = 0x40; // tx on rising edge set_bit(intcon,6); set_bit(intcon,7); clear_bit(rcon,7); // priority level int disabled set_bit(pie1,3); // spi int enabled }
  15. My apologies. Thank you for the assistance.
  16. I may have found the problem. I know it's been a really long time. I gave up on this microcontroller stuff for a long time because my circuits either didn't work or worked strangely. That is, they would exhibit this same strange behavior on an aperiodic basis. I could never reproduce it, but it would happen for no apparent reason. I think the reason in my power supply. I use a small 5v 3A power supply I boulght from mouser. Plent of power for all my apps. I notiiced this strange behavior again and tried to diagnose it. In the past, the real problems have been with motors and other switching devices (such as the ping sensor above). I tried looking on a scope, but didn't find anything. Still a little odd, but placing a .1uf cap across my power supply fixed my issues. I don't have a complete resaon why, but the fact that it stopped immediately after I plcaed the cap and hasn't done it again since, tells me that was the problem. I hope this helps someone else.
  17. Should I take this silence as a statement that no one knows what this program is doing or how i2c really works? I know all this stuff is magic and if you let the magic smoke out it won't work at all, but ....
  18. I am attempting my first I2C master/slave program. I have read almost everything I can find to help, but I'm confused on something (well, really many things, but I'll just start with this). I have been reading the master/slave example on the sourceboost example downloads ( http://www.sourceboost.com/Products/BoostC/ExampleCode.html ) I have read the .h files and understand, I think, what's going on. What I don't get is the internal address of the slave 16f877. The code I am referring to is this: //////////////////////////////////////////////////////////////////////////// // Write to the External 16F877A device //////////////////////////////////////////////////////////////////////////// // s is a pointer to the string to be written to the EEPROM // HW_address is the hardware address of the i2c device // ic2_addr is the target internal address within the External device // count is the number of bytes to be written starting at i2c_addr void write_XFF(char *s, char HW_address, unsigned short i2c_addr, unsigned short count) { short i; HW_address <<= 0x01; // Shift the 7-bit address Left by 1 HW_address &= 0xFE; // LSB = 0 for address/data write operation i2c_start(); i2c_write(HW_address); // send XFF i2c address i2c_write(i2c_addr >> 8); // send XFF internal HIGH address i2c_write((char) i2c_addr & 0x00ff); // send XFF internal LOW address // XFF write loop for (i=0;i<count;i++) i2c_write(*s++); i2c_stop(); } What is meant by the "the internal address of the External device"? When I read/write to the slave 16f877 am I writing to an EEPROM address? I would rather learn to use the registers first so that I can understand what the boostc library is doing, but I haven't found a simple master/slave program that I could understand. If anyone knows of a reall really simple example that actually works, I would love to see it.
  19. Well, the library looks promissing. I'll give it a try. I have never found an example I could really understand. The problem is that most examples dump way too much information but not any explanation. I have this HID demo that has 15 executables in it, but not one bit of information that tells me what any of them are for or what they do. I have no idea which one is for the PIC and which one for the PC. Other times, the files won't compile for some reason and I can't get anything to actually run. It's frustrating, and I don't really expect this to be any different, but I'll still give it a shot. Thanks for the info.
  20. I appreciate that. I have never tried to build any plugins, and I have never managed to get the simulator to do much of anything but get locked in my loop. I use Oshonsoft for my simulator. As far as USB is concerned, I have never managed to get any of the available HID development tools to waork at all. I have tried to generate my own descriptors, but failed miserably. None of tyhe examples I have ever seen were detailed enough for me to be able to understand what to do with them. I'm an electrical guy and sometimes all the code stuff is above my head, especially when it comes to interfacing with the PC. I have written many VB PC applications, but nothing that ever interfaced with external devices beyond the keyboard. I've looked at Lang's example before and could not get it to work. Either the code would not compile on the PC or it would not compile in BoostC. It was too complex for me, frankly. For USB, all I ever wanted was to see if I could get it to work, and nothing I ever did made any sense to me and hence never worked. I all but gave up on USB. I tend to learn more through example.
  21. I appreciate the well-tought-out response and the honesty. I was unaware of the obsolescence of C18. I have recently started attempting USB support for some of my projects. My little exposure has been difficult and unproductive. I recently found an engineering design white paper on a simple USB project using C18, hence my interest. I'll certainly take it under advisement. I also only recently looked at the costs. I have the BoostC++ Pro license, and I don't know that I could foot the $600 for the C18 license alone. Anyway, thank you for the thought-provoking response.
  22. Ok. First, I purchased the Sourceboost C++ license, so I do know something about it. I also know that it is missing a number of very useful function libraries. There is, for instance, no support for trig functions. These are needed for some of the things I do, and I have to do it brute force using BoostC. So. For those who have tried both, why should I stay with BoostC++? I have NOT used C18... yet. I plan on installing it this weekend to test it, but I am familiar with BoostC, and while it has many limitations that I don't like, I am, as I said, familiar with it.
  23. The time between pulses is determined by a button on pin D0. The only time I should be getting the signal to the sensor is after the button is released. Oscilloscop confirms I am getting flat 5.2v. No dips dring button operation. unable to monitor puse using scope, but have ultrasonic sound frequency devider and am able to hear it audibly. Echo produces input as expected on pin B0 after pulse is initiated. However, when the mcu is behaving erratically, I am getting multiple spurrious signals and echoes with no detectable change in source voltage. Note, I never have to push the button to cause a firing of the PING sensor. When the PING is firing, I am getting the start signal from the mcu, that is I am able to detect the high output that "appears" to correspond to the led on the PING sensor lighting. It's so fast at tims I am unable to be certain, but either way, there is a signal from the mcu and the PING fires as it is supposed to.
  24. I have a problem that I cannot seem to fix. Granted, I think this is more of a physical issue rather than a programming issue, but who better to ask than a bunch of people who use these things on a regular basis. Here's what happens. After applying 5.5v batery power to the circuit, which consists of the mcu, a button, a PING ultrasonic sensor and 3 leds I get superfluous signals to the PING unit. There is a little light on it that lets me know when it is firing and the thing flickers for a while then stops. If I touch the mcu, it flickers. SDomtimes if I move my hand too close, it flickers. I have checked vdd and vss for problems - nothing there. I have checked all connections and found nothing inconsistent. Any thoughts on what is causing this issue? My code is here: #include <system.h> #include <eeprom.h> #pragma DATA _CONFIG1, _INTOSCIO & _WDT_OFF & _PWRTE_OFF & _MCLRE_ON & _CP_OFF & _CPD_OFF & _BOR_OFF & _IESO_OFF & _FCMEN_ON & _LVP_OFF & _DEBUG_OFF #pragma DATA _CONFIG2, _BOR21V & _WRT_OFF /* This program written for PIC16F887 with internal 8MHz clock portb will be used to change pwm value port b0 will increase the pwm dc, portb1 will decrease the dc portd.0 is ultrasonic input and output */ void setup(void); void interrupt(void); void pulse(void); char flag; short echo; char pb; // this variable is only for IOC void main() { setup(); while(1) { if (test_bit(portd,0)) { delay_ms(20); while (test_bit(portd,0)) {} pulse(); } } }/////////////////////////////////////////////////////////////////////////END MAIN void pulse() { /* This section uses the Parallax PING sensor This module utikizes a single pin for start pulse and timing pulse a 5 us pulse is used to start the ping process. There is a delay of between 500 and 750 us to allow setting the port for input and timing. Timer 1 is used for timing of the pulse portb must be read in order to keep the interrupt from always being set */ tmr1h = 0x00; tmr1l = 0x00; clear_bit(iocb,0); // clear ioc flag clear_bit(intcon,1); // clear ext int flag clear_bit(intcon,0); // make sure ioc b0 flag is not already set clear_bit(trisb,0); // set b0 for output set_bit(portb,0); delay_us(5); // starts timing delay clear_bit(portb,0); pb = portb; clear_bit(iocb,0); // clear ioc flag clear_bit(intcon,1); // clear ext int flag set_bit(trisb,0); // rest b0 for input set_bit(iocb,0); // set portb,0 as int on change }//////////////////////////////////////////////////////////////////////////END PULSE void setup() { osccon = 0x71; // internal 8MHz clear_bit(intcon,0); intcon = 0xc8; // ioc en trisa = 0x00; trisb = 0xff; trisc = 0x00; trisd = 0xff; trise = 0x00; porta = 0x00; portc = 0x00; portd = 0x00; porte = 0x00; ansel = 0x00; // porta digital anselh = 0x00; // portb digital adcon0 = 0x00; // a/d off tmr1h = 0x00; tmr1l = 0x00; t1con = 0x00; flag = 0x00; }/////////////////////////////////////////////////////////////////////////END SETUP void interrupt() { clear_bit(intcon,7); clear_bit(intcon,6); if (test_bit(intcon,0)) // ioc b { clear_bit(intcon,0); if (test_bit(flag,0)) { clear_bit(t1con,0); pb = portb; clear_bit(porte,0); clear_bit(flag,0); eeprom_write(0x00, tmr1h); delay_ms(20); eeprom_write(0x01, tmr1l); MAKESHORT(echo,tmr1l,tmr1h); } else { pb = portb; set_bit(porte,0); set_bit(flag,0); set_bit(t1con,0); } } clear_bit(intcon,0); set_bit(intcon,7); set_bit(intcon,6); }/////////////////////////////////////////////////////////////////////END INTERRUPT
  25. I have the attached program that calculates the value of the hypotenuse given values of 'a' and 'b' as modified by the user. I need to do some other things with the chip, but this program takes up almost the entire chip's (16f887) memory : 93.9% ROM, 81.3% RAM. Is there anything I can do to further shrink this so I can have some breathing room? I know the float instructions are the problem, but I don't see any other way to accomplish the calculation without the procedures as I have written them. Any help will be greatly appreciated. Thanks. Pythagorean.zip
×
×
  • Create New...