How to start

ManAtWork · 2019-12-11 10:03

Although I have quite a lot of experience with the P1 I'm totally new to the P2 and I haven't followed all the discussions here. So I'm trying to gather as much information as possible to be able to play a little bit and hopefully start my first P2 project, soon. Sorry for starting a new thread with questions that have surely been asked before many times. But all the answers are hard to find and scattered around the forum. And hopefully others find it also useful to collect them here.

I've already found the data sheet: https://docs.google.com/document/d/1gn6oaT5Ib7CytvlZHacmrSbVBJsD9t_-kmvjd7nUR6o/edit?usp=sharing

Is there a "minimum example schematic" somewhere? I mean, what is the minimum configuration (absolutely required external parts) to run the P2? crystal, voltage regulator, flash ROM, download/debug connector?

I've seen Parallax sells engineering samples
https://www.parallax.com/product/p2x8c4m64p-es-4
but I've found no Eval board. Is this one the only one available, right now?
http://forums.parallax.com/discussion/170695/p2d2-with-p2-revb-taking-orders/p8
It's no problem for me to make my own boards. It would just speed up getting the first prototype a bit.

What software do I need if I'd like to start with Spin, Assembler and C programming? I'm focussed on embedded realtime applications so I currently don't need an OS, video, filesystem etc.

In a realtime system a single step debugger is not of much use. On the P1 I used a simulator so I was at least able to test complicated math code in assembler. Debugging on the live system was done by sending prints or binary data over COM port to some scope software I've written by myself on the PC. I've heared the P2 has some hardware debugging features. Is that already supported?

I fear I can't really tell if everything works as I expect before December 17th which is the deadline for ordering larger quantities of P2 chips until October 2020. But I'm optimistic and consider ordering at least one tray.
http://forums.parallax.com/discussion/170919/order-p2x8c4m64p-now-for-april-delivery-up-to-990-units-per-customer#latest

ersmith · 2019-12-11 12:21

ManAtWork wrote: »

I've seen Parallax sells engineering samples
https://www.parallax.com/product/p2x8c4m64p-es-4
but I've found no Eval board. Is this one the only one available, right now?
http://forums.parallax.com/discussion/170695/p2d2-with-p2-revb-taking-orders/p8
It's no problem for me to make my own boards. It would just speed up getting the first prototype a bit.

