Jump to content

trossin

Moderator
  • Content Count

    243
  • Joined

  • Last visited

Posts posted by trossin


  1. Could it be that you have some unused inputs to your PIC "floating in the wind" and acting like antennas? Make sure that all unused pins are programmed up as outputs or connect them to ground. Maybe your switch is connected to an input so that when the button is pressed the input is grounded but when it is not it is just floating? Make sure you have a 1K to 47K resister to VDD on your D0 pin.


  2. I updated a couple of my plugins for version 7 (Plugin version 3). One is a 4 channel PWM monitor and the other is one to capture all the wiggles on the pins into a value change dump (VCD) so that the signals can be displayed in a standard simulator waveform viewer. I also have a free waveform viewer or you can use the free gtkwave viewer.

     

    You can find the plugins for version 6 and 7 here:

     

    http://www.tedrossin.0sites.net/Electronics/Pic/Pic.html

     

    Don't forget to check out the picture of my ducks down in the Duck House Controller project.

     

    My most intense plugin can be seen in this project which shows how I coded up an antique microprocessor (CDP1802) into a 18F4620 and am able to emulate another antique part (CDP1861) video chip in the plugin which issues DMA requests to the 1802 to get video data. The plugin implements all the timing that the video chip does and displays the image that would show up on a monitor. Timing has to be perfect for this thing to work.

     

    http://www.tedrossin.0sites.net/Electronics/RCA/RCA.html#ElfClone

     

    If you click on the image on the right you can see the plugin displaying video in 64x64 pixel mode (2nd highest resolution [it was the 70's after all]). The image in the center is the prototype hardware working in real life. The image on the left is the final version with the 1802 and 1861 emulated by two different PICs.

     

    I could not have done this project without SourceBoost and the ability to create my own plugins. Well, maybe, but it would have taken a long time and been quite painful to track down all the problems using a logic analyzer.

     

    It is well worth the effort to learn how to create your own plugins. I use Visual C++ 6.0 to write plugins. Someone asked about using the free version of Visual C++ but I'll admit I have not tried it.


  3. I upgraded to version 7.05 and my assembler project no longer assembles because I get a series of error messages from MPASM:

     

    Error in parameter "18F4620_g.lkr".

    Illegal source file name "Release\B7_1802_18F.O".

    Unrecognized error: 32.

     

    I compared and contrasted V7.04 and V7.05 commands sent to MPASM and MPLINK and saw that in V7.05 an extra /p18F4620 is given which was not in V7.04.

     

    I attached the project below.

     

    I tried the two versionsof commands in a DOS window and they both seem to work fine so maybe there is something else going on here. I did a fresh install on both and did not change from the default Assembler Options.

     

    Thanks.

     

    P.S The project is for an 1970's vintage microprocessor emulator of the RCA1802. I used assembler to control the tight timing requirements in order to make it bus/clock cycle accurate.

     

     

    V7.04 Works:

    Assembling...

    C:\PROGRA~1\MICROC~1\MPASMS~1\MPASMWIN.exe /pPIC18F4620 /q /eRelease\B7_1802_18F.err /lRelease\B7_1802_18F.lst /oRelease\B7_1802_18F.O /xRelease\B7_1802_18F.ref B1802_18F.asm && C:\PROGRA~1\MICROC~1\MPASMS~1\MPLINK.EXE /oRelease\B7_1802_18F.cof Release\B7_1802_18F.O 18F4620_g.lkr && C:\PROGRA~1\MICROC~1\MPASMS~1\MP2HEX.EXE Release\B7_1802_18F.cof

    MPLINK 4.37, Linker

    Copyright © 1998-2010 Microchip Technology Inc.

    Errors : 0

    MP2HEX 4.37, COFF to HEX File Converter

    Copyright © 1998-2010 Microchip Technology Inc.

    Errors : 0

    MP2HEX 4.37, COFF to HEX File Converter

    Copyright © 1998-2010 Microchip Technology Inc.

    Errors : 0

    Done

     

    V7.05 Fails:

    Assembling...

    C:\PROGRA~1\MICROC~1\MPASMS~1\MPASMWIN.exe /pPIC18F4620 /q /eRelease\B7_1802_18F.err /lRelease\B7_1802_18F.lst /oRelease\B7_1802_18F.O /xRelease\B7_1802_18F.ref B1802_18F.asm && C:\PROGRA~1\MICROC~1\MPASMS~1\MPLINK.EXE /oRelease\B7_1802_18F.cof Release\B7_1802_18F.O /p18F4620 18F4620_g.lkr && C:\PROGRA~1\MICROC~1\MPASMS~1\MP2HEX.EXE Release\B7_1802_18F.cof

    Error[108] RELEASE\B7_1802_18F.COF 1 : Illegal character ()

    Error[129] RELEASE\B7_1802_18F.COF 2 : Expected (END)

    Error[131] RELEASE\B7_1802_18F.COF 2 : Processor type is undefined

    Done

    Failed

    B7_1802_18F.zip


  4. Looks to me like the classic C bug of thinking the number placed in an array declaration is the largest index that it can take and not the number of elements to reserve.

     

    unsigned char spad[9];

    unsigend char s;

     

    If you access spad[9] that is the address of s (one byte past the spad array) so it will write the value of your function into s not spad[9].

     

    Your for loop will iterate 10 times (if you didn't clobber s) and not 9 (0,1,2,3,4,5,6,7,8,9). The last time through the loop it will access spad[9] but you only asked for 9 bytes of space for spad.

     

    Change your declaration to:

     

    unsigned char spad[10]; // Please reserve 10 bytes for my array

     

    and I bet it will work like a charm.


  5. Ok. That was it. One must set the internal oscillator frequency to either 4 or 8 MHz before turning on the phase locked loop frequency multiplier.

     

    Do this:

    osccon = (7<<4); // Select 8MHz internal osc to send to 4x PLL

    osctune = 0x40; // Enable PLL

    Not this:

    osctune = 0x40; // Enable PLL

    osccon = (7<<4); // Select 8MHz internal osc to send to 4x PLL

     

    Apparently, the hardware lockout is not on the read of the control register but instead on the write of the control register. If you don't select 4 or 8 MHz, you are prevented from setting bit 6 of OSCTUNE.

     

    My timer interrupts are now running at the corret rate. Life is good without the crystal for my non-timing critical application!


  6. I did not try setting bit 1 as there are quite a few posts I found searching the web that said (as does the spec) that you have to select the primary clock source which is setting the SCS bits to 0. Everyone finds this odd as you would think that since you are using an internal clock source that you have to select that. But, to get at the PLL you must select primary. At least that is the claim.

     

    I'll give it a try and report back.

     

    Thanks for you help Reynard.

     

    EDIT: I found this on the Microchip forum by Stefan Uhlemayr:

    "First you have to configure OSCCON to 0x70 (internal osc = 8 MHz and as primary oscillator), and then you can enable the PLL (OSCTUNE to 0x40), vice-versa don't work. "

     

    So, it seems that the answer to my question:

    "Should I swap osccon and osctune order as the PLL will only run if 8 or 4 MHz are selected?"

    is yes!

     

    I'll confirm tonight and update.


  7. Sorry. I was not clear about the fact that my time delay coming from a timer 0 interrupt. No software timer loops are being used.

     

    Hi Ted,

     

    One small question: Did you set the #pragma to tell the compiler of the new 32Mhz clock so it can recalculate any software timer values ?

     

    Cheers

     

    Reynard

     

    Here is my code for the interrupts (I had my logic analyzer on portd[0] which should be high for 1 ms every 4 ms. Instead I saw it high for 4 ms every 16 ms) :

     

    	// Set up for 40 MHz operation
    //#define TIMER0_RELOAD_VAL	250
    // Set up for 32 MHz operation
    #define TIMER0_RELOAD_VAL	200
    
    void interrupt( void )
    {
    unsigned char Tmp;
    //Handle timer0 interrupt
    if( intcon & (1<<T0IF) )
    {
    	clear_bit( intcon, T0IF );  //clear timer 0 interrupt bit
    	tmr0l -= TIMER0_RELOAD_VAL; // reload the timer 50uS per interrupt
    	LocalTick50us++;
    	if(LocalTick50us==20){ 
    		LocalTickms++;
    		LocalTick50us = 0;
    			// Column is active low so that is why LedFB is inverted
    		portd = 0;
    		porte.2 = (LedFB[DispRow] & 0x10) ? 0 : 1;
    		portc.5 = (LedFB[DispRow] & 0x20) ? 0 : 1;
    		portd = 0x1<<DispRow | (~LedFB[DispRow]<<4);
    		DispRow++;
    		if(DispRow==4) DispRow = 0;
    	}
    	GlobalTick50us++;
    	if(GlobalTick50us==20){ 
    		GlobalTickms++;
    		GlobalTick50us = 0;
    	}
    	if(GlobalTickms==200){  // will get zeroed by SetLED if which is a pulse key (0 to F or INPUT)
    		GlobalTickms = 0;
    		ClearLED(LastKey);
    		ClearLED(KEY_INPUT);  // Redundant if last was INPUT but fixes auto load flash of INPUT and key
    	}
    }
    }
    
    
    
    void InitTimer(void)
    {
    	// Timer0 increments at a rate of (Fosc/4)/2 due to prescaler
    	// So that would be 5 MHz or 200ns
    //	tmr0l = -250;	// Set up for 50us/interrupt using 40MHz clock
    tmr0l = 0 - TIMER0_RELOAD_VAL;   // Set up for 50us/interrupt using 32MHz clock
    t0con = 0xd0;  // Timer 0 and prescaler on with divide by 2 (8-bit mode)
    set_bit(intcon, T0IE);
    set_bit(intcon, GIE);
    
    LocalTick50us = 0;
    LocalTickms = 0;
    GlobalTickms = 0;
    GlobalTick50us = 0;
    DispRow = 0;
    }
    
    void Waitms(unsigned int Num)
    {
    LocalTickms = 0;
    while(LocalTickms<Num);
    }
    
    void Wait50us(void)
    {
    LocalTick50us = 0;
    while(LocalTick50us<2);
    }
    
    void Wait50us(unsigned char Count)
    {
    LocalTick50us = 0;
    while(LocalTick50us<Count);
    }


  8. I was using an external 10 MHz crystal with PLL and want to get rid of the crystal and use the internal 8 MHz oscillator with PLL to run at 32 MHz. I changed all my timer loops to use 32 MHz.

     

    I changed my config word from:

    #pragma DATA _CONFIG1H, _OSC_HSPLL_1H & _FCMEN_OFF_1H

    to:

    #pragma DATA _CONFIG1H, _OSC_INTIO67_1H & _FCMEN_OFF_1

     

    and added these control register writes as the first instructions in main():

     

    osctune = 0x40; // Enable PLL

    osccon = (7<<4); // Select 8MHz internal osc to send to 4x PLL

     

    The end result is that my time delays are all 4x longer than expected (LED flashes are about a second instead of 1/4 second). I confirmed the x4 factor with a logic analyzer.

     

    So the PIC is running without a crystal but it seems to be running at 8 MHz instead of 32 MHz. Tonight I'll code up some manual port writes to confirm that instructions are running too slow as well but it seems that the timers and the code execution are tied to the same clock source. I searched the web and most people blow it by setting osccon to 0x72 instead of 0x70 so that is not the problem. The datasheet is not real clear if you need to poll some PLL locked signal before letting code continue.

     

    If anyone has had luck getting this to work I would like to see some code. Should I swap osccon and osctune order as the PLL will only run if 8 or 4 MHz are selected? I saw one person on the web that put a 15us delay after the write to osctune but how do you count time if the PLL is not locked? I was led to believe that the core would halt until the clocks were stable when changing this crud on the fly.

     

    Thanks for any help.


  9. Thanks Dave. I'll admit that I did not try your script but instead just used the ... button to the right of the Assembler path and just navigated to MPASMWIN and gave it a go without adding all my icky flags. It all worked fine!

     

    I was able to assemble my little test program and I was able to use the debugger. I've only done a little bit of testing but it seems to work except that when I hold the mouse over a variable in the souce window it always says the current value is zero. If I add the symbol to the watch window, it has the correct value. This seems to be a minor problem.

     

    For example:

    movlw 2

    movwf Count

    clrf TMR0

     

    When the execution pointer is on clrf TMR0 I put the mouse pointer over Count and it will say that Count is 0x0. If I add Count to the watch window it will say 2.

     

    This seems to work fine for a 16F628. I also tried an 18F project and it seems to work like a charm. I just need to see if I can program a part with the hex file produced and port my plugins and I'm set.

     

    Sorry to be a dummy user and setting the flags manually. I think that is where I blew it. I needed to do that in version 6 but now that is a no no.

     

    Thanks for getting this fixed. I really appreciate it!

     

    Ted.


  10. Alright. I have not purchashed 7.x yet as I was not able to debug an assembler project on 7.02. So I broke down and tried 7.04 today with a fresh tiny assembler project. I've included how things went below. The bottom line is that I have v8.60 of the MPLAB suite installed on my machine and I am unable to build an assembler project so I can't try to debug it.

     

    It seems to me that the default settings in the SourceBoost IDE should be updated to point to the current default install path for MPLAB. Also, it seems that the build flow does not pick up the path to MPASMWIN.EXE and use it for finding the linker and other tools including the link control file. I am unable to find a way to change the path to the linker and other tools. They seem to just expect them to be in c:\.

     

    Does anyone have any hints on how to get this to work? I would like to move forward but I'm stuck with V6.89 and an old version of Microchip's assembler tucked away in a special location.

     

    Thanks for any help.

    Ted.

     

    1st Assembly: Settings->Options then Tools tab to see default Assembler is: C:\PROGRA~1\MPLABI~1\MCHIP_~1\MPASMWIN.EXE /aINHX8M /p%target% /rHEX /w2 /q

     

    Assembling...

     

    C:\PROGRA~1\MPLABI~1\MCHIP_~1\MPASMWIN.EXE /aINHX8M /pPIC16F628 /rHEX /w2 /q /pPIC16F628 /q /eDebug\asmsimp3.err /lDebug\asmsimp3.lst /oDebug\asmsimp3.O /xDebug\asmsimp3.ref AsmSimp.asm && C:\PROGRA~1\MPLABI~1\MCHIP_~1\MPLINK.EXE /oDebug\asmsimp3.cof Debug\asmsimp3.O 16F628_g.lkr && C:\PROGRA~1\MPLABI~1\MCHIP_~1\MP2HEX.EXE Debug\asmsimp3.cof

     

    Failed to spawn (C:\PROGRA~1\MPLABI~1\MCHIP_~1\MPASMWIN.EXE /aINHX8M /pPIC16F628 /rHEX /w2 /q /pPIC16F628 /q /eDebug\asmsimp3.err /lDebug\asmsimp3.lst /oDebug\asmsimp3.O /xDebug\asmsimp3.ref AsmSimp.asm). Check if path to this external application is correct.

    Failed to locate output file 'C:\PicProjects\AsmSimp3\Debug\asmsimp3.hex'

    Done

     

    Failed

     

     

    2nd try: Change Settings->Options then Tools tab to set Assembler: to "C:\Program Files\Microchip\MPASM Suite\MPASMWIN.EXE /aINHX8M /p%target% /rHEX /w2 /q"

     

    Assembling...

     

    c:\Program Files\Microchip\MPASM Suite\MPASMWIN.exe /aINHX8M /pPIC16F628 /rHEX /w2 /q /pPIC16F628 /q /eDebug\asmsmp2.err /lDebug\asmsmp2.lst /oDebug\asmsmp2.O /xDebug\asmsmp2.ref AsmSimp.asm && c:\MPLINK.EXE /oDebug\asmsmp2.cof Debug\asmsmp2.O 16F628_g.lkr && c:\MP2HEX.EXE Debug\asmsmp2.cof

     

    Failed to spawn (c:\MPLINK.EXE /oDebug\asmsmp2.cof Debug\asmsmp2.O 16F628_g.lkr). Check if path to this external application is correct.

    Failed to locate output file 'C:\PicProjects\AsmSimp2\Debug\asmsmp2.hex'

    Done

     

     

    Copy C:\Program Files\Microchip\MPASM Suite\mplink.exe and mp2hex.exe to c:\

    Assembling...

     

    C:\Program Files\Microchip\MPASM Suite\MPASMWIN.EXE /aINHX8M /pPIC16F628 /rHEX /w2 /q /pPIC16F628 /q /eDebug\asmsimp3.err /lDebug\asmsimp3.lst /oDebug\asmsimp3.O /xDebug\asmsimp3.ref AsmSimp.asm && C:\MPLINK.EXE /oDebug\asmsimp3.cof Debug\asmsimp3.O 16F628_g.lkr && C:\MP2HEX.EXE Debug\asmsimp3.cof

     

    Error spawning _mplink.exe

    MP2HEX 4.37, COFF to HEX File Converter

    Copyright © 1998-2010 Microchip Technology Inc.

    Error - Could not open Coff file 'Debug\asmsimp3.cof' for reading.

    Errors : 1

     

    Failed to locate output file 'C:\PicProjects\AsmSimp3\Debug\asmsimp3.hex'

    Done

     

    Copy C:\Program Files\Microchip\MPASM Suite\_mplink.exe to c:\

    Assembling...

     

    C:\Program Files\Microchip\MPASM Suite\MPASMWIN.EXE /aINHX8M /pPIC16F628 /rHEX /w2 /q /pPIC16F628 /q /eDebug\asmsimp3.err /lDebug\asmsimp3.lst /oDebug\asmsimp3.O /xDebug\asmsimp3.ref AsmSimp.asm && C:\MPLINK.EXE /oDebug\asmsimp3.cof Debug\asmsimp3.O 16F628_g.lkr && C:\MP2HEX.EXE Debug\asmsimp3.cof

     

    MPLINK 4.37, Linker

    Copyright © 1998-2010 Microchip Technology Inc.

    Error - Could not find linker command file'16F628_g.lkr'.

    Errors : 1

     

    MP2HEX 4.37, COFF to HEX File Converter

    Copyright © 1998-2010 Microchip Technology Inc.

    Error - Could not open Coff file 'Debug\asmsimp3.cof' for reading.

    Errors : 1

     

    Failed to locate output file 'C:\PicProjects\AsmSimp3\Debug\asmsimp3.hex'

    Done

     

    Copy C:\Program Files\Microchip\MPASM Suite\LKR\16f628_g.lkr to c:\

    Assembling...

     

    C:\Program Files\Microchip\MPASM Suite\MPASMWIN.EXE /aINHX8M /pPIC16F628 /rHEX /w2 /q /pPIC16F628 /q /eDebug\asmsimp3.err /lDebug\asmsimp3.lst /oDebug\asmsimp3.O /xDebug\asmsimp3.ref AsmSimp.asm && C:\MPLINK.EXE /oDebug\asmsimp3.cof Debug\asmsimp3.O 16F628_g.lkr && C:\MP2HEX.EXE Debug\asmsimp3.cof

     

    MPLINK 4.37, Linker

    Copyright © 1998-2010 Microchip Technology Inc.

    Error - Error reading object file 'Debug\asmsimp3.O'

    Errors : 1

     

    MP2HEX 4.37, COFF to HEX File Converter

    Copyright © 1998-2010 Microchip Technology Inc.

    Error - Could not open Coff file 'Debug\asmsimp3.cof' for reading.

    Errors : 1

     

    Failed to locate output file 'C:\PicProjects\AsmSimp3\Debug\asmsimp3.hex'

    Error[121] C:\PICPROJECTS\ASMSIMP3\ASMSIMP.ASM 1 : Illegal label (iCop)

    Done

     

    Failed


  11. I think you are missing the point that the little PICs have a hardware stack so there is no way for the compiler to generate code to read or write the contents of the stack. There is no way to deal with this unless the compilier gives up the performance of the hardware stack and implements a software stack (no calls and no rets just jumps) which would generate larger code and execute slower. I have not seen how they do it but it could be similar to how we did things back in the 70s with RCA's 1802 microprocessor which had no call and no return instruction. Instead it had multiple program counters which a couple could be dedicated to point at tiny pieces of code to implement call and return managing its own software stack. Fun times back then.

     

    Now I think our friends at SourceBoost Technologies have implemented software stacks so it may be possible to get this feature you request but in order to use it, you will have to give up performance.


  12. Using an external RAM seems pretty drastic. Why not use two 50 byte arrays and create a simple wrapper function to write and read them? You would have to write functions to access your external RAM anyway.

     

    unsigned char OutBuffer0[50],OutBuffer1[50];
    
    void WriteArray(unsigned char Index, unsigned char Data)
    {
    if(Index>50){
    	 OutBuffer1[Index-50] = Data;
    }
    else{
    	 OutBuffer0[Index] = Data;
    }
    }
    
    unsigned char ReadArray(unsigned char Index)
    {
    if(Index>50){
    	 return(OutBuffer1[Index-50]);
    }
    else{
    	 return(OutBuffer0[Index]);
    }
    }


  13. From the data sheet in section 10.4 there is a little code fragment to help out new users. If you have not read the data sheet before posting your question then shame on you. If you have then sorry to scold.

     

    Also, check out section 21.0 and have a look at ANCON0 and ANCON1. Now that I see the port defs of ANCON0 and ANCON1 I see that the code in the data sheet just gives you a hint. If you look at these bit definitions in sections 21.3 and 21.4 you will have your answer. I'm being a jerk and not giving it to you so that you get the data sheet and learn how to read it.

     

    go to http://www.microchip.com or here to get the data sheet:

    http://ww1.microchip.com/downloads/en/DeviceDoc/39932D.pdf

     

     

    CLRF LATC; Initialize PORTC by  
    			; clearing output
    			; data latches
    MOVLW 0x3F; Value used to	   
    			  ; initialize data
    			  ; direction
    MOVWF TRISC; Set RC<5:0> as inputs 
    				 ; RC<7:6> as outputs
    MOVLB 0x0F; ANCON register is not in Access Bank
    BSF ANCON1,PCFG11
    			  ;Configure RC2/AN11 as digital input


  14. We are just enjoying the weather. Here is an example of how to use interrupts. The secret is to define a function named interrupt which will be called when an interrupt occurs.

     

    I wish I could remember to use _[_c_o_d_e_] and _[_/_c_o_d_e_] (without the _ ) instead of trying 10 different variations in order to get the code to look correct!

     

     

    include <system.h>
    
    static unsigned char LocalTick50us;
    static unsigned int LocalTickms;
    
    void interrupt(void)
    {
    if( intcon & (1<<T0IF) ){ //Handle timer0 interrupt
     clear_bit( intcon, T0IF ); //clear timer 0 interrupt bit
     tmr0 -= 250;   // reload the timer - 250uS per interrupt
     LocalTick50us++;
     if(LocalTick50us==20){ 
      LocalTickms++;
      LocalTick50us = 0;
     }
    }
    }
    
    void InitTimer(void)
    {
    tmr0 = -250; // 50 us at 20 MHz
    clear_bit( option_reg, T0CS ); //configure timer0 as a timer
    set_bit(intcon, T0IE);  // Enable timer 0 interrupts
    set_bit(intcon, GIE);  // Enable interrupts[/font]
    
    LocalTick50us = 0;
    LocalTickms = 0;
    }
    
    void Waitms(unsigned int Num)
    {
    LocalTickms = 0;
    while(LocalTickms<Num);
    }
    
    void Wait50us(void)
    {
    LocalTick50us = 0;
    while(LocalTick50us<2);
    }
    
    void main(void)
    {
    InitTimer();
    
    while(1){
    // Add main code here.
    }
    }


  15. Hi guanzhao,

     

    Step 1.

    Download the datasheet from the Microchip website and read the first few chapters to get a general idea what the chip does. Yes there will be information overload at first but just suffer through it as it is good to have this info in the back of your head to make sense of other stange stuff you will see later.

     

    What does #pragma do? I see lots of pragma (e.g. DATA _CONFIG, _FCMEN_OFF & _IESO_OFF) but have no idea what is it for.

    The pragma like you mentioned sets configuration information in the microcontroller which is used before the chip executes any code. For example, it sets up the clock source to be either the internal oscillator or an external crystal. All these bits and what they do are in the datasheet (usually found in the Special Features of the CPU section under the heading Configuration Bits).

     

    How would I be able to access the ports of a microcontroller?

    BoostC makes it very easy to access the ports of the microcontroller. For example portb=0x12; will set the 8-bit port B to the value 0x12.

     

    What am I supposed to declare? Which header files should I use?

    Our friends at SourceBoost Technologies made it easy on us. All you need to include is system.h (#include <system.h>) and the build environment will load the correct header file based on the target you selected (Settings menu then Target ... menu item).

     

    What does trisa/trisab do? What should I do to it? (A reference program I saw assigned trisa = 0x00, but what does it do?)

    These control registers control the data direction of the port. For example trisb=0x0f will set bits 7 to 4 to be outputs and bits 3 to 0 to be inputs. The Microchip folks gave a secret on how to remember this. Any bit that is 0 in a tris register will be an output (a 0 looks like the o in output). In your case, you want to drive a number out of the chip so you would set your port to be 0.

     

    What does PORTA/porta do? What's the difference between them? I notices another programmer's program using porta.1 = ... but I don't understand what does it mean.

    Some compiler vendors use PORTA (Microchip) and others use porta (BoostC). Both mean the same. porta.1 means bit 1 of porta. For example porta.6 = 1; will set bit 6 of porta to 1. If port A was already 0x00 it will now be 0x40.

     

     

    I'm not up on the 16F690 but a common theme on the PICs is that the analog input pins share a digital pin and after reset, the pin is configured as an analog pin. This causes trouble for most new users so when you first start out, trying to flash some LEDs, start off using a port that does not also act as an analog input.


  16. That code compiled ok on Linux but it might be more correct to type cast the 0 passed with the data type that TestProc is expecting. The 0 should be promoted to an integer which TestProc is not expecting.

     

    Instead of:

     

    TestProc(0);

     

    Use:

     

    TestProc((PTestStruct)0);

     

    This solved the problem with V6.89. I'll admit that I'm glad the SourceBoost complier flagged this as a problem.


  17. Ok. It is nearly a year since I posted this bug and I don't expect it to get fixed so I started playing around with the Microchip C18 compiler. I'll be honest. It is a piece of crap. I ported a project from SourceBoost C and it took twice the memory and generated bad code. You have to make all your variables globals to get reasonable code and then you have to use unions to convert bytes to ints unless you want to do a bunch of type casting which then creates horrible code.

     

    Tmp = (a<<8) | b; // Tmp is an unsigned short, a and b are unsigned char will not generate valid code.

    Tmp = ((unsigned short)a<<8) | b; // produces 20 bytes of code (10 instructions) countless more if locals

     

    Your product is superior but I can't upgrade due to the cod file problem.

     

    I'm to the point where I'm thinking of trying to write a converter that converts MPASM output to the file format that SourceBoost wants. The MPASM coff file is documented and I have written an assembler that generates COFF before so I think I can figure it out with a bit of trial and error. The file expected by SourceBoost is mystery to me and would require a good deal reverse engineering. If the file spec was available to me it might motivate me more to work on this task.


  18. POSTINC pops over bank boundaries just fine. It is not limited to stay in an 8 bit range. I use it in my logic analyzer code to sample 3936 samples (uses 15+ banks). It just counts up as a 12-bit value in the 18F2620 part. You can see the code here:

     

    http://www.tedrossin.0sites.net/Electronic...l#LogicAnalyzer

     

    Look for the label "Sample5000KHz". This is the big chunk of movf PORTB,w followed by movwf POSTINC0 repeated 3936 times to implement 5M Samples/sec mode.

     

    Ok I broke down and found the place in the Microchip data sheet that says this about POSTINC which really makes my case:

    Operations on the FSRs with POSTDEC, POSTINC and PREINC affect the entire register pair; that is, rollovers of the FSRnL register from FFh to 00h carry over to the FSRnH register. On the other hand, results of these operations do not change the value of any flags in the STATUS register (e.g., Z, N, OV, etc.).

     

     

    I added a new testprogram to the original posting. Maybe it will help some.

     

    Regards,

    Lasse T

    Lasse I'm not sure if anyone got back to you on this. There are several instructions such as POSTINC and POSTDEC that only use 8 bits of address so there will be a problem if they operate on a variable that crosses a bank boundary such as an int or long starting at 0x000007FF. POSTDEC for example will operate on the first byte and then decrement the address which will just wrap around to the other end of the bank.

     

    Pavel and Dave were aware of this when developing v7 and probably that's why they added the linker error (just guessing). They also looked at some potential solutions such as the linker trying to make sure multi-byte variables did not cross bank boundaries but this is a lot trickier with, for example, a pointer to one type that is cast to a larger type, or how the ptr will be assigned, so the linker may not know ahead of time. I'm not sure what solutions were ultimately implemented - perhaps Pavel or Dave has time to chime in here? I'm guessing the linker error was added when variables could not be moved to a safer place.

     

    Your struct may also contribute to the problem (or caused the linker error). If one variable within the struct was aligned so to cross a bank, the linker would have to do a special allocation for the entire struct, which may be impossible. I'm curious how other compilers/linkers have dealt with this issue. It may be a limitation of the PIC18 devices that if you use large arrays, you have to pay close attention to alignment.

     

    Best,

    Henry

     

     


  19. I finished up my first version of the 18F2620 cheap logic analyzer (about $10) which is capable of taking 3936 samples at a 5M sample/second rate (200ns/sample). You can find the new project here:

     

     

     

    http://www.tedrossin.0sites.net/Electronics/Pic/Pic.html

     

     

     

    I added a voltmeter mode where the 5 analog inputs of the PIC are sampled and displayed on the screen. I also implemented run length encoding for transferring the samples in order to get the update rate a bit faster over the ~10Kbyte/sec serial port. The PC side software can cleanly update the PIC firmware so as new versions are available, the changes will not require pulling the part off the board.

     

     

     

    I also created a bootloader for some of the 18F devices that can found on that page as well.

     

     

     

    Let me know if you find problems.

×
×
  • Create New...