• AVR Freaks

Hot![GRIPE] Why is the PIC16F1xxxx simulator so awful?

Author
dan1138
Super Member
  • Total Posts : 3194
  • Reward points : 0
  • Joined: 2007/02/21 23:04:16
  • Location: 0
  • Status: offline
2019/08/15 23:57:08 (permalink)
5 (1)

[GRIPE] Why is the PIC16F1xxxx simulator so awful?

This post is just me venting my frustration with the MPLABX v5.25 simulation tools.

What I am trying to do is try out some of the new features of the enhanced mid-range 8-bit controllers that Microchip added to the PIC16F1xxxx family of controllers.

My first step was to check the MPLABX IDE and simulator release notes for a list of known issues so I can select a target controller to write some test code for.

The PIC16F18877 seems like something useful. A DIP-40 package, PPS for GPIO reconfiguration and a bunch of timers with simulation models.

Task 1: create code to assert an interrupt once per second from a 32MHz system oscillator.

TIMER1 is a 16-bit timer that can be reset on match with a compare using the CCP1 function block.

We need to divide the system oscillator frequency (FOSC) by 32,000,000.

The instruction clock is FOSC/4 (8MHz), the maximum TIMER1 prescale value is 1:8 so we can get a TIMER1 input clock of FOSC/32 (1MHz). This is a 16-bit timer so a maximum divisor of 62,500 will yield a output of FOSC/2,000,000. This is 16 times faster that I want.

According to the data sheet TIMER0 output can be selected as an input clock for TIMER1 so we setup TIMER0 for a FOSC/4 clock in and use TIMRE0 in 8-bit mode for a divide by 16. This yields a FOSC/64.

Select TIMER0 out as a clock source for TIMER1 and nothing! TIMER1 does not count in simulator.

Well I happen to have a few old demo boards like the DM163022-1 (PICDEM2Plus) that the PIC16F18877 will work in. So I try the code in real hardware and it works just the way the data sheet describes.

So I dig around with the timer clock source selections and come to find that the only selection that simulates correctly is when the FOSC/4 is the clock source selected for TIMER1. Selecting the FOSC clock source clocks 4 times SLOWER that the FOSC/4 clock source. Other selections do not seem to cause TIMER1 to count at all.

The MPLABX simulator release notes do not mention that FOSC/4 is the only working clock source for TIMER1. The MPLABx v5.25 IDE says the TIMER0 to TIMER5 have simulation models but I can find no mention that they are incomplete.


It is perhaps understandable that a complex function may lack a complete simulation model. Microchip can only get one clock source to work? Come on! It's the 21st century. This is only a 16-bit timer with 16 selectable clock sources. How hard can this be?

I tried the PIC16F15323 in the simulator TIMER1 fails to clock from TIMER0 as well.

Is there any part in the PIC16F1xxxx family of controllers where the MPLABx v5.25 IDE timer simulation models are complete or the documentation is correct?

I challenge Microchip to come out and say that the simulation tools are a waste of time or fix the timer simulation models.
post edited by dan1138 - 2019/08/17 14:02:23

Attached Image(s)

#1

