Help using pPropellerSim

nyholku

Hi I've tried to use pPropellerSim and it sort of works but I don't know how to use it.

I have written my two line C-code and two line .spin/pasm code and compiled it with SimpleIDE (so gcc AFAIU).

In pPropellerSim I use "Open Propeller Tool Binary..." command and the code loads (at least I think it does) into the HUB memory.

I hit RUN or single step and COG 0 starts to spin (pun intended) but I never see my code C code launching anything to COG 1.

As I understand it Propeller launches a spin interpreter in COG 0 when it boots and that is supposed to run the spin code from hub which then launches or runs the compile C code (details not clear yet) and something in this chain is not working for me.

Any help would be highly appreciated.

cheers Kusti

Here is my code in blink.c:

#include "simpletools.h"                    
extern int binary_blinkasm_dat_start[];
int main()                                  
{
   cognew((void*)binary_blinkasm_dat_start, (void*)0);
  while(1)
  {
  }  
}

and in blinkasm.spin:

pub main
dat
	   org	0
loop
      nop
      jmp #loop
huuhaa long $deadbeef

nyholku

More results from experimentation.

There are one or two small bugs in the pPropellerSim which are show stoppers if one is not aware of them.

1. The Cold Reset menu command is not implemented
2. hwreset() function in the Java code does not call cog.reset(true) so after first run of any spin/pasm code

Together these means that is next to impossible to try to run some code and one is totally confused.

After fixing those I'm able to run a simple spin program that launches a simple .pasm into a separate COG like this:

pub main
      cognew (@loop,0)
dat
	   org	0
huuhaa long $deadbeef
loop
      add huuhaa,#1
      
      jmp #loop

However I'm unable to get the almost equally simple C/pasm combo to produce anything in cog 1, cog 0 just spins (no pun intended) in tight loop (maybe pulling something from hub memory and executing it?).

How is the C code supposed to start executing?

After reset Propeller loads the spin interpreter to COG 0 which then starts to read and execute SPIN code from hub, so is there some sort of SPIN launcher code to launch the 'kernel' mentioned in propellergcc docs ?

Is this documented somewhere?

I even wrote the simplest of C programs but simulating it does not produce anything that makes sense:

#include "simpletools.h"                      
int main()                                    
{
  int cnt=0;
  while(1)
  { 
  OUTA=cnt;
  cnt++;
  }  
}

Wuerfel_21

Hmm, have you tried the GEAR emulator? That one sorta worked last time I checked (albeit at some 1% of real speed) and includes bytecode-level spin debugging.

Anyways, emulating the Prop is a bit of a lost cause, it's just kinda too fast, yet reliant on precise timing to get anywhere near 100% real speed. I do most of my debugging on a real chip, printing out values on the serial port.

nyholku

@Wuerfel_21

Yeah, tried GEAR. That too works with simple spin/pasm but not with the C-code.

Hard to debug when there is so little info on how the C starts executing and what is and how the kernel that pulls code from the hub memory to cog for execution works.

The Gear speed is pitiful, after all 20 MPIS/cog is not that fast when I'm running my stuff on 2.6 GHz 8 core i7. PIC gpsim runs at equivalent of 20 MHz which translated to 5 MIPS. I think the problem with Gear is just the screen update, there is no point and need to update the screen so often.

Also Gears seems to be Windows only at least out of the box.

I kind of agree with simulation point in general, but still it would be convenient to have good reliable emulator.

I mainly picked pPropellerSim cause it is Java based and I'm very proficient with all things Java AND it is so much more cross platform than any of the other alternatives. I was able to get the project compile in minutes and debug those above mentioned problems in less than half an hour.

Projects like this (writing a simulator) are very tempting but I try to steer away from them as this can easily turn into making tools to make tools for a side project of a side project.

Oh well, I'll give this a rest for a day or two and see if someone has some helpful input.

cheers Kusti

Wuerfel_21

Well, to be honest, "I do most of my debugging on a real chip" was a lie. I actually wrote a very project-specific high-level emulator that I use for working on my prop game (altough only to reduce the amount of times I have to swap the SD card around - too lazy to write a proper debugger). The high-level program is written with a custom assembler that can also emit C++ code that I then link with C++ re-implementations of all the low-level driver code - this kind of approach is really fast, but requires a lot of extra effort (since this kind of high-level emulator will inevitably have a different set of quirks than real HW (and obviously someone has to write the C++ driver replacements)). In my case that's fine, in the end I want a PC version, anyways.

If you're writing high-level code in C, I guess it's easier, since you can just compile it with x86 GCC instead of having to roll custom tooling Of course, a more.. kinetic? (involving motors,sensors,etc...) project wouldn't really work on a PC. (Unless hooked up to some kind of physics simulator?)

On the topic of pPropellerSim, I assume you have version 1.0.0.12?
Looking at the org.pacito.propeller.Cog class, many of the instructions are implemented very incorrectly. (for example, the Z flag result from MIN/MAX is supposed to be "S==0", not "S==D". The Z flag result from MOVS/MOVD/MOVI is also incorrect. I don't see where the flag outputs for hubram load/store are handled.). In case you want to try fixing it and want to take the fast path, I've attached some relevant source from my above-mentioned bespoke assembler / high-level emulator. It doesn't have every instruction (anything I/O or timing-related is not present) and some pseudo-ops specific to my XMM/LMM kernal, but all the ALU ops are there and as far as I can tell, correct (I've fuzzed each instruction - identical results on real HW). The interesting bits are the ALUINSTRUCTIONS table and the _frame_c method.
(Stupid forum doesn't like .rb files, so once again, a ZIP)

yeti

Does simpletools somehow preset DIRA?

I currently have no PropGCC at hand but trying something remotely related with FastSpin yields the expected output.