Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by trossin

  1. There could be two problems:


    1. The source boost simulator does not support external interrupts
    2. 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. 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).



    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).

  3. 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.

  4. 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.

  5. 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:

    Compilers/Assemblers supported:



    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.

  6. Sorry for the interruption. My webstie moved to:




    PIC page with SourceBoost plugins and examples:





    Emulating a 1970's COSMAC ELF computer with a couple PICs:




    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).

  7. 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.



    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



    #include <system.h>
    void RS232putch(unsigned char ByteVal)
    txreg = ByteVal;
    unsigned char RS232getch(void)
    unsigned char RS232peekch(void)
    if(test_bit(pir1,5)) return(1);
    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

  8. 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?

  9. 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.

  10. 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;
       case 0:
       case 1:
       case 2:

  11. 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.

  12. 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

  13. 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.

  • Create New...