Compiler moving to faster micros?

[Ecoli-557]

Hello All-
I have greatly enjoyed learning and working with this compiler, thanks to All who had a hand in it.
I am working on a digital audio project and in it I wish to use a CODEC and it needs a proc with a higher clock such as ARMs or STM32s.
I am wondering if there is any desire/interest/direction in having a compiler which will work in this higher speed procs area?

[RGV250]

Have you looked at 16 bit PICs, they are pretty fast.

Bob

[trastikata]

For DSP it is worth exploring the MAC instructions and the overhead-less loops. FFT can be extremely fast, but to achieve that will require some efforts understanding Assembler.

If you think of employing faster MCU's because of the readily available libraries using high-level commands, this could be very inefficient way to do it, but much easier of course.

[Fanie]

If I do a digital audio project I would rather use a chip dedicated for this type of processing and use the pic to control that.  While it is possible to do anything with a micro, is it worth the time and frustration ?

32 bit has become a standard for many things...

[top204]

When I get the time spare, I am looking at an Arm M0 compiler version. However, this is not something that is knocked up over night. It takes months of dedication and absolute concentration, which does not earn any money, and after that work, the compiler may not make a penny, so months of my time wasted!

It is not the sort of thing that can be done in the evenings of over the weekends either, becuase it is sooooo complex. I am busy studying the Arm M0+ PIC32 architecture when I get the chance to do so. Then there is the code generator functions (many hundreds of them) in the compiler, and the arithmatic and logic functions, that are different to standard devices.

The list goes on....

[JonW]

How long do you think it will take to develop a basic version with IO/register manipulation, clocks, and procedures?

This approach could open it up to user-built functions like the Arduino libraries. This would ease the burden and help promote and develop the compiler.

If you do this and get a basic version running, you can then start an internal Posotron-M go-fund page where we (as users) can support you. At that point, if anyone has a specific or custom function that needs a dedicated command, you can charge for it on a one-off basis or get multiple payments from many users to support the development.

[top204]

It is still early days Jon.

I have a few of the PIC32CM5164JH01032 devices,and I am working with them. They are M0+ architecture, and I can get them to power up, and write some code for them in assembler, which is always the first start, as I need to know how the assembler program works as well. But microchip have nicked the 'open source' GCC compiler/assembler that are also used with the dsPIC and PIC24 devices (and put their name to it), so that is one hurdle that is not as big.

32 bit has become a standard for many things...

Only for those who follow... Not for the creators that get the very best out of what they have. The American way (sorry USA friends), is to make things bigger and bigger, so less work has to be done to get something working, at a cost of waste, and to persuade the followers that "this is what is needed", so they can cash in. A standard example, of many examples, are the PCs and operating systems now? They are not much different in operation to the original ones, but the wastage in them is staggering, and it is the wastage in the O/S that makes them a lot, lot slower than they should be if they were written with more care.

[trastikata]

Not for the creators that get the very best out of what they have.

A very interesting article to support this statement, if you have time, read it to the end.

https://jontio.zapto.org/hda1/dsp.html

[top204]

That is an excellent page Dyanko, and one I fully agree with. Reading his other pages, shows he is one extremely intelligent person. Way above my head with all of his calculations and QAM modulation etc... :-)

The newer 18F K and Q devices are inexpensive, swapable, and very flexible, and the newer 16-bit dsPIC33CK devices have more than enough RAM and flash memory for a microcontroller, and operate at 100 MIPS, with built in DSP hardware.

For the standard 'microcontroller' application, they are way more than is actually needed, because DSP is not required most of the time, and they can toggle and monitor pins extremely fast, and the 16-bit operations, with built-in divide, and multiply, and single clock cycle shift, mnemonics, means that arithmetic and logic operations are performed in them extremely fast. Not to mention the plethora of on-board peripherals, and the useful DMA. However, setting up the DMA can sometimes take more time that the actual use of it, unless large lumps of data are moved around. "Blitted" I think they call it :-)

