Why do people not like Microchip?

[woofy]

They start asking for your email already if you want to download the latest compiler.

Microchip compilers are free to download, you do not have to give them an email address.
https://www.microchip.com/en-us/development-tools-tools-and-software/mplab-xc-compilers#Downloads

[Jan Audio]

Ah better, they removed it.
I was getting suspicious.

Gotto be hard about these things, people dont care normally.

[AaronD]

...converting two characters into one byte. I came up with a bizarre way of doing it, I haven't seen it anywhere else. It doesn't check the data and alpha hex (A-F) has to be in upper case. It reads the hex output of MPLAB just fine:

Code: [Select]

SWAPF CHAR1,W
ADDLW 0x55
BTFSS CHAR1,6 ; test if letter
ADDLW 0x71
; 2nd hex char
ADDWF CHAR2,W
BTFSS CHAR2,6 ; test if letter
ADDLW 0x07

I'll...just take your word that that works.  I tried to prove it to myself before I left yesterday morning; I could see a little bit of a pattern emerging, but not the whole thing.

You assembler guys are something else.  You might be the best bit-twiddlers on the planet, and you produce the most compact and obfuscated code that I've seen, even compared to an optimizing compiler.  That's great, as long as the rest of us just take it as a black box that "just works" and don't try to wrap our minds around how.

[T3sl4co1l]

I mean it doesn't look too bad to me, even though I'm not familiar with PIC ASM; but that is the catch, you have to know what things mean, and step through it and reason it out -- I know a few instruction sets, so it's not too alien to me.  If you don't know ASM at all, it's just a bunch of cryptic incantation; you sure as hell aren't going to know where to plop it into a project!

The constants 0x55, 0x71 and 0x07 look like offsets related to ASCII code, namely the ranges of letters, or the lack thereof.  Although I'm not sure how exactly they relate ('A' == 0x41 is a long way from 0x55?), I'd have to read the instruction set to see what exactly is being done.

So, that is to say: even for experts in related fields like myself, it may not exactly be useful, or even intelligible; your sarcasm is understandable!


