I've had it with Microchip ... they have excellent products, but sometimes they make unwanted and logic-defying changes to their policies and products ...

Anyway ... I am migrating a project that I've been working on from using the PIC16LF1825 to the far more capable PIC16LF18446 which, among other advantages, has double the program memory capacity, much more RAM available registers and uses a single page of code for its entire 14KB capacity.

Now, some of Microchip's datasheets are fairly decent, like the one for the PIC16LF1825. The datasheet is neatly organized and has a nice and clear Memory Map table of sorts, which has proven to be extremely useful for me. And many others of their datasheets are organized in a similar way, which makes them easier to read and quick to browse through when one is in a hurry to verify specific things.

But the datasheet for the PIC16LF18446 is different from the rest. It has an unnecessarily different structure, and does not have a Memory Map. Instead, it has a detailed list at its end (and not at the beginning, as I think it should) that shows each register individually, which is fine by me ... but, I repeat, no Memory Map is anywhere to be seen ... Why the author chose not to include a Memory Map is beyond me, it being such an invaluable tool. So in my desperation, I put together a map myself in an Excel sheet because I knew I couldn't do optimal assembly code without it.

Here's a link for the PIC's datasheet, and I've attached a my version of its memory map for anyone that might be interested. It's the least that I can do for a place that has done so much for me.

 

I've had it with Microchip ... they have excellent products, sometimes they make unwanted and logic-defying changes to their policies and products ...

Anyway ... I am migrating a project that I've been working on from using the PIC16LF1825 to the far more capable PIC16LF18446 which, among other advantages, has double the program memory capacity, much more RAM available registers and uses a single page of code for its entire 14KB capacity.

Now, some of Microchip's datasheets are fairly decent, like the one for the PIC16LF1825. The datasheet is neatly organized and has a nice and clear Memory Map table of sorts, which has proven to be extremely useful for me. And many others of their datasheets are organized in a similar way, which makes them easier to read and quick to browse through when one is in a hurry to verify specific things.

But the datasheet for the PIC16LF18446 is different from the rest. It has an unnecessarily different structure, and does not have a Memory Map. Instead, it has a detailed list at its end (and not at the beginning, as I think it should) that shows each register individually, which is fine by me ... but, I repeat, no Memory Map is anywhere to be seen ... Why the author chose not to include a Memory Map is beyond me, it being such an invaluable tool. So in my desperation, I put together a map myself in an Excel sheet because I knew I couldn't do optimal assembly code without it.

Here's a link for the PIC's datasheet, and I've attached a my version of its memory map for anyone that might be interested. It's the least that I can do for a place that has done so much for me.

IMO the new style Microchip datasheets are crap. I've been told the new style is an artifact of the ATMEL documentation dept. merger from a few years ago.

https://forum.microchip.com/s/topic/a5C3l000000MfdcEAC/t388831

I see that the PIC16 datasheets have taken on more the format of the AVR datasheets... its not bad bad man i'm treasuring the old pic16 datasheets.

I like the AVR, its powerful and far more flexible than the PIC16 but I've never been big on the ATMEL format on the datasheets and always found the Microchip datasheets far easier to grasp. The diagrams and data layout was easier to digest where as the ATMEL datasheets seemed more of a novel, more reading to get to a point or understand it.


This became more apparent now as PIC16 datasheet has moved onto atmel format and I miss the old format, ESPECIALLY the memory map showing all the registers. It gave a beautiful overview of the memory which required no guess work where the registers are and where they are. Yes I know they give the addresses for the registers and there is a register summary at the end (its nice) but its not the same as seeing the entire map on 1 page (or more for larger chips).

Same goes for the over viewed circuit diagrams... they just not the same.

Keep the ATMEL editor with the ATMEL documentation and bring back the Microchip Editor...

 

IMO the new style Microchip datasheets are crap.

I'm sure that many others agree with you ... they are crappy crap, indeed

 

I found a serious discrepancy between the PIC16LF18446 datasheet and MPLAB X IDE (v5.35) list of SFR's

They show different addresses of the STKPTR register:


The datasheet:



MPLAB:




What gives?

 

They are for sure a challenge to get used to. It's not so bad with the 18F chips I've seen it with as you don't have the memory banks to deal with as often which is where the address table helps a lot!! It still would be a help with them in the long run, but it's a lot easier to get used to.

I would chalk up the stack register address issue to a problem with MPLAB. Just a quick glance through a few datasheets I have downloaded over time shows the stack registers at FED - FEF for each one.

 

What happens is that employees who produce the data sheets change, and at best only half of all changes are for the better. Some writers are great, some are not.

 

I'm sure that many others agree with you ... they are crappy crap, indeed

I have also noticed quite a change in the Microchip info/APP notes etc for a while now .

 

I have also noticed quite a change in the Microchip info/APP notes etc for a while now .