Large chunks of RAM or flash memory are really not needed in most 'microcontroller' applications, and it is normally sitting there being wasted and taking extra current to do nothing, or flash an LED, or display "Hello World" on an LCD, or monitor a sensor, or two, and store or transmit data. All of which can actually be done comfortably with a small 8-bit device. :-)

For a hobby project or a demo, the faster and bigger the better because it "looks good". But for most "real" microcontroller applications, it is wastage that costs, either in the device price and its surrounding components and design because of its speed, or the power to it etc...

On a side note... As an experiment, I used the DMA on a dsPIC33 device to transfer flash memory data to a colour graphic LCD, and it was very, very fast. So I am going to investigate DMA a bit further when I get a chance.

[Fanie]

32 bit has become a standard for many things...

Only for those who follow... Not for the creators that get the very best out of what they have. The American way (sorry USA friends), is to make things bigger and bigger, so less work has to be done to get something working, at a cost of waste, and to persuade the followers that "this is what is needed", so they can cash in. A standard example, of many examples, are the PCs and operating systems now? They are not much different in operation to the original ones, but the wastage in them is staggering, and it is the wastage in the O/S that makes them a lot, lot slower than they should be if they were written with more care. 

I agree.
When the covid fiasco was in full swing, we couldn't get pics here.  I wasn't going to let my client down and the ESP32-S3 was freely available, so I used that.  I used the 18F45k20 before, and it performed fine and was more than sufficient for the needs at the time.
The customer came back and said he wants me to use the ESP in future.  He liked the way it looked on the board and because he can now say there is a 32 bit processor in it.  As you rightly say, a waste of resources. 
I have however added other functions to the ESP's board for (hopefully near) future expansion and here the ESP will shine.
Also had zero comebacks with the ESP, while with the pic boards we had a few.
Something I do like about the ESP32-S3 is the larger pins, it makes assembly a lot easier.  I made the prototype board and it programmed and worked the first time.  I got the LED not only to blink, but dimmed it too.  Very impressed with myself that a 32-bit micro can do that with an LED 
As for the O/S in PC's, the latest is stupid retarded, especially the memory management is pathetic.  I have to restart my SE drawing program from time to time because the O/S limits the memory it can use, while half the total memory is unused, and setting it in task manager has no effect either.  Makes the I7 performs worse than the I3 on win7 
That is one thing "includes" do, it has to cater for various author's functions, the same way the O/S is created by various author's, and it becomes plump and fat.  A bit like the phones we have, they can do everything except make a proper phone call.

[flosigud]

Are these 32 bit micros really faster than 100 mips PIC? I'm not sure when you take into account all the hardware. Few years back I saw a comparison between few 32 bit micros and a 16 mips 16 bit PIC. The PIC lagged behind in all categories but multiplication where it was above average. A 100 Mips PIC would have aced the competition.

Now it seems to me that majority of Positron users stay with 8 bits, so in my opinion more support for the 16 bit hardware would be more useful. At lest for me.

[Fanie]

If you can believe AI...
The ESP32-S3 boasts a dual-core Xtensa 32-bit LX7 microprocessor with a clock speed of up to 240 MHz, offering a significant performance boost over earlier ESP32 models. It also supports Wi-Fi (802.11 b/g/n) at 2.4 GHz with a 40 MHz bandwidth and Bluetooth Low Energy (BLE) with various speed options, including 2 Mbps PHY for higher data throughput. The ESP32-S3's PSRAM/FLASH throughput is also improved, reaching a maximum of 240 MB/s, a 6x increase compared to the standard ESP32.

Xtensa® dual-core 32-bit LX6 with 600 MIPS (in total); 200 MIPS for ESP32-U4WDH/ESP32-S0WD (single-core variants); 400 MIPS for ESP32-D2WD

There will always be another coming from somewhere that is faster, it's a never ending competition.
I like to think more in terms of how easy and will it do what I want for how inexpensive.

Let me add.  These 32 bit micro's use the same instructions as the 8 bit.  To optimize the 32 bit capabilities, a new instruction set will have to be developed to fully use the full capability.  THEN it will be really fast.