A relevant example in C (if not an equivalent; but given the above is only 7 instructions, I don't think it does nearly the full thing either, just a snippet from the middle of such) might look like the two functions here,
https://github.com/T3sl4co1l/Reverb/blob/master/console.c#L275

Whereas in my linked C example, the constants are explicitly readable -- single-quoted letters are parsed as numeric constants, so you get precisely the range of letters converted as is written.  (Does use the assumption that ASCII is well-ordered, which, fortunately it is; this might not always be the case, like in the bad old days of EBCDIC!)  Note it also checks range more carefully, which might not be needed, and will take more instructions (to be exact, the whole function is 40 instructions on avr-gcc 8.1.0 -Os; that includes the helper function, which gets inlined; for a complete function that operates on a string, and even with GCC 8's very poor AVR optimizing, that's quite reasonable).

Tim

[NorthGuy]

Although I'm not sure how exactly they relate ('A' == 0x41 is a long way from 0x55?), I'd have to read the instruction set to see what exactly is being done.

That's quite straightforward actually. Letters 'A' to 'F' are encoded with codes 0x41 - 0x46, while numbers are encoded 0x30 to 0x31. Like symbol = number + 0x30. It would be nice if 'A' was encoded as 0x3a, 'B' as 0x3b etc, but the creators of ASCII were dumb and didn't do it this way. But we can fix it:

Code: [Select]

uint8_t get_byte(char ch, char cl) {
  if (ch & 0x40) ch -= 7; // 'A' is changed from 0x41 to 0x3a, 'B' from 0x42 to 0x3b etc
  ch -= 0x30; // convert to a number

  if (cl & 0x40) cl -= 7; // same for the next character
  cl -= 0x30;
 
  return (ch << 4) + cl;
}
Now, we can re-write this in assembler. It'll be a little bit dumb at first, as a non-optimized compiler:

Code: [Select]

  movf ch,w   ; load ch
  btfsc ch,6  ; the next command is executed only if ch is a letter
  addlw 0xf9  ; subtract 7
  addlw 0xd0  ; subtract 0x30
  movwf ch    ; store the result
 
  movf cl,w   ; load cl
  btfsc cl,6  ; the next command is executed only if cl is a letter
  addlw 0xf9  ; subtract 7
  addlw 0xd0  ; subtract 0x30
  movwf cl    ; store the result
 
  swapf ch,w  ; shift (no barrel shifter, so swap instead)
  addwf cl,w  ; and add to get the result
Now we can optimize it a bit. First, the cl calculation only used additions. Therefore, instead of storing the ch value and adding it at the end, we can simply keep it and add everything to it. This saves 3 instructions:

Code: [Select]

  movf ch,w   ; load ch
  btfsc ch,6  ; the next command is executed only if ch is a letter
  addlw 0xf9  ; subtract 7
  addlw 0xd0  ; subtract 0x30
  swapf WREG,w   ; shift the result
   
  addwf cl,w  ; add cl to the result
  btfsc cl,6  ; the next command is executed only if cl is a letter
  addlw 0xf9  ; subtract 7
  addlw 0xd0  ; subtract 0x30
Then, we can join the loading of ch with the swap. This will requite some intelligence in tweaking the constants to make sure the effect is the same, but will save one more instruction:

Code: [Select]

  swapf ch,w  ; load and shift ch
  btfsc ch,6  ; the next command is executed only if ch is a letter
  addlw 0x8f  ; subtract 1 from lower nibble, add 9 to upper nibble
  addlw 0xfd  ; subtract 0x30, which is 0x03 after the shift
   
  addwf cl,w  ; add cl to the result
  btfsc cl,6  ; the next command is executed only if cl is a letter
  addlw 0xf9  ; subtract 7
  addlw 0xd0  ; subtract 0x30
Finally, there are two unconditional additions, which can be united into one

Code: [Select]

  swapf ch,w  ; load and shift ch
  btfsc ch,6  ; the next command is executed only if ch is a letter
  addlw 0x8f  ; subtract 1 from lower nibble, add 9 to upper nibble
  addwf cl,w  ; add cl to the result
  btfsc cl,6  ; the next command is executed only if cl is a letter
  addlw 0xf9  ; subtract 7
  addlw 0xcd  ; united addition
Now, the only thing left is to remove comments. Lo and behold:

Code: [Select]

  swapf ch,w
  btfsc ch,6
  addlw 0x8f   
  addwf cl,w
  btfsc cl,6
  addlw 0xf9
  addlw 0xcd
You can re-write it in C as well, only C won't have a swap:

Code: [Select]

uint8_t swap(uint8_t r) {
  return (r << 4) | (r >> 4);
}

uint8_t get_byte(char ch, char cl) {
  uint8_t x = swap(ch) + cl;
 
  if (ch & 0x40) x += 0x8f;
  if (cl & 0x40) x += 0xf9;
   
  return (x + 0xcd);
}

[MIS42N]

Northguy has the same solution as piclist http://www.piclist.com/techref/microchip/math/radix/a2b-2h8b-pf.htm which, if I had found it earlier would have saved a bit of time. It is a more logical approach using twos complement addition to do subtraction (PIC doesn't have a subtract literal from register, so the equivalent is add a twos complement). In essence, it converts the ascii 4k to ascii 3k+9, then removes the 3s in the last line. I was not so smart. Knowing the ascii 4k had to have 9 added, I added it to every character (the combination of 0x55 and the 4 in 4k) I then adjusted the 3k numbers which now were 3k+9 TO 4k by adding another 7. The end result is the same, the cycles are the same, the execution time is the same.

[T3sl4co1l]

Speaking from experience with avr-gcc at least, the compiler can recognize a swap -- even with optimization sadly, GCC will still mask the result if you do e.g. (x >> 4) & 0x0f, even if you don't use the high nibble in subsequent operations; however, using x >> 4 | x << 4 or something like that, will properly elucidate the SWAP instruction.  So it's sometimes worthwhile to add both terms to the expression, even if you aren't using one of the results.

Possibly the same is true of PIC compilers.

Tim

[NorthGuy]

Northguy has the same solution as piclist http://www.piclist.com/techref/microchip/math/radix/a2b-2h8b-pf.htm which, if I had found it earlier would have saved a bit of time. It is a more logical approach using twos complement addition to do subtraction (PIC doesn't have a subtract literal from register, so the equivalent is add a twos complement). In essence, it converts the ascii 4k to ascii 3k+9, then removes the 3s in the last line. I was not so smart. Knowing the ascii 4k had to have 9 added, I added it to every character (the combination of 0x55 and the 4 in 4k) I then adjusted the 3k numbers which now were 3k+9 TO 4k by adding another 7. The end result is the same, the cycles are the same, the execution time is the same.

That's the same method as yours. I actually tried to explain how your method can be derived, but it came out with reverse coefficients.

0xcd + 0x8f + 0xfd = 0x55 - here's your 0x55 for the case where both chars are letters
0x55 + 0x71 + 0x07 = 0xcd - here's 0xcd from my post for the case where both chars are digits

[AaronD]

...the creators of ASCII were dumb and didn't do it this way...

I wouldn't quite say that.  They were just optimizing string functions.  See how capitals and lowercase line up nicely with each other?  It took some padding to do that, so they used the punctuation characters for the padding, and followed some patterns for those too.  And it still doesn't take much effort at all to convert two ASCII hex characters to a byte, as shown in the previous few posts.

I think it would only add one instruction to handle both upper and lower case:  When you know it's a letter, force one bit to make it known which case it is, then add the appropriate offset for that known case.  For comparison, bounds-checking everything would probably double the code size.


Also interesting are the control characters that were used originally to control a teletype, or "remote-controlled dumb typewriter".  We hardly use any of them now:

• carriage ("print head") return
• line (paper) feed
• horizontal tab (there's a now-barely-used v-tab too; both of these together make tables somewhat easier)
• escape
• backspace
• delete

but it's interesting to see that the rest of them are still part of the modern standard.

[T3sl4co1l]

Don't forget bell!

Indeed, outside of specific applications (various types of terminal emulators, or original equipment of historical interest) you're pretty free to use 0-31 however you like, minus the most conventional exceptions; often some in-band coding is needed, and they were originally assigned precisely this task.

Tim

[MIS42N]

Don't forget bell!

Indeed, outside of specific applications (various types of terminal emulators, or original equipment of historical interest) you're pretty free to use 0-31 however you like, minus the most conventional exceptions; often some in-band coding is needed, and they were originally assigned precisely this task.

Tim

Xmodem protocol still uses SOH ACK NAK and EOT. It neatly gets around the problem of control characters in data by always sending 128 bytes of data. For something cooked up for a specific purpose decades ago it's nice to work with. I chose to use it because it is half duplex, the code can disable interrupts and run entirely with polling which means the bootloader can overwrite the interrupt vector. And Tera Term supports it and is freeware.

[westfw]

Letters 'A' to 'F' are encoded with codes 0x41 - 0x46, while numbers are encoded 0x30 to 0x31. Like symbol = number + 0x30. It would be nice if 'A' was encoded as 0x3a, 'B' as 0x3b etc, but the creators of ASCII were dumb and didn't do it this way/

ASCII (1961) somewhat pre-dates the current usage of "hexadecimal" (which first showed up on IBM machines that didn't use ASCII in 1964)
Hexadecimal has a more interesting history than I would have thought.  Apparently letters other than A-F, or even entirely new symbols, we used before IBM...
https://en.wikipedia.org/wiki/Hexadecimal

[nigelwright7557]

I have used PIC's for 35 years.
Its a case of matching the right PIC to the job.
Sometimes an 8 pin PIC will do the job.
Other times I need a lot more power and lots of peripherals so use PIC32MX series.

Not everyone gets on with MPLAB X. Its a bit of a mess but things can be found if you dig deep enough.
The pickit can be a bit flaky at times.
I found the snap programmer works better.

[brichards42]

I decided to have a look at MPLABX so downloaded, installed, unchecked provide anonymous data, unchecked check for updates.

I then turned on my firewall and disabled all output with logging, and found it took over 4 minutes for the ide to start, all the while in the background it repeatedly tried to connect to:
13.226.204.19
184.51.39.36
 224.0.0.251
 52.218.216.234
 52.92.162.171
 72.247.206.9

Maybe all the other major players do this to but but seems like we just want to give the impression you have the option to run without 'pinging' various cloud services (for whatever purpose).

[Warhawk]

 

[poorchava]

I started looking at Microchip again, since I can't buy any STM32 nowadays, and C2000 are just a too much of a pain to use for a general purpose microcontroller.

I've used them until like 7...8 years ago. Stuff that used to throw me off:
-all 8 bit PICs (10, 12, 16, 18) are SHIT. Much slower than AVR, non-vectored interrupts, memory banking, etc. The only reason I'd fathom to use them would be either some ultra low power application, or something that would use some of their weird (but admittedly - interesting) peripherals like CTMU.
-dsPIC30s were total CRAP. I recall one of those drawing so much current it was actually very warm. And this wasn't some shorted GPIO.
-all parts had frequent read/modify/write problems
-silicon bugs. My favorite was some PIC24H which was advertised as 'USB OTG OMG WTF' and the first paragraph in the errata was 'USB doesn't work'.
- I recall that onc upon a time they were aggressively marketing paid compiler versions that resulted in almost 50% smaller code... That's when I looked at the disassembly and found out that the free version was deliberately adding dummy instructions to blat the code and slow it down.... Great... Maybe it's different now, I don't know.

[westfw]

-all 8 bit PICs (10, 12, 16, 18) are SHIT. Much slower than AVR

That's not entirely true.  The PICs take 4 clock cycles per instruction (vs 1 on the AVR), but they also frequently allowed clock speeds about 4x faster than similar AVRs.

the free version was deliberately adding dummy instructions to blat the code and slow it down...

There was a lot of debate on whether it was adding dummy instructions, or whether their "no optimization" code was REALLY dumb.  (avr-gcc -O0 code is also really horrible.)  If you assume that the unoptimized code was aimed at some abstract VMish thing that put a C-like architecture on top of the PIC decidedly un-C-friendly CPU, it was almost within the realm of believability.  It was pretty awful, though.

Maybe it's different now, I don't know.

It is in fact much better now.  Not great, but no longer in the "this is completely horrible" range.

[AaronD]

-all 8 bit PICs (10, 12, 16, 18) are SHIT. Much slower than AVR, non-vectored interrupts, memory banking, etc. The only reason I'd fathom to use them would be either some ultra low power application, or something that would use some of their weird (but admittedly - interesting) peripherals like CTMU.

I wouldn't go quite that far.  Yes, the CPU is awful compared to AVR, and the almost-requirement to use a proprietary compiler that is focused more on commercial profit than on hobbyist accessibility (it never was GCC-compatible and probably never will be), makes it even worse.  But they seem to have a lot more peripherals for the price than AVR, even for the bog-standard stuff.  So if I can make the peripherals do all the work and keep the CPU as just a supervisor with only a small amount of less-critical "glue logic", then that makes a PIC the better choice.

But for data-processing kinda stuff, AVR wins by a mile in the 8-bit world!  It was wonderful, having learned on PIC, to use an AVR for the first time to make a DMX lighting controller.  A little bit of peripheral work just to move data in and out, and TONS of memory and number-crunching.  Just to declare a single, 2-dimensional array (scenes x channels) to occupy several kB would be a tall order on a PIC, but the AVR was like, "Yeah, sure!  What else ya want?"  Not to mention working through all of that data within one refresh cycle.
(PIC's do tend to have higher maximum clock rates, but not *that* much higher.  32MHz/4=8MIPS for PIC, vs 20MHz=20MIPS for AVR.  Plus, AVR likes to include a single-cycle multiplier more than PIC does.)

-dsPIC30s were total CRAP. I recall one of those drawing so much current it was actually very warm. And this wasn't some shorted GPIO.

  Good to know that.  I've been casually looking for a good DSP chip myself, that supports 8-ch bidirectional audio + HID as a USB device, plus some audio ADC's and DAC's, and can use my own code to get the latency way down for the analog-to-analog signal path.  (most libraries use a block size of 64 samples or so, but I need single samples)  I'm guessing that's not it.

-all parts had frequent read/modify/write problems

Never had a problem with that myself.  Maybe because I learned on them and treated that oddity and its workaround as "normal"?  I'm not even sure what it is.

-silicon bugs. My favorite was some PIC24H which was advertised as 'USB OTG OMG WTF' and the first paragraph in the errata was 'USB doesn't work'.

  That's good!  I wouldn't put it past them though.  Too much marketing pressure to get it out NOW!???

- I recall that onc upon a time they were aggressively marketing paid compiler versions that resulted in almost 50% smaller code... That's when I looked at the disassembly and found out that the free version was deliberately adding dummy instructions to blat the code and slow it down.... Great... Maybe it's different now, I don't know.

The official explanation is that all versions initially output the "free" assembly by concatenating prefab entries from a lookup table that each have enough wrapper code around them to guarantee that they all work in every context as-is, and then the paid versions go back and clean that mess up according to how much you paid for it.  In that sense, it's not artificially stuffing the output with dummy instructions, but yeah, the completely uncleaned code that you get from the free version is pretty bad.

But the chip does end up doing what the source tells it to do.  In that sense, it's a "good" compiler, but ONLY in that sense.

[SiliconWizard]

-dsPIC30s were total CRAP. I recall one of those drawing so much current it was actually very warm. And this wasn't some shorted GPIO.

  Good to know that.  I've been casually looking for a good DSP chip myself, that supports 8-ch bidirectional audio + HID as a USB device, plus some audio ADC's and DAC's, and can use my own code to get the latency way down for the analog-to-analog signal path.  (most libraries use a block size of 64 samples or so, but I need single samples)  I'm guessing that's not it.

Well, the dsPIC33 series is much better, more recent and more powerful. If you were interested in the dsPIC series.
The dsPIC30 series was really not that bad. It was ALOT more powerful, and easier to use than anything Microchip had released before. But yes they were power hungry and would heat up quite a bit. Absolutely no reason to go for them these days, unless the extended VDD range up to 5.5V could do something for you. Otherwise, dsPIC33 is the way to go. Of course if you want a 16-bit Microchip dsPIC. There are certainly many other and more powerful options these days.

[T3sl4co1l]

the free version was deliberately adding dummy instructions to blat the code and slow it down...

There was a lot of debate on whether it was adding dummy instructions, or whether their "no optimization" code was REALLY dumb.  (avr-gcc -O0 code is also really horrible.)  If you assume that the unoptimized code was aimed at some abstract VMish thing that put a C-like architecture on top of the PIC decidedly un-C-friendly CPU, it was almost within the realm of believability.  It was pretty awful, though.

Which IS, AFAIK, the explanation with GCC -- the IL is particularly ill-suited to AVR so makes rather boneheaded decisions, and performs little optimization once it's there [which, I think you're already keenly aware of!].  And that kind of makes sense, for all the machines GCC targets.  It seems to have improved a bit since GCC 10 or so; 8 was actually doing worse on a number of cases than 4 or 5.  (I've personally more than doubled the speed of some DSP routines with asm, versus avr-gcc 8.1.0.)  It would be... surprising? If a PIC-exclusive tool weren't optimized towards that family, but yeah, who knows.

Tim

[MIS42N]

-all 8 bit PICs (10, 12, 16, 18) are SHIT. Much slower than AVR, non-vectored interrupts, memory banking, etc. The only reason I'd fathom to use them would be either some ultra low power application, or something that would use some of their weird (but admittedly - interesting) peripherals like CTMU.

I like the PIC16F1455. I wished I could use the USB interface but the design requires a 10MHz clock and that is incompatible with the USB module (it likes 48MHz sub multiples). The processor has a PLL clock multiplier so internally runs at 40MHz. I use the 40MHz clocked 10 bit PWM, and capture events to 25ns accuracy in firmware using Timer 1 running at 40MHz gated by a comparator at 1.9V derived from the internal voltage reference (which allows an interface with a low voltage part without a level translator). I also switch between the external and internal oscillator on the fly. Write to flash memory. Use one read only pin as a software 9600 baud input, because I use the UART to run a user interface. There are 7 interrupt handlers handling around 50,000 interrupts a second. All that in a part that draws 5mA and costs less than $2.

I avoid dealing with the vagaries of the C compilers by writing assembler. Plenty of spare memory so I added a bootloader that allows direct reprogramming by hex files using Tera Term's Xmodem transfer.

Yes, the banked program and data memory model can get in the way, but it is not hard to get used to it. The 1455 has some useful enhancements compared to previous 8 bit PICs. Interrupts automatically save and restore many registers, which allows IRCs to be quite short. The stack is exposed and can be programmatically manipulated. Fixed data can be stored in program memory and the full 14 bits retrieved. Index registers can be used in linear memory mode to address data memory as banked or linear, and also program memory. Finally introduced an ADDWFC - add with carry - which was missing from older PICs (which made for some arcane arithmetic). And indexing can have pre/post increment/decrement or use an offset.

[Rudolph Riedel]

As it was mentioned I took a peek at the datasheet for the PIC16F1455.
And as expected this thing has an accumulator architecture with only 1 working register.
AVRs have 32 8 bit registers and a couple of these work as pairs for 16 bit operations.
This is why AVRs are quite a lot faster even when a 8-bit PIC runs at four times the clock, there are less cycles
wasted to shuffle data around and a C-compiler has a lot to work with.

Well, I went with ATSAMC21 and ATSAME51 a while ago.
I just installed MPLAB-X 5.50 to give it a try - and MPLAB-X still can not even generate an empty project for ATSAMC21 that compiles.
Still no, I rather swith the manufacturer than going MPLAB-X.


My recent impression is that Microchip stopped releasing anything new that I would actually find interesting.
Like an upgraded ATSAMx5x with Cortex-M33 or an upgraded ATSAMC21 with Cortex-M23.

[commie]

This is why AVRs are quite a lot faster even when a 8-bit PIC runs at four times the clock

Not entirely true, AVR runs 1 clock cycle per instruction, whilst PIC complete 4 cycles per instruction but AVR's run at 2 to 4 times slower than the PIC's, so you might find there's not much in it between the two.

[MIS42N]

The trouble with comparing 8-bit AVR and PIC is they are completely different, difficult to make real world comparisons. I have programmed both in assembler so have a bit of a grasp of what goes on. The 32 registers (AVR) versus one register (PIC) seems like a big win for AVR until you notice the only instruction to move data in and out of the AVR registers is load and store. AVR direct load and store take two cycles (at say 16MHz) versus PIC one instruction of 4 cycles at say 40MHz. PIC wins by a small margin. But use indirect addressing and AVR wins. PIC allows some instructions to work on memory directly (DECFSZ location,f) not using the working register at all. Or combine two operations into one (ASLF location,w - shift left and load). PIC has indexing like the AVR, the 1455 has two index registers very similar to the AVR X,Y registers but with the advantage they are saved during an interrupt and restored on return. And so it goes...

I think AVR would have an advantage using C language, compilers are better at juggling multiple registers than people. But I think there is no clear winner, it depends on the application. I wanted to use an AVR for my application but it didn't have the right abilities. So I chose a PIC instead. A while back I wrote a Top Octave Generator using an AVR, there is no way a PIC would do it. Horses for courses.

[Rudolph Riedel]

This is why AVRs are quite a lot faster even when a 8-bit PIC runs at four times the clock

Not entirely true, AVR runs 1 clock cycle per instruction, whilst PIC complete 4 cycles per instruction but AVR's run at 2 to 4 times slower than the PIC's, so you might find there's not much in it between the two.

You left out the important part when quoting me:

>And as expected this thing has an accumulator architecture with only 1 working register.
>AVRs have 32 8 bit registers and a couple of these work as pairs for 16 bit operations.

So even if an AVR and a PIC need the same amount of time for a single operation that does the same thing,
the AVR still will end up running faster since it can run calculations with 32 registers instead of only one register.
With an accumulator architecture the program spends a significant amount of time pushing data in out of this
one working register while a more modern architecture with more registers can just hold values in these registers.
And less instructions to do the same thing is not only faster, but shorter as well.

When I found the datasheet for a PIC16F84 over twenty years ago in a binder,
I just put back the binder, did not want annother accumulator architecture back then, still would not use any.
I did enough 6502 assembly way back and had to use 8085.