Padauk PFS154 - getting started

[zitt]

I'm trying to get up to speed on the Padauk microcontrollers... but have hit a brick wall in my understanding and was hoping someone could help me get the basics down.

Specifically; I've done a little playing around but haven't gotten very far because I seem to be lacking some key pieces of information. I went to lcsc a few months ago and bought an emulator (5S-1-S-2b) [ https://lcsc.com/product-detail/Emulator_PADAUK-Tech-5S-I-S02B_C394018.html ] and some sample parts.  LCSC did not have any programmers available for sale. For this project; I'm opting for the PFS154-s16 since I expect to be working thru some initial learning curves and don't want to be throwing away a lot of OTPs. For this project; I need all those IOs for various circuit functionality.

I've tried doing a couple of "emulated" projects. Once starting with
https://abnielsen.com/2019/04/24/driving-300-ws2812b-rgb-leds-with-a-3-cent-microcontroller-pms150c/
WS2812b project ... talked about here:
https://www.eevblog.com/forum/microcontrollers/i-rainbowed-300-neopixels-with-a-pms150c-d

I started with that project on the emulator because in my project; I'll be driving those LEDs. The project "sorta" worked; but it was having trouble driving the WS2812 strip... which I assumed was just due to user error.

Tonight; I wanted to start with a simple project which I could use as a spring board to launching into my own project. So I downloaded the "Hello World" demo from:
https://github.com/free-pdk/simple-pdk-code-examples/tree/master/HelloPFS154

When attempting to run this demo on the emulator; the serial stream is corrupted. I can't ready the output of PA7 with my FTDI serial nor can my Agilent Scope decode the serial stream at 9600 baud.

Given both of these projects don't work as-is out of the box... makes me think I'm doing something stupid, missing something key, or just plain misunderstanding the purpose of the emulator. I'm wondering if there is a emulator vs real silicon "difference" that I've missed in the manuals. IE the emulator runs at a different speed or something.

Can I use these projects AS-IS on the emulator? IE isn't the purpose of the emulator of "in circuit" emulate the uC in an actual system? Do I need to make project changes to target this specific emulator? My assumption is no; since there doesn't seem to be a .CHIP directive for the emulators.

My project goals are as follows:
Use the emulator to debug/single step thru my development of the firmware to have a ?ideally? bug-ish free implementation when I move to the real PFS154-SO16 part. I have built a easyPDKprogrammer ( https://github.com/free-pdk/easy-pdk-programmer-hardware) ; but I haven't even powered it on to load the firmware onto it.
Initially; I thought I would be able to program a PDK project onto the chip using the free PDK programmer but now I'm not so sure... and wondering out loud if I'll then have to port my working emulated code to SDCC. 

But I digress. Step one is to make sure I can do simple stuff... like target for the emulator. What am I missing?

[js_12345678_55AA]

Hi,

without looking into it in detail you should read the data sheet of the IC (last section). PADAUK emulator has a lot of restrictions what can be done and what not. Most of the time timers are limited to a much lower speed, some IOs don't work as expected, ...

From PFS154 data sheet, last page, section "9.3 Using ICE" (which is the "emulator"):

* PDK5S-I-S01/2(B) doesn’t support SYSCLK=ILRC/16
* PDK5S-I-S01/2(B) doesn’t support the dynamic setting of function misc.4(Only fix to 0 or 1)
* PDK5S-I-S01/2(B) doesn’t support the output of PW MG2C.PA5
* PDK5S-I-S01/2(B) doesn’t support the function Tm2.gpcrs/Tm3.gpcrs
* The PA3 output function will be affected when GPCS selects output to PA0 output.
* Fast Wakeup time is different from PDK5S-I-S01/2(B): 128 SysClk, PFS154: 45 ILRC
* Watch dog time out period is different from PDK5S-I-S01/2(B):

And yes, SDCC (as a free open source tool chain) is what we are using and is what you need to write your code for.
The very limited PADAUK IDE compiler code can NOT be used with EasyPDK-Programmer.
Unfortunately there is no way to use the ICE with SDCC code at the moment.

In case you really want to use the ICE for development best solution for you would be to get the official programmer.

JS

[zitt]

yes, I saw those references - but they don't appear to be applicable to the HelloWorld demo.
Hello World uses the TM2 timer... but I don't see "Tm2.gpcrs" in the source. I will go look to see what that functionality is to confirm.

I don't like the idea of using the minic compiler... would rather use SDCC. But the problem with SDCC is there really aren't any debug tools to help prove the source is working right nor is there an ICE solution. (correct me if I'm wrong).

So right now; I see the struggle is:
Learn miniC... and buy a programmer... but I have to figure out why ICE isn't functioning right.
or
Learn SDCC... validate the easy Programmer is built correctly... and brute force develop the source.

for the latter; my concern is that development for SDCC would result in an intel hex file... that wouldn't be usable for volume programmers if my design is build in medium volumes.

[greenpossum]

for the latter; my concern is that development for SDCC would result in an intel hex file... that wouldn't be usable for volume programmers if my design is build in medium volumes.

Why would hex files be a problem? You can convert to other formats like binary if that's what your programmer wants.

[brucehoult]

for the latter; my concern is that development for SDCC would result in an intel hex file... that wouldn't be usable for volume programmers if my design is build in medium volumes.

Why do you say that?

[zitt]

My assumptions is that "officially" the only program to support the PFS154 is the Padauk programmer...and that most resellers/programmers would be using the default programmer. It's unlikely that they would be using an intel hex format if unsupported by the official programming device.

That said; do you guys have specific information to the contrary?

[retrev]

I've ordered parts for the Easy PDK programmer and I'd rather not have to build adapters as well since I'd have to source zif sockets elsewhere anyway. In the recent padauk series Dave used some adapters he already had on hand from another programmer which seemed to work. Does anyone have a source for similar adapters already assembled? Or maybe someone's got some extras already assembled that they could sell me?

[brucehoult]

My assumptions is that "officially" the only program to support the PFS154 is the Padauk programmer...and that most resellers/programmers would be using the default programmer. It's unlikely that they would be using an intel hex format if unsupported by the official programming device.

That said; do you guys have specific information to the contrary?

And what format does the official programming device want?

It used to be reasonably common to see things wanting Motorola S-record hex format, but I haven't seen that in decades. Some things may want elf, but that's a trivial conversion. Or maybe they made up their own format for no particular reason.\

It really doesn't matter, it's all just a list of "set the byte at X address to Y value", so any conversions are trivial.

But they probably use Intel hex like everyone else.

[oPossum]

The official tools used an encrypted binary file. The encryption algorithm is known, so it is possible to convert to/from that and anything else. Details are in the lengthy Padauk reverse enginerring thread. The catch is that the programmer does some calibration of the MCU that involves code generated by the tools. The official Padauk tools differ from the open source tools. There is currently no solution for this.