They did have an eval board (https://www.parallax.com/product/64000-es) but it looks like it's sold out right now. I would think that when they get more chips they'll probably make more eval boards.

What software do I need if I'd like to start with Spin, Assembler and C programming? I'm focussed on embedded realtime applications so I currently don't need an OS, video, filesystem etc.

Personally I would suggest starting with FlexGUI, which has PASM, Spin, BASIC, and C support in one package, and also comes with a demo of micropython. But I'm biased, since I wrote it

.

Other good choices are Tachyon FORTH (it's a very complete system and probably more mature than any other tools available right now) and Catalina C (a C89 compiler that was originally on P1 but now has P2 support).

In a realtime system a single step debugger is not of much use. On the P1 I used a simulator so I was at least able to test complicated math code in assembler. Debugging on the live system was done by sending prints or binary data over COM port to some scope software I've written by myself on the PC. I've heared the P2 has some hardware debugging features. Is that already supported?

@ozpropdev has done some work on debugging, but I don't know the current state. There is a P2 simulator (the somewhat misnamed "spinsim", which can also simulate P1).

Regards,
Eric

potatohead · 2019-12-11 13:11

I second FlexGUI. It's probably the easiest get going option right now. Truth is, you can plug in your eval board, when you can get one, open a blinky example, and hit the "compile and run on P2" button to kick things off.

Right after that, run one of the examples that sends text back through the serial / USB connection and you are off to the races.

VonSzarvas · 2019-12-11 13:49

There will be a limited quantity of Eval boards back in stock, likely to be either the last week of December or first working week of January.

Attached is a schematic of the most basic parts needed to get going, apart from the power supplies.

The SPI Flash memory chip could be replaced with an SD card socket instead (use the same pinout as for the flash chip, but swap the CS and CLK pins).

Edit: Attached schematic updated with link to documentation for the Propeller 2 chip footprint and ground pad information

ManAtWork · 2019-12-11 16:28

Ok, thanks a lot. From the "getting started schematic" I can guess that a standard P1 prog-plug should also work for downloading binaries. There are no ground pins except the exposed pad?

I'll use the AP3402 step-down regulator for the 1.8V and an LDO for 3.3V. And I've just ordered 4 ES chips. No patience to wait for the eval boards...

And I've found the Eval board schematics. https://www.parallax.com/downloads/propeller-2-es-eval-board-schematic
Unfortunatelly, the types/values of the ICs are missing, so I can only guess. Any SPI flash with at least 512MB = 4Mb works? So I could take the AT25SF041 or MX25V4035 oer AT25SF081 if I want some spare memory for data storage?

VonSzarvas · 2019-12-11 16:46

Standard PropPlug is good.

Your right about the ground pad- and thanks for the feedback; I'll make that clearer on the schematic.

The last page if the RevA schematic includes a full BOM. The flash IC was the same for RevB.

evanh · 2019-12-11 16:58

Von,
You changed a lot with the regulators I think and definitely the USB power handling.

VonSzarvas · 2019-12-11 17:04

evanh wrote: »

Von,
You changed a lot with the regulators I think and definitely the USB power handling.

That's true. I'll see about getting the RevB bom added to that schematic file. I thought it was "out there"; memory can be a funny thing sometimes!

evanh · 2019-12-11 17:18

Not sure where I got it from but I've got this stashed in me downloads. EDIT: Ah, it's from the Diptrace zip file ...
https://www.parallax.com/downloads/propeller-2-es-eval-board-design-files

VonSzarvas · 2019-12-11 17:53

Ah ha! That's the one. So it was tucked away with the sources. Good stuff.

Thanks evanh!

Rayman · 2019-12-11 18:38

In case you use Eagle:

I posted the design files for my P2 board here:
https://forums.parallax.com/discussion/170725/my-first-p2-pcb-its-alive/p1

I made a couple mistakes, but they were fixed in the files that are posted.

Cluso99 · 2019-12-11 19:55

@ManAtWork,
If you design your own pcbs, take a look at what the pullups and pulldowns do on pins P59-61 for booting the P2. You might need these to be linkable for your testing, and for security too as you can prevent downloading. Its not foolproof tho.
You can probably get a P2D2 board(s) from Peter - he’s assembling atm.

I forgot, use Eric’s Flexgui for compilation, and/or look at Peter’s TAQOZ - there is a version built right into the P2s ROM

And for testing, theres my monitor/debugger in the ROM which allows dumping cog/lut/hub etc.

Peter Jakacki · 2019-12-11 23:29

If you want a minimal schematic and the datasheet (not the P2 documentation), then click the "P2 SHORTFORM DATASHEET" link in my sig.
If you want a more complete schematic (that stills fits on one page) then have a look at this one for the P2D2 (r3). Plus I have attached the datasheet anyway.

Tubular · 2019-12-11 23:43

Peter it would be good to get the RESn pullup resistor shown on the shortform schematic (you do describe it in the text comments)

I think its going to catch people out, if those people are used to P1's internal RESn pullup (or other micros)

Peter Jakacki · 2019-12-11 23:55

Tubular wrote: »

Peter it would be good to get the RESn pullup resistor shown on the shortform schematic (you do describe it in the text comments)

I think its going to catch people out, if those people are used to P1's internal RESn pullup (or other micros)

Yes, thanks for the heads-up, I was thinking I needed to update that!

ManAtWork · 2019-12-16 08:53

Peter,

many thanks for the documentation. I'm currently routing my first P2 PCB layout... One question: The short form data sheet list the ePad dimension as 10.3mm as the full datasheet says 9.6mm. Which one is correct.

I don't know if it matters much but I found out that at least smaller QFN packages are auto-centered better if the ePad is corrently sized.

Peter Jakacki · 2019-12-16 09:26

The exposed pad is 9.5 but the pcb pad should be 9.6. I made up a datasheet at the time because I had to scrounge around for all this information and create some graphics for it as well. So I will update the datasheet accordingly.

ManAtWork · 2020-01-04 17:51

Another beginners question: Where can I find a language definition for Spin2, or at least some explanation of the differences to Spin1?

I know there are those discussions about FastSpin and FlexGui, but I don't want to read 1000s of messages. I've read the forst pages but, unfortunatelly, there's little useful information for the newcomer...

potatohead · 2020-01-04 18:07

Spin 2 is in progress. Chip is in progress, posting things as they develop.

You can find Spin 2 vs Spin 1 differences as proposed and implemented by @ersmith in FastGUI. Most of us are considering that as a forward looking look at Spin 2 that is useful today.

That, plus your Propeller Manual, found in the menus of PropTool, or as a download from Parallax are pretty good to get started.

Spin basics are likely to continue to work just fine. Some operators have changed. See the fast GUI doc for a quick reference.

Spin 2 features may see change for some time yet.

I am working in PASM and Spin, keeping it simple for code I want to use in the future. I use Pnut and FastGUI currently.

ManAtWork · 2020-01-07 12:40

potatohead wrote: »

You can find Spin 2 vs Spin 1 differences as proposed and implemented by @ersmith in FastGUI.

Shame on me. I was too stupid to find it, but now I did. The language definition or at least the differences/extensions are described in "spin.pdf" in the "doc" folder of FlexGui. I've first looked in "fastspin.pdf". It contained no language definition but only the command line parameters and some general info about the compiler. I was disappointed and didn't look further.

potatohead · 2020-01-07 16:12

No shame, just ONWARD! Glad you are set!

ManAtWork · 2020-01-08 15:57

OK, I managed to write my first spin2 program (in FlexGui). Well... actually it's not really mine, I just modified the blink example to fit my board pinout and crystal.

Compiling and running from RAM works. Writing to flash also works, at least the programmer says

P2-ES Flash Programmer
Erasing flash...
Programming...
Done

But the P2 doesn't boot from flash when I cycle power. What can be wrong? I have the EEPROM connected as shown in Peter Jakacki's P2 shortform.pdf:
P61 to /CS with pullup, P60 to SCK, P59 to SI, P58 to SO. The EEPROM is a MX25V8035FM from Macronix. I hope it is compatible. I remember Chip said something like "all SPI flash chips support the same read command. They only differ in page size and write commands." So I think if writing works then booting should also work...

ManAtWork · 2020-01-08 17:35

I have to learn P2 assembler and how the smart pins work...

Can somebody please tell me what that new addressing modes mean? OK, "#" is immediate, but what does "##" and "#\" mean? There are even more confusing patterns like "#\@ " and "##@ ".

Dave Hein · 2020-01-08 18:08

# indicates an immediate value, such as mov x, #123
## indicates a 32-bit immediate value, such as add x, ##123456
\ indicates that an absolute address should be used, such as jmp #\label
@ causes the hub address to be used, such as long @label

evanh · 2020-01-08 21:42

\ was mostly used in sources historically to work around a bug in Pnut. I'm not sure if Chip has fixed the bug either. I've transitioned to fastspin and since removed such uses.

@ is important in two ways: Firstly, it provides the byte offset into the binary file as compiled/assembled. This matches where a loader will put the binary in hubRAM at runtime. Secondly, because it is always byte sized offsets this allows a defined way to know lengths of static data in the binary. PS: Eric has an extension to this with @ @ for compiled code, I'm not sure what the difference is.

EDIT: Had to place a space between the two at's to stop the forum software going screwy.

ManAtWork · 2020-01-09 12:43

Thanks Dave and Evan for the explanation.

Still no clue about the flash problem. I've set the flash command line options to verbose (-v). The output is now:

trying \\.\COM3...
P2 version G found on serial port \\.\COM3
Setting load mode to CHIP
Setting clock_mode to 12427f8
Loading fast loader for chip...
Sending header
Loading C:/Program Files (x86)/Parallax Inc/FlexGui/board/P2ES_flashloader.bin -
 4128 bytes
chksum: a0 OK
Sending header
Loading G:/Projekte/Speedcube3/Source/Propeller/Sc3_main.binary - 1440 bytes
chksum: 91 OK
( Entering terminal mode.  Press Ctrl-] to exit. )
P2-ES Flash Programmer
Erasing flash...
Programming...
Done

I hope the flashloader does a verify to ensure the write to EEPROM has been actually successful.

ManAtWork · 2020-01-09 13:01

The P2 makes no attempt to boot from the flash. I checked with the scope. There is a small low pulse on /CS aprox. 20ms after the rising edge of RESn. But no activity on SO. The EEPROM is either empty or the P2 somehow doesn't want to boot from it.

Again, my wiring is like this: P61 to /CS with pullup, P60 to SCK, P59 to SI, P58 to SO. The EEPROM is a MX25V8035FM from Macronix.

Peter Jakacki · 2020-01-09 13:30

ManAtWork wrote: »

The P2 makes no attempt to boot from the flash. I checked with the scope. There is a small low pulse on /CS aprox. 20ms after the rising edge of RESn. But no activity on SO. The EEPROM is either empty or the P2 somehow doesn't want to boot from it.

Again, my wiring is like this: P61 to /CS with pullup, P60 to SCK, P59 to SI, P58 to SO. The EEPROM is a MX25V8035FM from Macronix.

TAQOZ is built into the ROM for checking hardware among other things, so when you have new hardware to debug, use TAQOZ.

With a terminal connected, reset the P2 and type the 3 characters [>] [SPACE] [ESC] to enter TAQOZ. Then type .SF and it should report Flash ID etc. You can examine and program/erase the Flash from TAQOZ.

Cold start
-------------------------------------------------------------------------------
  Parallax P2  .:.:--TAQOZ--:.:.  V1.1--v33h         190219-1900
-------------------------------------------------------------------------------
------------------------------------------------------------------------------- ---  ok
TAQOZ# .SF --- $EF70_1800 $0F0B_2826_$E468_5CF4 ok
TAQOZ# 0 $40 SF DUMP --- 
00000: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF     '................'
00010: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF     '................'
00020: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF     '................'
00030: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF     '................' ok
TAQOZ#

To make P33 blink an LED type:
33 BLINK

To make P34 go high or low:
34 HIGH
34 LOW

evanh · 2020-01-09 14:19

ManAtWork wrote: »

I hope the flashloader does a verify to ensure the write to EEPROM has been actually successful.

No it doesn't, all writes are completely blind and there is no verify read-back. That's something I'd considered addressing but never got around to it.

evanh · 2020-01-09 15:50

There is a check for erase/write busy status. If the EEPROM is not responding then it'll get stuck waiting for a response before it even starts the erase step.

ManAtWork · 2020-01-09 15:53

evanh wrote: »

> I hope the flashloader does a verify to ensure the write to EEPROM has been actually successful.
No it doesn't, all writes are completely blind and there is no verify read-back. That's something I'd considered addressing but never got around to it.

Uh, this is something that should definitely be fixed soon! Especially for testing of new prototype boards (and later production) it saves a lot of time finding problems. And it shouldn't be too hard to implement.

BTW, I checked the data sheets of both Macronix MX25V8035 (mine) and Winbond W25Q128 (used for the P2D2 and Eval board AFAIK). All basic commands (Read, Chip Erase, Page Program, Write Enable...) seem to be compatible. Page size is 256 bytes for both devices.

Next thing to try is using TAQOZ as Peter suggested. It's completely new to me...

How to start

Comments