Shop OBEX P1 Docs P2 Docs Learn Events
p2gcc For MicroPython? — Parallax Forums

p2gcc For MicroPython?

What is the current status of p2gcc and were can I find the latest version? There has been talk of porting MicroPython to P2 and since it is written in C it seems like p2gcc might be a good solution. How much of the standard C library has been implemented so far? Or can I just compile the library used by PropGCC?

Comments

  • Dave HeinDave Hein Posts: 6,347
    edited 2018-12-01 14:14
    I just posted a comment on the status of p2gcc in the Python for P2 thread.
  • Thanks for the update but where can I find the latest p2gcc?
  • Dave HeinDave Hein Posts: 6,347
    edited 2018-12-01 14:20
    The latest zipfile is posted in the Can't Wait for PropGCC on the P2 thread. The latest source, which is more up to date than the zipfile is in GitHub at https://github.com/davehein/p2gcc.
  • Got it. Thanks!
  • Great. I was looking for this as well.

    I've been chasing down the dev tools and compilers as well for Prop2.
    We need to ultimately document these in a single place.
  • Where's the latest code for MicroPython? I can try to build it, and see what's missing in p2gcc. Most likely it will need lots of library functions that p2gcc doesn't have.
  • The MicroPython web page says it's here: https://github.com/micropython/micropython

    I got it to compile using PropGCC for P1 and the xmmc memory model but it doesn't run and I haven't had time to try to track down why.
  • I looked at the make file for MicroPython, and it will be a loooong time before we can build that for the P2. It relies heavily on GCC and ELF files.
  • Dave Hein wrote: »
    I looked at the make file for MicroPython, and it will be a loooong time before we can build that for the P2. It relies heavily on GCC and ELF files.
    Thanks for checking. I suppose the Makefile could be rewritten. I guess your compiler requires all C source files to be specified on a single command line. Is that correct? You don't have the concept of compiling each file separately and later linking them?

  • Does p2pasm have the ability to assemble P1 programs as well as P2 programs?
  • In all seriousness, having all the information all over the forums - both for the P1 and the P2 has been an impediment to keeping up to date with a lot of things.

    We all know the old canard "There were 12 standards, so we created a new one to integrate them all - now we have 13 standards..." but a community-based wiki that isn't dependent on gatekeepers to add / remove / update would I think help us move faster.

    I have my own (internal) wikis that I use for keeping my docs / bookmarks - maybe I should just copy mine up and make them public. Worst case, someone finds them and uses them. Best case, people find them and add to them.
  • David Betz wrote: »
    Dave Hein wrote: »
    I looked at the make file for MicroPython, and it will be a loooong time before we can build that for the P2. It relies heavily on GCC and ELF files.
    Thanks for checking. I suppose the Makefile could be rewritten. I guess your compiler requires all C source files to be specified on a single command line. Is that correct? You don't have the concept of compiling each file separately and later linking them?

    p2gcc supports the -c option, so it is capable of generating an object file. Multiple C files can be specified on one line, or each file could be compile one line at a time. The object can then be linked together using p2gcc, or p2link could be used directly.

    The earlier version of p2asm, which was called qasm, could assemble both P1 and P2. However, I removed the P1 feature at some point. It would be fairly easy to add P1 capability back in.

    __red__, it would be useful to create a thread that lists all of the P1 and P2 tools that are available.

  • Dave Hein wrote: »
    __red__, it would be useful to create a thread that lists all of the P1 and P2 tools that are available.
    I'm not sure a thread is the best approach. Unless it is very active it ends up falling off the bottom of the thread list and it becomes hard to find. Maybe a sticky thread would help. Is that possible?

  • A sticky thread might be good. Personally, I don't like sticky threads before they clutter up my view of current active threads. However, I believe the forum software allows individuals to "dismiss" sticky threads. At least I think that's what I've done in the past. If the thread has a unique subject it is very easy to search for it. Whenever I want to find the P2 documentation I just search for the "FPGA" thread. A thread with the subject "P2Tools" would be easy to find.
  • David Betz wrote: »
    I'm not sure a thread is the best approach. Unless it is very active it ends up falling off the bottom of the thread list and it becomes hard to find. Maybe a sticky thread would help. Is that possible?

    The fundamental problem with threads is that you don't get to see the latest version unless someone specifically edits / tags / updates / it etc...

    People will post .zip file of the latest version 30 pages down a thread which, with all the love in the world doesn't scale.

    For the longest time the documentation / code sticky for the P2 wasn't the latest version (I spent a few days developing against something that was weeks old) because the newer version had dropped off the front page.

    I know we have some... ahem, 'resistance' in some quarters to using git / github and instead posting zipfiles to threads because it's how it's always been done.

    This isn't meant as a criticism btw, the individuals concerned are making massive contributions to the community so if volunteers can attempt to keep a wiki / community github up-to-date with these updates/posts as they come on then that seems like a like a wiki/github could be a good contribution to make.

    Like I said - I already have a fair amount of this done for my own internal use. I just have to decouple it from my personal stuff and I'll publish it.

    "If you build it, they will come".

    (or, worst case - my docs are online in the cloud instead of being on my internal wiki)

    Either way - it costs me a few hours and I still win.
  • jmgjmg Posts: 15,140
    edited 2018-12-03 18:52
    __red__ wrote: »
    The fundamental problem with threads is that you don't get to see the latest version unless someone specifically edits / tags / updates / it etc...
    People will post .zip file of the latest version 30 pages down a thread which, with all the love in the world doesn't scale.

    Actually, not quite.
    The Parallax forum software allows no-time-locks editing, so the common approach is to update the FIRST post in the thread over time, easy to follow then.

    This example you likely have already seen
    http://forums.parallax.com/discussion/162298/prop2-fpga-files-updated-2-june-2018-final-version-32i/p1


    Some run a thread here, and a Github link, and that seems to work quite well - you have actually just suggested 'adding another standard'

    an example of this
    http://forums.parallax.com/discussion/164187/fastspin-compiler-for-p2/p1
  • Red, if you drop a Wiki, I am inclined to contribute. You are right. It's all net gain.

  • The problem with a thread is only the OP or a moderator is going to be able to update it.

    So unless one person + a moderator wants to commit to keeping a list of tools updated, it will inevitably fall out of date.

    It's very hard to figure out the status of everything from forum threads alone, for both P2 and non-Parallax P1 stuff.
  • potatohead wrote: »
    Red, if you drop a Wiki, I am inclined to contribute. You are right. It's all net gain.

    https://github.com/rosco-pc/propeller-wiki
  • Clock LoopClock Loop Posts: 2,069
    edited 2018-12-03 20:27
    I am GITiing alot of stuff lately, and if its not in the git or the wiki of the git, then I miss it.

    Aren't threads for the TALK of it, to get help with it or to announce it.

    Gits are where you should keep/maintain/share it?
    Often, I wish people would link and copy the thread related, into the git.
    For opensource anyone can GIT it into their own, only needing to give credit to source?
    Gits move it across the world, languages, and platforms, just from the spider of dependencies.
    Threads are very local.


    What he said...
    jmg wrote: »
    The Parallax forum software allows no-time-locks editing, so the common approach is to update the FIRST post in the thread over time, easy to follow then.

    Some run a thread here, and a Github link, and that seems to work quite well

    If you have a project planned, use the first 4 posts in the thread to do content as its developed so you don't need to shove it all in the first thread.
  • potatohead wrote: »
    Red, if you drop a Wiki, I am inclined to contribute. You are right. It's all net gain.

    Mediawiki:

    https://evil.red/wiki/Main_Page

    Working on the tools listing here: https://evil.red/wiki/P2Tooling (Heck - even having the list of tools in one page is useful)(!)

    I'll move it to its own domain in a few days...

    Planning on running an active job to export all the articles and automatically upload them to github so if I accidentally get hit by a bass someone else can pick up the pieces.

    What I don't want to see a repeat of is the loss of data like we saw with a previous wiki.

    With that said, after I have the P2 stuff at least referenced I may look to see if I can recover the data from the old P1 wiki from the wayback machine and see if it's importable. (That may be extra credit).

    Feel free to add / re-arrange / whatever there.

    Account creation is wide open, hell - editing the articles doesn't even need registration right now just like wikipedia (but if you don't register the editing user will show as your IP address, again - just like wikipedia).
Sign In or Register to comment.