18 Replies Related Threads

    Jim Nickerson
    User 452
    • Total Posts : 6187
    • Reward points : 0
    • Joined: 2003/11/07 12:35:10
    • Location: San Diego, CA
    • Status: offline
    Re: [GRIPE] Why is the PIC16F1xxxx simulator so awful? 2019/08/16 09:19:42 (permalink)
    0 (2)
    I wonder how much you might be willing to pay for a simulator that handled everything you wish for ?
    When I run into a situation where the simulator can not handle something I use the real hardware.
    #2
    GeorgePauley
    Moderator
    • Total Posts : 1153
    • Reward points : 0
    • Joined: 2009/12/01 13:59:30
    • Location: Chandler AZ
    • Status: offline
    Re: [GRIPE] Why is the PIC16F1xxxx simulator so awful? 2019/08/16 11:27:07 (permalink)
    0
    Looking at the simulator source, it sure looks like the TMR1 implementation will use TMR0 overflow if T1CLK.CS is set to 8.  Any chance you can give us simple code snippet to illustrate the issue?
    #3
    dan1138
    Super Member
    • Total Posts : 3194
    • Reward points : 0
    • Joined: 2007/02/21 23:04:16
    • Location: 0
    • Status: offline
    Re: [GRIPE] Why is the PIC16F1xxxx simulator so awful? 2019/08/16 13:39:25 (permalink)
    +2 (2)
    Ok George here is my test code:
    /*
     * File:     main.c
     * Target:   PIC16F18877
     * Compiler: XC8 v2.05
     * Author:   
     *
     * Description:
     *
     *  Use TIMER0 as an FOSC/64 prescale for TIMER1.
     *  Use TIMER1  with 1:8 prescale and CCP1 in compare mode to count 500000 input clocks.
     *  Make CCP1 compare assert interrupt after FOSC/32000000 clocks. (1Hz)
     *
     * Bugs:
     *  
     *  Seems to work in real hardware.
     *  
     *  Simulation models for TIMER0 and TIMER1 do not support this configuration.
     *
     *                         PIC16F18877
     *                 +----------:_:----------+
     *   S1  VPP ->  1 : RE3/MCLR/VPP  PGD/RB7 : 40 <> PGD
     * R16(0-5V) ->  2 : RA0/AN0       PGC/RB6 : 39 <> PGC
     *           <>  3 : RA1               RB5 : 38 <>
     *           <>  4 : RA2               RB4 : 37 <>
     *           <>  5 : RA3               RB3 : 36 <> LED_D5
     *   S2      ->  6 : RA4               RB2 : 35 <> LED_D4
     *   S3      ->  7 : RA5               RB1 : 34 <> LED_D3
     *           <>  8 : RE0               RB0 : 33 <> LED_D2
     *           <>  9 : RE1               VDD : 32 <- PWR
     *           <> 10 : RE2               VSS : 31 <- GND
     *       PWR -> 11 : VDD               RD7 : 30 -> LCD_ON
     *       GND -> 12 : VSS               RD6 : 29 -> LCD_E
     *      4MHZ -> 13 : RA7/OSC1          RD5 : 28 -> LCD_RW
     *           <- 14 : RA6/OSC2          RD4 : 27 -> LCD_RS
     *           <> 15 : RC0/SOSCO   RX/DT/RC7 : 26 <- RXD
     *           <> 16 : RC1/SOSCI   TX/CK/RC6 : 25 -> TXD
     *    BUZZER <> 17 : RC2/CCP1          RC5 : 24 <>
     *       SCL <> 18 : RC3/SCL       SDA/RC4 : 23 <> SDA
     *    LCD_D4 <> 19 : RD0               RD3 : 22 <> LCD_D7
     *    LCD_D5 <> 20 : RD1               RD2 : 21 <> LCD_D6
     *                 +-----------------------:
     *                          DIP-40
     */

    #pragma config FEXTOSC = OFF    // External Oscillator mode selection bits (Oscillator not enabled)
    #pragma config RSTOSC = HFINT32 // Power-up default value for COSC bits (HFINTOSC with OSCFRQ= 32 MHz and CDIV = 1:1)
    #pragma config CLKOUTEN = OFF   // Clock Out Enable bit (CLKOUT function is disabled; i/o or oscillator function on OSC2)
    #pragma config CSWEN = ON       // Clock Switch Enable bit (Writing to NOSC and NDIV is allowed)
    #pragma config FCMEN = OFF      // Fail-Safe Clock Monitor Enable bit (FSCM timer disabled)
    #pragma config MCLRE = ON       // Master Clear Enable bit (MCLR pin is Master Clear function)
    #pragma config PWRTE = OFF      // Power-up Timer Enable bit (PWRT disabled)
    #pragma config LPBOREN = OFF    // Low-Power BOR enable bit (ULPBOR disabled)
    #pragma config BOREN = OFF      // Brown-out reset enable bits (Brown-out reset disabled)
    #pragma config BORV = LO        // Brown-out Reset Voltage Selection (Brown-out Reset Voltage (VBOR) set to 1.9V on LF, and 2.45V on F Devices)
    #pragma config ZCD = OFF        // Zero-cross detect disable (Zero-cross detect circuit is disabled at POR.)
    #pragma config PPS1WAY = OFF    // Peripheral Pin Select one-way control (The PPSLOCK bit can be set and cleared repeatedly by software)
    #pragma config STVREN = ON      // Stack Overflow/Underflow Reset Enable bit (Stack Overflow or Underflow will cause a reset)
    #pragma config WDTCPS = WDTCPS_31// WDT Period Select bits (Divider ratio 1:65536; software control of WDTPS)
    #pragma config WDTE = SWDTEN    // WDT operating mode (WDT enabled/disabled by SWDTEN bit in WDTCON0)
    #pragma config WDTCWS = WDTCWS_7// WDT Window Select bits (window always open (100%); software control; keyed access not required)
    #pragma config WDTCCS = SC      // WDT input clock selector (Software Control)
    #pragma config WRT = OFF        // UserNVM self-write protection bits (Write protection off)
    #pragma config SCANE = available// Scanner Enable bit (Scanner module is available for use)
    #pragma config LVP = ON         // Low Voltage Programming Enable bit (Low Voltage programming enabled. MCLR/Vpp pin function is MCLR.)
    #pragma config CP = OFF         // UserNVM Program memory code protection bit (Program Memory code protection disabled)
    #pragma config CPD = OFF        // DataNVM code protection bit (Data EEPROM code protection disabled)

    #include <xc.h>

    #define _XTAL_FREQ (32000000ul)
    #define TIMER1_RELOAD_COUNT (62500u)

    void __interrupt() ISR_handler(void)
    {
        /* 1Hz interrupt handler */
        if(PIE6bits.CCP1IE)
        {
            if(PIR6bits.CCP1IF)
            {
                PIR6bits.CCP1IF = 0;
            }
        }
    }

    void main(void)
    {
        INTCON = 0; /* disable all interrupt sources */
        PIE0 = 0;
        PIE1 = 0;
        PIE2 = 0;
        PIE3 = 0;
        PIE4 = 0;
        PIE5 = 0;
        PIE6 = 0;
        PIE7 = 0;
        PIE8 = 0;
    /*
     * Initialize one second interrupt
     */    
        PIE0bits.TMR0IE = 0;
        PIE4bits.TMR1IE = 0;
        PIE6bits.CCP1IE = 0;
        T1CON = 0;
        T1CLK = 0;
        TMR1 = 0;
        T1CONbits.CKPS = 0b11; /* select 1:8 prescaler */

    //#define MAKE_TIMER1_CLOCK_IN_SIMULATOR
    #if defined(MAKE_TIMER1_CLOCK_IN_SIMULATOR)
        T1CLKbits.CS =0b0001;       /* select FOSC/4 output as clock source for TIMER1 */
    #else
        T1CLKbits.CS =0b1000;       /* select TIMER0 output as clock source for TIMER1 */
    #endif
        
        /* WARNING: TIMER1 does not clock from the TIMER0 output in simulation */
        T0CON0 = 0;
        T0CON1 = 0b01000000;        /* select FOSC/4 as clock source for TIMER0 */
        TMR0L  = 0;
        TMR0H  = 15;                /* select TIMER0 to overflow after FOSC/64 clocks */
        T0CON0bits.T0EN = 1;        /* start TIMER0 */

        CCP1CON = 1;            /* compare mode, on match clear TIMER1 */
        CCPR1 = TIMER1_RELOAD_COUNT;

        CCP1CONbits.EN = 1;
        PIR6bits.CCP1IF = 0;
        PIE6bits.CCP1IE = 1;
        T1CONbits.TMR1ON = 1;
    /*
     * Enable system interrupts
     */    
        INTCONbits.PEIE = 1;
        INTCONbits.GIE  = 1;
        
        for(;;)
        {
            NOP();
        }
    }

    Can I get paid for testing Microchip tools?
    post edited by dan1138 - 2019/08/16 13:58:07
    #4
    NKurzman
    A Guy on the Net
    • Total Posts : 17719
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: [GRIPE] Why is the PIC16F1xxxx simulator so awful? 2019/08/16 15:08:59 (permalink)
    +3 (3)

    Can I get paid for testing Microchip tools?



    They should Offer at least Swag.
    #5
    dan1138
    Super Member
    • Total Posts : 3194
    • Reward points : 0
    • Joined: 2007/02/21 23:04:16
    • Location: 0
    • Status: offline
    Re: [GRIPE] Why is the PIC16F1xxxx simulator so awful? 2019/08/16 22:54:51 (permalink)
    +3 (3)
    JANickerson
    I wonder how much you might be willing to pay for a simulator that handled everything you wish for ?

    I would settle for accurate documentation so I don't waste time trying to do something that is not supported.
     
    What I want is for Microchip to tell us what the simulator does not support.
     
    And I agree that no simulator is as correct as the real device.
    #6
    GeorgePauley
    Moderator
    • Total Posts : 1153
    • Reward points : 0
    • Joined: 2009/12/01 13:59:30
    • Location: Chandler AZ
    • Status: offline
    Re: [GRIPE] Why is the PIC16F1xxxx simulator so awful? 2019/08/19 11:52:34 (permalink)
    +7 (7)
    Problem identified and fixed.  Fix is available in 5.30.  Sorry for the inconvenience.
    #7
    dan1138
    Super Member
    • Total Posts : 3194
    • Reward points : 0
    • Joined: 2007/02/21 23:04:16
    • Location: 0
    • Status: offline
    Re: [GRIPE] Why is the PIC16F1xxxx simulator so awful? 2019/08/19 13:24:48 (permalink)
    +1 (1)
    GeorgePauley
    Problem identified and fixed.  Fix is available in 5.30.  Sorry for the inconvenience.

    George,
     
    Your people that create the simulation models must have some kind of integration tests that should be able to identify that timer clock sources that can be selected actually cause the timer state to change during simulation.
     
    You are the most proactive of the Microchip employees that read posts on this forum so I am reluctant to ask this question:
     
    Why does it take a griping, whining post from a developer for a bug like this to be noticed?
     
     
    <EDIT>
    Thank you for responding to my post.
    post edited by dan1138 - 2019/08/19 14:45:19
    #8
    nice
    Super Member
    • Total Posts : 1089
    • Reward points : 0
    • Joined: 2004/09/18 11:42:25
    • Location: Germany
    • Status: offline
    Re: [GRIPE] Why is the PIC16F1xxxx simulator so awful? 2019/08/19 16:18:09 (permalink)
    +1 (1)
    dan1138
    Why does it take a griping, whining post from a developer for a bug like this to be noticed?
     



    Have you ever been faced with first level support? If so, it has proven to be of benefit to mention to first level support that you're unhappy with their performance. Sometimes subtile hints are enough, but sometimes it takes statements like "I’m really pissed off by your kind of support" until they notice that a reported issue is beyond their scope.  

    After reporting an issue regarding the XC16 compiler, I was also faced with Microchip’s marketing (bullshit) department. They seriously asked me for the project's name and the annual quantity of chips I’m buying after reporting an XC16 related issue affecting all users of dsPIC33CH devices. None of the questions were useful for resolving the reported issue, of cause. Hence my conclusion is that there are three ways to get past first level support. Griping and whining here, telling the marketing department that you’ll buy 1 million chips per year or telling the first level support that you’re pissed off.

    I’m seriously missing the old Hi-Tech support. For any decent bug report I’ve gotten a decent answer (thanks Jeff and Mark) without having to discuss it with first level support not understanding the issue at all.
    #9
    newfound
    Super Member
    • Total Posts : 1840
    • Reward points : 0
    • Joined: 2003/11/07 12:35:49
    • Status: offline
    Re: [GRIPE] Why is the PIC16F1xxxx simulator so awful? 2019/08/19 16:24:08 (permalink)
    0
    NKurzman

    Can I get paid for testing Microchip tools?



    They should Offer at least Swag.


    I got a Tee shirt once. :) 
    #10
    dan1138
    Super Member
    • Total Posts : 3194
    • Reward points : 0
    • Joined: 2007/02/21 23:04:16
    • Location: 0
    • Status: offline
    Re: [GRIPE] Why is the PIC16F1xxxx simulator so awful? 2019/08/19 16:43:38 (permalink)
    +2 (2)
    nice
    dan1138
    Why does it take a griping, whining post from a developer for a bug like this to be noticed?

    Have you ever been faced with first level support?

    I humbly suggest that you may have missed my point.
     
    As a developer that read the available documentation, errata and release notes I expect that the manufacturer supplied tools either meet the specification or there is documentation that describes where they do not.
     
    My point is that Microchip testers should have found this simulator behavior and fixed it or documented.
     
    My gripe is that neither of these things occurred and only the action on my part caused any change.
    #11
    GeorgePauley
    Moderator
    • Total Posts : 1153
    • Reward points : 0
    • Joined: 2009/12/01 13:59:30
    • Location: Chandler AZ
    • Status: offline
    Re: [GRIPE] Why is the PIC16F1xxxx simulator so awful? 2019/08/20 11:05:39 (permalink)
    +7 (7)
    dan1138
    Your people that create the simulation models must have some kind of integration tests that should be able to identify that timer clock sources that can be selected actually cause the timer state to change during simulation.
    ...
    Why does it take a griping, whining post from a developer for a bug like this to be noticed?


    Actually the simulator has a large number (over 12k) unit tests that take a couple of hours to run each night.  And the SQA group does independent testing beyond that.  Though I doubt SQA's testing is exhaustive with respect to different timer clock sources.

    In this particular case, the timer functionality was originally developed for PIC18 devices, and there are boatloads of tests for this timer.  It turns out that the PIC16 timer that you are using is identical to the PIC18 timer.  So the simulator is using the same code for both PIC18 and PIC16 timers. Since the PIC18 timer was tested and known to work, there was minimal effort to test this software using PIC16 devices.
     
    The bug you discovered has to do with using another timer as the input source.  In this situation, the simulator timer code expects to receive a PIC18PeripheralNotification object.  Of course this doesn't work so well when the device is a PIC16.  The fix was pretty straightforward as you might imagine.
     
    The simulator is demonstrably the most expensive (and most complicated) development tool Microchip creates.  (And we give it away for free!)  We struggle with balancing functionality and cost versus utility.  There is not a single processor or peripheral that 100% faithfully models what it represents.  Supporting over 3000 devices, 200 peripherals, and over 1 million lines of code, the job of enumerating exact functionality would be monumental, and beyond the resources we can bring to bear.  We cannot fix every deficiency.  Heck we can't even list them all.  We get as close as we can with the resources available to us.

    It is worth noting that the code in question here is 10 years old.  And that you were the first person to report the issue.  I'm sure you won't like hearing this, but there's a pretty good argument that we guessed correctly on the cost versus utility question in this case.
     
    At this point in the discussion I often hear that the simulator, as described, is simply useless.  And there may be grain of truth in that.  Especially since hardware tools like PICkit and ICD are very cheap, and real PIC devices ALWAYS model themselves faithfully.

    That said, our metrics indicate that that there are usually about 15k-20k unique simulator users for each MPLAB X release.  The majority of these users are productive and experience no issues.  Many customers have told us that they can't do their development without it.  And this is why Microchip keeps pouring resources into continued simulator support.  But when you are one of the unlucky ones who does discover a blocking issue, it can definitely be frustrating.

    We take bugs as we get them.  We evaluate them and usually fix them.  These forums are meant to be a peer-to-peer self-help system.  In this case, I (the simulator team lead) happen to monitor this forum, out of my own desire to see what is going on.  So you got lucky that I saw this.  I could have been at MASTERS, or on vacation, etc.  A better, more consistent, approach is to open a ticket.
    #12
    mlp
    boots too small
    • Total Posts : 794
    • Reward points : 0
    • Joined: 2012/09/10 15:12:07
    • Location: previously Microchip XC8 team
    • Status: offline
    Re: [GRIPE] Why is the PIC16F1xxxx simulator so awful? 2019/08/21 09:29:50 (permalink)
    +1 (1)
    nice
    I’m seriously missing the old Hi-Tech support. For any decent bug report I’ve gotten a decent answer (thanks Jeff and Mark) without having to discuss it with first level support not understanding the issue at all.

    Aww, shucks.
     
    To be fair, a company with tens of staff is a different beast to one with thousands, and I know which environment I preferred working in.
     
    My suggestion for best results is:
    • discuss the problem you're seeing, and provide a complete program to demonstrate the issue, here
    • if you get responses from regulars confirming your diagnosis, log a support case pointing to the forum discussion; if it's within the area of expertise of a Microchippee whose name you know from here, note that in the case too
    • if nobody comments usefully, refine your test program and continue the discussion
     

    Mark (this opinion available for hire)
    #13
    GeorgePauley
    Moderator
    • Total Posts : 1153
    • Reward points : 0
    • Joined: 2009/12/01 13:59:30
    • Location: Chandler AZ
    • Status: offline
    Re: [GRIPE] Why is the PIC16F1xxxx simulator so awful? 2019/08/21 10:49:18 (permalink)
    0
    mark.pappin
    nice
    I’m seriously missing the old Hi-Tech support. For any decent bug report I’ve gotten a decent answer (thanks Jeff and Mark) without having to discuss it with first level support not understanding the issue at all.

    Aww, shucks.
     
    To be fair, a company with tens of staff is a different beast to one with thousands, and I know which environment I preferred working in.



    HiTech wasn't thousands, I think they were like 20 people? 
    #14
    PStechPaul
    Super Member
    • Total Posts : 2375
    • Reward points : 0
    • Joined: 2006/06/27 16:11:32
    • Location: Cockeysville, MD, USA
    • Status: online
    Re: [GRIPE] Why is the PIC16F1xxxx simulator so awful? 2019/08/21 12:24:09 (permalink)
    0
    I miss the support that was available when I first started working with PICs 20 years ago. I was using a PIC16C63a and assembly, and my previous experience was with 8080/8085/Z80 code. I placed a phone call to Microchip and soon I was talking with an actual engineer (or a very well informed support tech) in Chandler. My problem turned out to be bank selection, a common newbie mistake, that did not exist for the microprocessors I was familiar with. I don't really expect such one on one support these days, although this forum is just about as good. The support ticket system seems to have degraded over the last ten years or so, and I rarely use it.

     
    #15
    nice
    Super Member
    • Total Posts : 1089
    • Reward points : 0
    • Joined: 2004/09/18 11:42:25
    • Location: Germany
    • Status: offline
    Re: [GRIPE] Why is the PIC16F1xxxx simulator so awful? 2019/08/21 12:32:55 (permalink)
    0
    I’m working for a company with about 350 employees. It’s much more larger than Hi-Tech was and much more smaller than Microchip is. The bug reports I’m getting regarding the firmware I’ve written are usually filed by our service department. Depending on the person having filed the bug report, it’s quite easy for me to differentiate between "PEBKAC" and a real issue in my firmware.

    Of cause making such assumptions is much more easy in a small to mid size company than in a real big company. Microchip’s marketing department asked for the project’s name and the estimated annual use of the device in question. Obviously their customer’s data base have entry fields for both. How about adding an entry field called "This customer does not require first level support"?

    @Mark
    All of your points are valid and I obey to them. Nevertheless it’s a waste of time for me discussing reported issues with first level support.
    #16
    nigelwright7557
    Super Member
    • Total Posts : 284
    • Reward points : 0
    • Joined: 2006/11/06 08:15:51
    • Location: 0
    • Status: online
    Re: [GRIPE] Why is the PIC16F1xxxx simulator so awful? 2019/08/21 12:43:59 (permalink)
    0
    dan1138
     
    Why does it take a griping, whining post from a developer for a bug like this to be noticed?
     



    The PIC dev tools are very complex. Also software engineers are very expensive so any tasks the get are prioritised.
    On the face of it things like XC compilers and Harmony are great ideas but they are also massive undertakings and take up massive resources.
    #17
    ric
    Super Member
    • Total Posts : 23581
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: [GRIPE] Why is the PIC16F1xxxx simulator so awful? 2019/08/21 13:19:08 (permalink)
    +2 (2)
    GeorgePauley
    HiTech wasn't thousands, I think they were like 20 people?

    That was Mark's point.
    He's comparing HiTech ("tens of staff") with Microchip ("thousands").
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #18
    mlp
    boots too small
    • Total Posts : 794
    • Reward points : 0
    • Joined: 2012/09/10 15:12:07
    • Location: previously Microchip XC8 team
    • Status: offline
    Re: [GRIPE] Why is the PIC16F1xxxx simulator so awful? 2019/08/23 14:26:37 (permalink)
    +3 (3)
    ric
    GeorgePauley
    HiTech wasn't thousands, I think they were like 20 people?

    That was Mark's point.
    He's comparing HiTech ("tens of staff") with Microchip ("thousands").

    At HI-TECH I was employee number 20-something.
    At Microchip I was employee number 15-thousand-and-something.

    Mark (this opinion available for hire)
    #19
    Jump to:
    © 2019 APG vNext Commercial Version 4.5