free-pdk / pdk-includes Goto Github PK
View Code? Open in Web Editor NEWDevice Include files for Padauk MCUs
License: GNU General Public License v2.0
Device Include files for Padauk MCUs
License: GNU General Public License v2.0
How we should deal with small differences between devices , or in another words difference between default periph/xxx and device ?
For example minus input of comparator, on PFS154 GPCC[3-1] '101' is PB7 but on PMS150C is PA7 . by default we have GPCC_COMP_MINUS_PB7 but on PMS150C should be GPCC_COMP_MINUS_PA7 for same value
Create another version of comparator.h ?
add overrides inside device/xxx.h
or maybe create another .h with overrides form default like
override_PMS150C.h
#undef GPCC_COMP_MINUS_PB7
#define GPCC_COMP_MINUS_PA7 (5 << GPCC_COMP_MINUS_BIT0)
This repo need a clearly identified LICENSE so people know what can and cannot be done with it.
@freepdk, my preference for this is MIT, but these files have their roots from easy-pdk-programmer-software (even though they have been changed dramatically from what was/is there) which is GPL v3. Are you ok with (re-)licensing these include files as MIT?
I'm considering adding support for PFC161. For peripherals this should be straightforward; I can look up the register definitions in the datasheet, add them to the device-specific header and if necessary modify the common peripheral headers. But what about code options? Where do you find the values for those?
Also is there anything else to consider when adding support for a new device?
Now that SDCC generates efficient code for assignment from an address that is just a cast integer literal to a __sfr, IMO the asm macros for factory clibration aren't needed anymore.
Inline asm tends to interfere with optimizations, so for larger functions containing a use of factory calibration values, the assignment is likely to result in more efficient code being generated by SDCC.
There seems to be a discrepancy regarding what fuses are supported by the PFS154 between current information on the Free-PDK website, device headers, and currently published datasheet by Padauk.
The website asserts that the PFS154 does not support LVR fuse settings (instead using MISCLVR register), and the pfs154.h device header correspondingly does not include definitions for the LVR fuses. However, according to the datasheet available from Padauk (dated Mar 23, 2023) the PFS154 does feature LVR fuses.
The datasheet also contains no mention of a MISCLVR register.
Is the Free-PDK information incorrect, or has Padauk changed the PFS154?
PMS150G support?
I think the fuse handling as it is now is confusing. It currently works by OR-ing FUSE_RES_BITS_HIGH with the individual fuse settings. I'll further detail my thinking with the PFS173 as an example.
I would expect that calling PDK_SET_FUSE();
would use the factory default values (i.e., no security, strong PB4/PB5, fast bootup). However, it currently sets a mix of factory default and non-default values:
If we later add a #define
for the currently missing code options (such as lvr, comparator, ...), we would also need to change FUSE_RES_BITS_HIGH
. This, in turn, would change the behavior of calling PDK_SET_FUSE();
!
I suggest to rework the fuse handling like this:
#define FUSE_RES_BITS_HIGH 0b111111111111111
#define FUSE_SECURITY_ON 0b111111111111110
#define FUSE_SECURITY_OFF 0b111111111111111
#define FUSE_PB4_PB5_NORMAL 0b111111011111111
#define FUSE_PB4_PB5_STRONG 0b111111111111111
#define FUSE_BOOTUP_SLOW 0b110011111111111
#define FUSE_BOOTUP_FAST 0b111111111111111
// ...
#define PDK_SET_FUSE(f) \
__asm__( \
".area FUSE (ABS) \n" \
".org ("_STR(FUSE_WORD_ADDR)"*2) \n" \
".word ("_STR(FUSE_RES_BITS_HIGH)"&"_STR(f)") \n" \
".area CODE \n" \
)
The macro would now work as expected:
PDK_SET_FUSE();
sets all to factory values, even if we later add definitions for more fusesPDK_SET_FUSE(FUSE_SECURITY_ON);
enabled security, leaves all other values at factory defaultPDK_SET_FUSE(FUSE_SECURITY_ON & FUSE_PB4_PB5_NORMAL);
enabled security and normal I/O, all bootup at factory default.Note that you have to bitwise-and the fuse settings instead of bitwise-oring them. If we don't like that, we could also instead invert the fuse definitions:
#define FUSE_RES_BITS_HIGH 0b0111111111111111
#define FUSE_SECURITY_ON 0b000000000000001
#define FUSE_SECURITY_OFF 0b000000000000000
#define FUSE_PB4_PB5_NORMAL 0b000000100000000
#define FUSE_PB4_PB5_STRONG 0b000000000000000
#define FUSE_BOOTUP_SLOW 0b001100000000000
#define FUSE_BOOTUP_FAST 0b000000000000000
// ...
#define PDK_SET_FUSE(f) \
__asm__( \
".area FUSE (ABS) \n" \
".org ("_STR(FUSE_WORD_ADDR)"*2) \n" \
".word ("_STR(FUSE_RES_BITS_HIGH)" & ~("_STR(f)")) \n" \
".area CODE \n" \
)
(I'm not entirely sure if that is how inline assembler works and if bitwise inverting 0b000000000000000
will lead 0b11111111
or 0b1111111111111111
)
This would allow us to use PDK_SET_FUSE(FUSE_SECURITY_ON | FUSE_PB4_PB5_NORMAL);
I think the HAS_* macro names have a high risk of conflicting with user names (one can easily imagine a programmer choosing HAS_COMP or HAS_ADC for a macro referring to some feature in their software).
Maybe some kind of prefix could help?
I am just in the process of setting up a new project from scratch and am trying to use the most recent includes, which I intendend to clone into my path somewhere. (Before I was just lazy and reused old structures)
It turns out this is quite cumbersome due to the need to put the easy-pdk includes somewhere else. So my suggestion would be to clone or move them also into this repository?
Furthermore, the substructure of the later include path could be reproduced also in this repository. In the example these includes are in the subfolder "pdk", while this is not defined here.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.