[SeanG_65]

The new dual core PIC's hit 100MHz!

[Wimax]

The new Dspic33ak series, set as the successor to the Ck series in Microchip's roadmap, includes 200 MIPS microcontrollers with integrated FPU and, a fact to be thoroughly investigated, support for 16-bit mnemonics.

[Fanie]

The duel-core ESP32-S3 also features an independent co-processor and is very fast.

This is the only non-pic micro I like.  Remember I grew up on pic's, and I was one of the first in Sick Africa to start using them.  They were big, small memory, UV erased back then and I wrote code in assembler. The only windows we had back then was the UV erase window on the pic's.
PC's were DOS operated with Kb sized hard drives and magnetic floppy discs. A slow and cumbersome process.  The largest project I did was an 8 x 8 disco light which "played" patterns and it worked. I also remember I had a hot date with a nice chick once and I got arc eyes from the UV, so I was pretty useless during that date and gives new meaning to "early retirement".

For most applications you do not need a very fast pic, and the peripherals also make it easier.
The new pics are very easy and quick to use, you just program any changes in the software in seconds.
The most difficult part is probably to convince yourself to use the manual (data sheet)

While I was thinking this over, something else occurred to me.
2^8 = 256
2^16 = 65 536  (Challenge - start counting, see how long it takes you to get there)
2^32 = 4 294 967 296
2^64 = 18 446 744 073 709 551 616  (pronounce this !)
So if you have a micro counting down a 64-bit register, how long will it clock for an overflow interrupt ?  Work it out... !

Also, as you can see, I'm nearing a 64-bit year age with an 8-bit bank account

[Sommi]

I'm sorry but this is one of the categorie "grandpas talk of war"

In 1989 I got the first 16C54 and 16C56s.

I then did a true sinewave power inverter 12V to 230V 50 Hz, 500W (with triple overload) with the PIC16C56 (the 16C54 with only 0.5K ROM was too small). It had sigma delta PWM for the Mosfet full bridge power stage and sigma delta A/D conversion with help of an LM324. Also fast current limit, thus short circuit proof. Sinewave filter was made from exorbitantly expensive MPP cores.

In order to achieve the 50 HZ I had several meter long assembly listings on the floor, counting commands and adding nops to get the 50 hz.

The 25 registers had some double use for obvious reasons.

We then manufactured some 300 pcs. of this inverter, many more to follow with PICs more and more sophisticate.

So much for nostalgy

Sommi

[top204]

I am working on the dsPIC33AK devices, but they are rather dreadful, and seem to be a university degree students's experiment to try to make a PIC 'Harvard' architecture device into an Arm 'type' device, now that they have bought an Arm licence when they bought up Atmel for it. And this is somethng you cannot 'ever' rule out with microchip. :-)

I'm having quite a few problems, because microchip are keeping data for them under-wrap, and all code is locked in 'libraries', and even the standard data files for them are very shallow in details. Not to mention, the assembler instruction manual for them is actually the instructions for the earlier ASM30 assembler, which is very different, so I am having to nit-pick (examine in the dark) what is the correct syntax for some things, and I have not worked out how to manipulate the config fuses yet, because the names and address' and syntax are all wrapped and hidden!

microchip are determined that people only use their, 'actually re-named open source', dreadful C compilers, which are very poor in assembler code quality, as I have found out by looking at code snippets the latest C compiler has produced for a dsPIC33AK32MC102 device. I tried this so I could get an idea of how to work around some of the important SFRs and mnemonics that are 'missing' from the devices, for some inexplicable reason! And to see what syntax is required for some items, because it is not written down!

For example, none of the WREG SFRs are memory mapped, and neither is the STATUS SFR (named SR in dsPIC33 and PIC24 devices). Why would anyone with a single brain cell remove the most important SFRs from the memory map, so they cannot be read or written directly? That is going back 30 years to the days of the 16C, 8-bit, type devices??

