That'd be fun...instead of tending the garden someday when/if I retire. And I'd do it for free (my code is that good).

Starting from scratch would be IMO an impossible task -- heck, there are other open-source PIC assemblers that support, what, maybe 5 parts? And an IDE -- including a useful debugger? Not a chance.

I would love for Microchip to open-source their old MPLab/mpasm and put it up on Github. There could be two forks: one to add support for the newer chips to the old 32 bit code base, and another to convert the code base from 32 to 64 bit for use not only on Windows, but Linux as well.

I would participate in such a project. But my contacts over at Microchip are stale. I wouldn't know to whom to make such a request, nor if corporate would allow it.

... a vast project with half-vast ideas.

IMO, the corporate response today is, no support for multiple tool chains and no release of private internal tool chain source code for programs to the public.

 

IMO, the corporate response today is, no support for multiple tool chains and no release of private internal tool chain source code for programs to the public.

And you're not allowed to repair your own car.

 

And you're not allowed to repair your own car.

They all have the same bean counters and lawyers making the rules. If you think that's bad we have suppliers of multi-million dollar tools that will invalidate the operating software on their gear if it's powered down for more than a few days (export controls). Just moving something internally in the same factory can take weeks and cost $100,000+ easily. Obviously it's a hassle even if the vendors don't charge for a new install key so we UPS main control computers in storage and transit for short moves.

 

You guys have no idea how cool this is:



C still sucks, though.

 

You guys have no idea how cool this is:

View attachment 290852

C still sucks, though.

It sucks less as you use it more and stop thinking in ASM.

 

It sucks less as you use it more and stop thinking in ASM.

Dude...I have to keep rewriting the C code to ensure proper compilation into effective .asm.

This takes 10x longer than just writing the damn .asm.

 

...stop thinking in ASM.

I'd just as soon stop breathing.

 

Dude...I have to keep rewriting the C code to ensure proper compilation into effective .asm.

This takes 10x longer than just writing the damn .asm.

This is a long thread (longer than my memory), so forgive me if this has been addressed before…

Why don’t you just write the damn .asm?

 

This is a long thread (longer than my memory), so forgive me if this has been addressed before…

Why don’t you just write the damn .asm?

https://forum.allaboutcircuits.com/...owering-ones-expectations.190219/post-1794077

 

Dude...I have to keep rewriting the C code to ensure proper compilation into effective .asm.

This takes 10x longer than just writing the damn .asm.

Sure, there's a onetime learning curve punching the 8-bit C ticket but you had that once with ASM too.

 

Sure, there's a onetime learning curve punching the 8-bit C ticket but you had that once with ASM too.

Yeah, in 1978 -- as a child.

Way past that.

 

Sure, there's a onetime learning curve punching the 8-bit C ticket but you had that once with ASM too.

And it's got nothing to do with learning except that I learned that many important things that I do in 8 bit asm are completely impossible in 8 bit C.

Edit: if I didn't know .asm, I'd just suspect that the hardware was crippled.

 

https://forum.allaboutcircuits.com/...owering-ones-expectations.190219/post-1794077

Ahh! Ok, you have no reason other than personal stubbornness - which you are totally entitled to. It’s like arguing with my 99 yo mother. Those arguments usually end with. “Because that’s the way I do it!”

 

Ahh! Ok, you have no reason other than personal stubbornness - which you are totally entitled to. It’s like arguing with my 99 yo mother. Those arguments usually end with. “Because that’s the way I do it!”

I'm with Joey on this one ... using C for certain tasks is like using a machine gun to kill a fly. It's the hell of a lot easier to directly tell the MCU what wants instead of having C as an intermediary, and then let it process the code through it's compiler black box and spit out a solution that takes much more code and many more cycles to execute

 

Ahh! Ok, you have no reason other than personal stubbornness - which you are totally entitled to. It’s like arguing with my 99 yo mother. Those arguments usually end with. “Because that’s the way I do it!”

You guys seriously don't get it.

I do things in .asm that simply cannot be done in C.

All I want is a stupid assembler that gets out of my way.

Why should I care that you all think I'm doing it wrong when I run rings around my competition in terms of product performance and cost?

My (and others!) ability to innovate is being compromised by my hardware vendor. That is where the concern should be. Not to C or not to C.

 

using C for certain tasks is like using a machine gun to kill a fly.

No. More like a very slow reloading tank with the tracks shredded.

 

No. More like a very slow reloading tank with the tracks shredded.

... that's a more dramatic way to put it, but ... yeah ...

 

I place into evidence a post I wrote 5 years ago, before I actually did any PIC C development.

Now that I have, I stand by that original statement 1000%.

 

@nsaspook, you ever try to implement UART via DMA-driven circular buffers, including flow control, for indeterminate-sized data streams?

If you have, gimme a hint.

PS -> I wish to scan and process incoming data in-place, as data and CPU cycles become available.

And, I'm trying to avoid per character interrupts and multiple buffer to buffer copies.

 

Using DMA for UART reception like that is tricky. You need a UART with line idle detection.

A good example:
https://github.com/STMicroelectroni...xamples/UART/UART_ReceptionToIdle_CircularDMA

The HAL_UARTEx_ReceiveToIdle_DMA() function allows to handle reception of Data from Hyperterminal
using DMA and notify application of already received data while the reception is still ongoing.
Received characters are handled by DMA and are stored in the user aRXBufferUser buffer.
Notifications to application, that some data are available in reception buffer, are done
through the execution of a user callback : HAL_UARTEx_RxEventCallback().
This callback will be executed when any of following events occurs :
- HT (Half Transfer) : Half of Rx buffer is filled)
- TC (Transfer Complete) : Rx buffer is full.
(In case of Circular DMA, reception could go on, and next reception data will be stored
in index 0 of reception buffer by DMA).
- Idle Event on Rx line : Triggered when RX line has been in idle state (normally high state)
for 1 frame time, after last received byte.

When any of the HT, TC or Idle event occurs, HAL_UARTEx_RxEventCallback() is called,
and provides (as callback parameter) the index in user buffer until which, received data have been stored.

For a PIC32, PIC24/dsp
https://ww1.microchip.com/downloads/en/DeviceDoc/61107G.pdf