Change for the worse ... they're getting sloppy.
When I read their most recent datasheets I get the impression that they are assuming that the reader is already familiar with their architecture's history and evolution.
That is, although all (or most) of the technical details are there, they don't bother to explain the purpose of some features.

I don't think that their documents would be more than 10% larger if they ever did that.

 

Yep ... I've just checked the p16lf18446.inc file in MPLAB's library, and sure enough, the STKPTR, TOSL and TOSH registers are listed at the bottom of bank 64, and not bank 31 as the datashit states.

So their official addresses are:



I still have to test that is actually such the case, though.

EDIT: No, that was not a typo in my spelling

 

And here's another peeve. In every datasheet I've seen so far, the bit that activates the use of synchronized (or clocked) serial communications is called SYNC. And it's also listed as such in this device's datasheet. BUT ... the moment I tried to assemble my program, and error is reported saying that such SYNC symbol was not recognized ... so I opened the #include p16lf18446 file, and sure enough, this is what's shown in the section describing the TX1STA register:



The list shows three different ways in which the SYNC bit can be described. But NONE of them shows the SYNC bit as simply "SYNC" as has been customary in every other Microchip device that I'm familiar with!. Also, the SYNC symbol is not used in any other register!. Why complicate matters in a device that has one single serial coms circuit?!!

Microchip, I hope you have an observer or a spy somewhere in this forum that's taking notice of all these inconsistencies. [\RANT]

 

My guess: if you write C, you don't need to care.


Donchyaknow? No one writes in .asm anymore.

 

There is a dedicated few of us.
Together we stand!
United by the code we use.

 

Unfortunately, to get the very tight pack of code in a small package, assembler is sometimes the only way. In addition, cheap compilers are not always available for some of those weird little processors. And buying an expensive compiler for a one-off project seldom makes much sense.

 

My guess: if you write C, you don't need to care.

If you write in C, you have other cares.

e,n,j,o,y;main(){for(++o;n=-~getchar();e+=11==n,y++)o=n>0xe^012>n&&'`'^n^65?!n:!o?++j;printf("%8d%8d%8d\n",e^n,j+=!o&&y,y);}

 

cheap compilers are not always available for some of those weird little processors.

What are the "weird little processors"?
Compilers for Microchip are free!

 

If you write in C, you have other cares.

e,n,j,o,y;main(){for(++o;n=-~getchar();e+=11==n,y++)o=n>0xe^012>n&&'`'^n^65?!n:!o?++j;printf("%8d%8d%8d\n",e^n,j+=!o&&y,y);}

That is child's play.
https://www.cise.ufl.edu/~manuel/obfuscate/piglatin
https://www.cise.ufl.edu/~manuel/obfuscate/obfuscate.html

 

That is child's play.

Haha the shortest entry I could find in the IOCC contest. There's a wealth of maintenance horror in there https://www.ioccc.org/years-spoiler.html

 

Haha the shortest entry I could find in the IOCC contest. There's a wealth of maintenance horror in there https://www.ioccc.org/years-spoiler.html

C has the same power to express complex functions and ideas with clarity. It doesn't straitjacket you into a safe sandbox.

 

Good programmers have the power to express complex functions and ideas with clarify. C offers an opportunity to bypass that.

It doesn't straitjacket you into a safe sandbox.

'Unsafe' is almost a defining characteristic of the language, it seems.

 

Good programmers have the power to express complex functions and ideas with clarify. C offers an opportunity to bypass that.



'Unsafe' is almost a defining characteristic of the language, it seems.

Even RUST , the latest language of safe programming has a 'Unsafe' mode because low-level systems that interface hardware exposed to random events are unsafe. Yes, C and RUST both give you a way to blow your foot off, the real difference with C is, you don't need to ask permission.

https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
All the code we’ve discussed so far has had Rust’s memory safety guarantees enforced at compile time. However, Rust has a second language hidden inside it that doesn’t enforce these memory safety guarantees: it’s called unsafe Rust and works just like regular Rust, but gives us extra superpowers.

Unsafe Rust exists because, by nature, static analysis is conservative. When the compiler tries to determine whether or not code upholds the guarantees, it’s better for it to reject some valid programs than to accept some invalid programs. Although the code might be okay, if the Rust compiler doesn’t have enough information to be confident, it will reject the code. In these cases, you can use unsafe code to tell the compiler, “Trust me, I know what I’m doing.” Be warned, however, that you use unsafe Rust at your own risk: if you use unsafe code incorrectly, problems can occur due to memory unsafety, such as null pointer dereferencing.

Another reason Rust has an unsafe alter ego is that the underlying computer hardware is inherently unsafe. If Rust didn’t let you do unsafe operations, you couldn’t do certain tasks. Rust needs to allow you to do low-level systems programming, such as directly interacting with the operating system or even writing your own operating system. Working with low-level systems programming is one of the goals of the language. Let’s explore what we can do with unsafe Rust and how to do it.