I saw it today. Looks like massive work! Is it synthesizable? This could be the foundation for an open-source in-circuit emulator based on any cheap FPGA board. It would ease development for the OTP variants a lot.
I wonder, what is so peculiar about the PFS154 interrupts? Since every instruction is executed in one or two cycles, the interrupts should be fairly quick and with low jitter?
I saw it today. Looks like massive work! Is it synthesizable? This could be the foundation for an open-source in-circuit emulator based on any cheap FPGA board. It would ease development for the OTP variants a lot.As of now, it is not synthesizable. Mainly because there are a few open questions regading the microcontroller implementation (see the toplevel README, I have a few questions there that need to be answered).QuoteI wonder, what is so peculiar about the PFS154 interrupts? Since every instruction is executed in one or two cycles, the interrupts should be fairly quick and with low jitter?They are quick... but it's hard to understand if you can keep up the pace when the interrupt sources come at only a few microsseconds apart. Simulating this at a lower level allows you to test several scenarios and evaluate whether your design will work or not. What I can tell you is, my first version which was implemented in "C" and built with SDCC was *not* able to keep pace. I found this during simulation, and simulation helped me optimize the (now in assembly) code.
There is something peculiar about how SDCC generates the interrupt handler, though. I ended up with the following sequence which was non-optimal (in addition to the goto statement due to memory location, I presume)
pushaf
mov a, p
pushaf
// Interrupt code
popaf
mov p, a
popaf
reti
I did not require modification of A for the most important part of the interrupt routine. And definitely not using "p". 6 less instructions to execute, 750ns saved. Quite important when you have 3 us between interrupts, and you need to serve them quickly because you need to sample pins from within the interrupt routine.
Alvaro
__sfr __at(0x03) clkmd;
__sfr __at(0x0d) padier;
__sfr __at(0x0e) pbdier;
__sfr __at(0x10) pa;
__sfr __at(0x11) pac;
__sfr __at(0x12) paph;
unsigned char _sdcc_external_startup(void){
return 0;
}
void main(void){
paph = (1<<5); // Enable pull-high
pa = 0; // HI
pac = (1<<0); // Enable output
padier = 0;//(1<<5); // Enable PA5 wake up event
while(1){
if((pa&(1<<5))) pa |= (1<<0);
else pa &= ~(1<<0);
}
}
Hi again.
I have 2 questions.
1. I can't read input when PADIER = 0. Tested with PFS154.
Is there some kind of bug, or I'm missing something in the documentation?
2. I got strange 2x speed difference between PFS154 and PMS150C.
Both set to 0x80 in IHRCR. PMS150C is 2 times slower (pwm speed and instruction execution time).
I need to set IHRCR really high (0xDA) to get the same results. Is it normal?
Is there a IHRCR factory calibration value for PMS150C in memory?
No bug. Just like it is. If you want to use a pin as digital input you have to enable the digital input pin in PxDIER = "Port x Digital Input Enable Register".
Also nothing strange here. This is just how the ICs are manufactured (big variance from batch to batch from IC to IC).
No bug. Just like it is. If you want to use a pin as digital input you have to enable the digital input pin in PxDIER = "Port x Digital Input Enable Register".Thank you for answer.
I thought PxC register is input/output switch and PxDIER is for wake up enable. There is nothing about input in bit definitions.
"Enable PA7~PA3 wake up event. 1 / 0 : enable / disable.
These bits can be set to low to disable wake up from PA7~PA3 toggling."
There is also nothing about it in "IO Pins" chapter.
"...all the pins can be independently set into two states output or input by configuring the data
registers (pa), control registers (pac) and pull-high registers (paph)......
If user wants to read the pin state, please notice that it should be set to input mode before
reading the data port....
When PMS15A/PMS150C is put in power-down or power-save mode, every pin can be
used to wake-up system by toggling its state. Therefore, those pins needed to wake-up system must be set to
input mode and set the corresponding bits of registers padier to high."
Only after analyzing "Hardware diagram of IO buffer", the reader may state that the description is incorrect.
The behavior of the chip also does not match the mentioned diagram. Read is always HI when PxDIER is LOW. If there is an AND gate, the read should be LOW.
Padauk put this AND gate in wrong place. It's a bug.
Thanks for the code. I seem to have an endianess problem somewhere.
I am using linux, but the IDE doesnt work with wine.
So I used windows to make and convert the file. Somehow bytes got swapped
Taiwan-based MCU maker Padauk Technology expects its shipments of MCU products to grow by over 20% on year to reach 1.3 billion units in 2020, according to company Tang Tsan-bih.
Despite growing concerns about the stability of related supply chain caused by the coronavirus outbreak, Tang said that he believes demand for MCUs will remain strong, particularly from sectors including 5G base stations, servers and other cooling fan systems.
Boasting a group of strong supply chain partners, including Magnachip Semiconductor and Powerchip Semiconductor Manufacturing (PSMC) for wafer foundry and Greatek Electronics for IC backend services as well as inventories of needed components for up to three months, Padauk is readied to support product roll-outs of its clients, Tang stated.
For individual product category, shipments of 8-bit MCUs for BLDC (brushless DC) motors will account for about 30% of its totals sales in 2020, up from 23% a year earlier, Tang revealed.
Meanwhile, the company is also expected to see its shipments of MCUs for TWS (true wireless stereo) devices expand significantly in 2020, having shipped about 20 million units to the sector in 2019, according to an estimate of industry sources.
The sources also estimated that Padauk will see its 2020 revenues grow over 10% from the NT$522 million (US$17.17 million) it recorded a year ago.
Shares of the MCU maker is scheduled to debut on Taiwan's OTC securities market in the second half of March.
#define ROP_TMX_6BIT 0x00
#define ROP_TMX_7BIT 0x10
#define ROP_TMX_16MHZ 0x00
#define ROP_TMX_32MHZ 0x20
#define ROP_PURE_PWM 0x00
#define ROP_GPC_PWM 0x40
#define ROP_PWM_16MHZ 0x00
#define ROP_PWM_32MHZ 0x80
JS, I want to know how we enable options in the SDSC, for example in the PFS173 Datasheet there are these options regarding clocking tim2 and Comparator usage,
GPC_PWM which can Enable Comparator controls all PWM outputs, and TMx_Source When tm2c[7:4]= 0010, TM2 clock source = IHRC*2 = 32MHZ and PWM_Source When Pwmgclk.0= 1, PWMG clock source = IHRC*2 = 32MHZ
There are these defines in the pfs173.hQuote#define ROP_TMX_6BIT 0x00
#define ROP_TMX_7BIT 0x10
#define ROP_TMX_16MHZ 0x00
#define ROP_TMX_32MHZ 0x20
#define ROP_PURE_PWM 0x00
#define ROP_GPC_PWM 0x40
#define ROP_PWM_16MHZ 0x00
#define ROP_PWM_32MHZ 0x80
how we should use them? I want to change the TIM2 clock to 32MHz and use the Comparator to control the PWM.
Take a look at this picture from the PFS173 Datasheet
Thanks
Thanks JS, I want to do a simple buck controller with these options, have you done any DC/DC converter with these padauk MCUs?
Also there is nothing mentioning ROP register in the Datasheet, how did you find it?
You also can get rid of the 2 extra cycles from the GOTO statement in case you manually instruct SDCC to place your interrupt code directly to the right position.