Also, there are no Bit Test and Skip mnemonics, so instead of a single Btsc or Btss mnemonic, two mnemonics need to be used, so the bit is tested, then branched over if it is true or false. Utter stupidity, and again, going back 3 decades to the original 8-bit microprocessors that did not have them either!

As I mentioned above, the C compiler is dreadful, and to illustrate that, I compiled the simple code snippet below:

Code Select Expand

if(PORTBbits.RB0 == 1)
  {
      Byteout = 100;
  }

Which should be a bit test and a branch, or a single 'bit test and skip' mnemonic depending on what is inside the comparison. However, the C compiler actually produced the code below:

Code Select Expand

    mov.w _PORTBbits,w0
    mov.b w0,w0
    and.b w0,#1,w0
    sub.b w0,#1,[w15]
    bra   nz,.L2
    mov.b #100,w0
    mov.b WREG,_Byteout
.L2:

I could not actually believe what I was seeing! It is absolutely horrendous with all of its pointless loading of W0, and the Anding of the bit to test, then a subtraction to alter the Z flag, for the actual test, and 'horrendous' is putting it lightly. Why load W0 into W0 with "mov.b w0,w0", when the W0 register already contains the value held in PORTB by the previous mnemonic; "mov.w _PORTBbits,w0", and the mnemonic itself serves no purpose whatsoever? If it was loading a section of the 16-bit PORT, or sign extending the value, it could be understood, but as it stands it serves no purpose at all, except bloat!

Can you imagine the size, and loss of speed, of a finished program with this type of code bloating everywhere. However, that is 'standard practice' with the majority of C compilers. Especially the GCC compilers.

It should be something like:

Code Select Expand

    btst.b PORTB,#0
    bra NZ,1f
    mov.b #100,W0
    mov.b WREG,Byteout
1:

Which is what the Positron16 compiler will produce!

I also have a big problem in that I do not have a programmer that can program the dsPIC33AK devices, so I am busy saving up for one.

Regards
Les

[John Lawton]

Oh dear, maybe I'll have to produce a version of the Amicus for this range - when things become clearer maybe.

As an aside, isn't it odd, no matter how fast the hardware, the OS seems to move like a dog. I'm thinking of a Windows 11 laptop I tried recently...

But seriously if the code is inefficient, the extra hardware speed is being thrown away.

John

[top204]

Unfortunately John, and I appologise to my American friends. That is the "American Way", and came into play with computers in the late 1970s and early 1980s, then got out of control with crapple, micro$oft and the 'Intel' type 'Personal Computers', and it has continued onwards and is actually getting worse.

The American way, is: Make it easier to design and build by just adding more and more and more, because studying and taking time to do it with more detail and efficiency does NOT make more "money", and the sheep can be milked more and more, because they can be brainwashed into thinking more is actually needed, and forced into getting newer devices by making the software that runs on it, less efficient!

Bring back the days when an item was learned thoroughly and could be made to do things that defied its architecture, because it was absolutely understood! But that did not make enough money from the sheep. :-) And unfortunately, virtually, all marketing and items, from all countries use the 'American Way' now, and people actually think that way now because it takes less work in studying and understanding. :-(

I know that for certain, because I've worked for some companies that do it.

[RGV250]

Hi Les,
I am not sure if I have a Pickit4 or one of these
https://www.mouser.co.uk/ProductDetail/Microchip-Technology/PG164100?qs=w%2Fv1CP2dgqoaLDDBjfzhMQ%3D%3D&mgh=1&vip=1&utm_id=20797887765&utm_source=google&utm_medium=cpc&utm_marketing_tactic=emeacorp&gad_source=1&gad_campaignid=20808116062&gbraid=0AAAAADn_wf3TI-oxiNvXDhIKog3-vFi0Z&gclid=Cj0KCQjw0LDBBhCnARIsAMpYlAqEQQpqgAejd_7vZF35bmdg7myO3HhuPt3sSJ7tKREHUaZd6uTSw9saApneEALw_wcB
I got it and then never used it as it seems absolute garbage against the Pickit2.
I will try to find it as it is buried deep but you are welcome to it if it helps.

Regards,
Bob