Jump to content

trossin

Moderator
  • Content Count

    243
  • Joined

  • Last visited

Everything posted by trossin

  1. There could be two problems: The source boost simulator does not support external interrupts I seem to recall that when you progam a pin to be an external interrupt input, it is no longer an input port pin. The data sheet for the device you are using will give you the answer to #2. If this is the case, you know the state of the pin since you get an interrupt while the button is pushed and not when it is not. The problem is you don't get an interrupt when the button is released so the main code would need to clear flag after it notices that it is set (change led1 = 1; to led1 = 1; flag1 = 0;). Another way to go is to just set up a timer interrupt and read the value of button in the interrupt routine and set flag accordingly. This will also give you a free debounce filter. If you don't want the overhead of the timer interrupt you could also use the interrupt on port B change feature of the PIC processors. I recall that this works in a group of 4 port B pins so if you have other inputs on those lines that you don't want an interrupt for you will get them. The data sheet has more details on this feature than I can remember off the top of my head. It looks like you do have a timer interrupt but you set an external source for the clock which you may not be wiggling during your simulation. You could for the short term set the source to be FOSC (the internal core clock). Sorry for the rambling message.
  2. Thanks Tim! These computer things still entertain me after all these years. I first played with TTL back in 1976 and built my first computer from that PE magazine article using perfboard, wire, solder and lots of luck. It took a month of paper route earnings to pay for all the parts!
  3. I finally moved on from the 16F parts to the 18F parts so I updated my bootloader PC software and wrote a little assembler that is parked at the end of memory to handle downloading code produced by BoostC (with and without interrupt routines). http://www.tedrossin.0sites.net/Electronics/Pic/Pic.html There are links at the top in the Latest News section. The old farts out there may be interested in the COSMAC Elf clone that is mentioned. This uses a 18F4620 to emulate a 1970's vintage microprocessor made by RCA. I'm not sure I could have completed this project without the SourceBoost IDE and ability to create my own plugins. Hence, my strong wish that MPASM assembly level project support get fixed. P.S. I'm close to releasing a new "Cheap Logic Analyzer" using the 18F2620 (5M samples/sec with a trace size of 3936 bytes). This should be available by the weekend so folks can use it during the Holiday season. A 10 MHz crystal is used instead of 20 MHz that the 16F873 used (the 4x PLL is used to clock the 18F2620 at 40 MHz).
  4. Pavel said: "SourceBoost IDE can not debug code built with recent MPASM" I claim that the V6.97 does not work with any version of MPASM. I had no luck with the MPASM 5.2. From the previous reply, I'm pretty sure that is the case since the debugger now uses a different COFF version or slightly tweaked non-standard format. For me, the value of the SourceBoost IDE is the ability to use custom plugins that I can create specific to the problem I'm trying to solve. Sometimes, microcontroller projects require lots of hand tuned assembly or blocks of it. Since the SourceBoost C compilier support for assembly is limited, I and others have to resort to full assembly projects. Going to MPLAB does not give me all the SourceBoost nor my own tools that I have been hooked on. Thanks for others chiming in on this as I thought I was the only one in need of this support.
  5. I broke down and tried the version 5.2 MPASM with SourceBoost version 6.97 but this does not solve the problem for me. I still get the can't load cof file message. This is a deal breaker for me in sending money for Version 7.0 as well as porting my plugins to 7.0. It has been overy 10 months since I reported this basic functionality bug. I have not tried the free version of 7.0 because I don't want my license to get messed up but I would guess that it still does not work. Has anyone tried to assemble and debug an MPASM project this is using 7.0 and a recent version of MPLAB's MPASM? It sure would be nice to get this working.
  6. Do you call Line 2 the 2nd line (1 based) or the 3rd line (0 based) of the display. It could be that you need 0,0 for the first character of the first line. Sorry if this is a stupid response.
  7. This works for version 6.xx of Souceboost. You will need CBLib to get this to compile which is on the same webpage. http://www.tedrossin.0sites.net/Electronic...ameraController
  8. How about while loops for generating blocks of repeated code like MPASM supports? For example, the following code will produce 512 instructions that samples PORTB and loads into RAM at a quick pace (5 Megasamples/second). local i=0; while i<256; movf PORTB,w movwf POSTINC0 i+=1; endw;
  9. It has been 7 months since I submitted this basic functionality bug and there is still no work-around. Is this feature dead? If so, you should remove it from your web site feature list: Also, if this will not be fixed it is a deal breaker for upgrading to version 7.0 for me. I would like to send money when 7.0 is available but I just can't live without simulating assembler projects.
  10. Sorry for the interruption. My webstie moved to: www.tedrossin.0sites.net PIC page with SourceBoost plugins and examples: http://tedrossin.0sites.net/Electronics/Pic/Pic.html Emulating a 1970's COSMAC ELF computer with a couple PICs: http://tedrossin.0sites.net/Electronics/RC...A.html#ElfClone SourceBoost was used to develope the code (it was assembler due to strict timing requirements but I could not have done it without the SourceBoost IDE and plugin support).
  11. Here are two files from my library (http://www.tedrossin.atbhost.net/Electronics/Pic/Pic.html) CBLib.zip that work on 16F parts that have the hardware serial ports hooked up to port C 6 and 7. Just change RS232Init to use different pins if your part is different. It seems that you understand the basics but you just need some simple code to set your baud rate based on you clock frequency. This code just does simple polling with no receive and transmit FIFOs. I hope this helps and does not confuse the issue more. 1. Call RS232Init with your clock frequency and desired baud rate 2. make calls to RS232getch and RS232putch to read and write bytes. Serial.h void RS232Init(unsigned char BaudRate); void RS232putch(unsigned char ByteVal); char RS232getch(void); unsigned char RS232peekch(void); #define RS232_20MHZ_BAUD_115000 10 #define RS232_20MHZ_BAUD_57600 20 #define RS232_20MHZ_BAUD_28800 42 #define RS232_20MHZ_BAUD_19200 64 #define RS232_20MHZ_BAUD_9600 129 #define RS232_16MHZ_BAUD_115000 8 #define RS232_16MHZ_BAUD_57600 16 #define RS232_16MHZ_BAUD_28800 33 #define RS232_16MHZ_BAUD_19200 51 #define RS232_16MHZ_BAUD_9600 103 #define RS232_10MHZ_BAUD_115000 4 #define RS232_10MHZ_BAUD_57600 10 #define RS232_10MHZ_BAUD_28800 21 #define RS232_10MHZ_BAUD_19200 31 #define RS232_10MHZ_BAUD_9600 64 #define RS232_4MHZ_BAUD_115000 1 #define RS232_4MHZ_BAUD_57600 3 #define RS232_4MHZ_BAUD_28800 8 #define RS232_4MHZ_BAUD_19200 12 #define RS232_4MHZ_BAUD_9600 25 serial.c #include <system.h> void RS232putch(unsigned char ByteVal) { while(!(test_bit(pir1,4))); txreg = ByteVal; } unsigned char RS232getch(void) { while(!(test_bit(pir1,5))); clear_bit(pir1,5); return(rcreg); } unsigned char RS232peekch(void) { if(test_bit(pir1,5)) return(1); return(0); } void RS232Init(unsigned char BaudRate) { set_bit(trisc,7); // PORTC[RX] is Input clear_bit(trisc,6); // PORTC[TX] is Output spbrg = BaudRate; // Set baud. see header file txsta = 0x24; // Set TXEN and BRGH to 1 rcsta = 0x90; // Set SPEN and CREN to 1 /* movlw (1<<TXIE)|(1<<RXIE) iorwf PIE1 ; Enable Transmit and receive interrupts */ }
  12. Is there a work-around possible such as putting my entire project in an asm section in main? I seem to recall that the boost assembler/linker has some limitations from having to deal with C code. Maybe there is a way to work around this as well. One of my popular projects (a logic analyzer in a PIC) uses lots of MPASM macro loops. Another (CDP1802 microprocessor emulator) is just a bunch of code but it does require code to be placed in certain locations in memory for it to work. Is it possible to add an option to SourceBoost to deal with direct assembly so that it does not need to be tied to Microchip?
  13. There should be no difference in code generation for putting the variable in the scope of the for loop our outside of it. The only difference is the scoping of the variable at compile time or whether you have one or two variables. { unsigned char a { unsigned char b .. } } The above code will still need to reserve two bytes for storage (I would say on the stack but that is not the case for boost C). And accessing the variables either on a stack or in the heap will require the same code. The only difference is that the compiler will generate an error if b is accessed outside the inner brackets. { unsigned char a { unsigned char b .. } { unsigned char c .. } } Now in the above case, only two bytes need to be reserved for a,b and c since b and c are never in scope at the same time. So in this case memory is saved but again there is no performance benefit.
  14. You could try doing some ugly stuff like this while you are waiting for the compiler to support larger address offsets: // const rom unsigned char Font[96][7]; const rom unsigned char Font0[32][7]; const rom unsigned char Font1[32][7]; const rom unsigned char Font2[32][7]; void DisplayChar(unsigned char Index) { unsigned char FontId,FontIndex; FontId = Index>>5; FontIndex = Index & 0x1f; switch(FontId){ case 0: DoYourThing(Font0[FontIndex]); break; case 1: DoYourThing(Font1[FontIndex]); break; case 2: DoYourThing(Font2[FontIndex]); break; } }
  15. It seems like it would slow down the routine and make it larger if it did a check for zero. Most people hard code the number of digits so it is not a problem and they would not want the slow down or code bloat. You could just do a check outside the routine to solve your problem.
  16. How does the debugger step through the code? I would guess that might help explain what is going on down in the LED helper functions.
  17. x10hosting's move has left my site dead for a month. I moved it here: http://www.tedrossin.atbhost.net/Electronics/Pic/Pic.html You will find free SourceBoost plugins and example code that may be of use in creating solutions using the SourceBoost tools.
  18. Debug and edit mode keep different sets of plugins. When you are in debug mode is when you should select your desired plugins. When you go back to edit mode they will disappear so that you have more space to type.
  19. Any update on when this might get fixed? I just downloaded Version 6.97 Beta and it still is unable to load the cof file. I used this command to create the common object file format file from the object file produced by MPASM: "c:/program files/Microchip/MPASM Suite"/mplink /p 16f877a /o BAsm.cof BAsm.O It produced a .cof and a .hex file.
  20. Assembly code TBLRD*+ in version 6.89 (I can't upgrade due to a previous bug where newer versions do not simulate at all with any version of MPLAB) does not advance the table pointer after the read. Multiple calls return the same value. The code works fine when programmed into a PIC18F4620 but does not simulate correctly. Here is some context. All 4 address variables are loaded with the same table entry in the simulator but in hardware, the code works fine. clrf TBLPTRU; address of the memory block movlw RomImageStart>>8 movwf TBLPTRH movlw RomImageStart & 0xff movwf TBLPTRL TBLRD*+ ; read into TABLAT and increment movf TABLAT, w ; get data movwf AddrHigh TBLRD*+ ; read into TABLAT and increment movf TABLAT, w ; get data movwf AddrLow TBLRD*+ ; read into TABLAT and increment movf TABLAT, w ; get data movwf AddrHighEnd TBLRD*+ ; read into TABLAT and increment movf TABLAT, w ; get data movwf AddrLowEnd
  21. You might get an answer sooner if you provide some information on what is not working as you would expect. Just a post of some code is not a question.
  22. Use software loops and assembler: bsf MY_BIT movlw Delay movf Count Loop: decfsz Count bra Loop bcf MY_BIT Just do the math to figure out what Delay should be for 6 and 14 us based on instrction rate. You also need to turn off interrupts during the delay.
  23. If you are not out of code space and don't mind a little longer execution, why sweat the details? Just write it in C.
  24. Resistors. Use two in series between the 400V source and ground. Take the point between the resistors and send it to the PIC but put a 100 Ohm resistor in series with that. 400V -/\/\/\/--A---\/\/\/\/\---GND At point A-----/\/\/\/\/\----PIC Call the resistor between 400V and point A R1, the resistor between A and GND R2, the resistor between A and the PIC R3. Make R3 100 Ohms to limit current to the PIC clamping diode in case some nut case puts 1KV on the input. To solve for R1 and R2 requires knowledge of what kind of load you can put on the 400V source. I'll assume it can handle 10K Ohms. Our buddy Ohm has a law that states the Voltage = Current * Resistance (V=IR). So at 400V we would like point A to have 5V so the voltage across R2 is 5V. The current is (I=V/R) or V/(R1+R2) or 400/10,000 = 40mA. R1 = V/I = 5/40mA = 125 Ohms. R1+R2 = 10,000 so R1 = 10,000-125 =9875 Ohms. The bummer is that you can't buy these values. The magic ratio you are looking for is 1/80 so R2/(R1+R2) is 1/80. You could use a 100 ohm for R1 and a 8.2K for R2 and get close (1/83). This would make 400V equal 4.82 at the PIC. This is a 4% error that you could get rid of with a lookup table or our friend y=mx+b. I hope this helps.
  25. I would guess the extended instruction set which we were told to disable in the config word.
×
×
  • Create New...