@ersmith said:
I'd really need more context to try to guess what's wrong. In one of your other posts you mentioned using a conditional debug in assembly (like if_b DEBUG()). The hardware doesn't actually support that, and so it should produce an error in flexprop, but if it somehow gets through it'll do weird things.
The particular weird thing that happens (when C=0 in that case) is that INT0 gets triggered without latching the BRK argument. So it'll repeat the processing of the most recent debug statement. If the cog never did a debug before, I think it defaults to $00, which IIRC triggers single step mode, which FlexProp doesn't have a way to handle. That would look a lot like a hard crash (incl. garbage spew on the terminal).
Is it possible to have some files of your project compile to byte code and some to machine code? I'm thinking about a software radio, with dsp compiled to machine code with quite a few largish buffers taking up memory and the gui running as byte code to fit in the remaining space. If this has been answered elsewhere, could someone point me to it please? Cheers, Bob
@bob_g4bby said:
Is it possible to have some files of your project compile to byte code and some to machine code? I'm thinking about a software radio, with dsp compiled to machine code with quite a few largish buffers taking up memory and the gui running as byte code to fit in the remaining space. If this has been answered elsewhere, could someone point me to it please? Cheers, Bob
Unfortunately that is difficult to do. It is possible, if you can completely separate the two parts -- @Wuerfel_21 did something like this with one of her game emulators (NeoYume and/or MegaYume) where she basically compiled two independent programs with different flags, one of them with the -E -H xxx flags so that it would run at a different hub address. This "upper" program could then be run by the "lower" program.
Another possibility is to use the -W flag to produce "wrapped" Spin code that's basically inline assembly. But that isn't well tested and probably doesn't work very well.
I would suggest as a first step just compiling everything into bytecode with -2nu, and then using inline assembly to accelerate the dsp part as necessary. That would be much easier than the other options.
Thank you for the advice, @ersmith . I've started with a DSP library made of inline assembly methods working on arrays - just about to add the cordic functions, which will be pretty fast thanks to the use of a cog pair with shared lut. Quite a tricky ballet dance to coordinate the two cogs to give 14 cycles per iq sample. My initial experiments indicate that a string of these methods running in a byte code program would spend by far the most time in the inline code and very little time in Spin.
So your compiler gives me a chance to compile either way and find out which fits inside 500k.
Cheers, bob
Comments
The particular weird thing that happens (when C=0 in that case) is that INT0 gets triggered without latching the BRK argument. So it'll repeat the processing of the most recent debug statement. If the cog never did a debug before, I think it defaults to $00, which IIRC triggers single step mode, which FlexProp doesn't have a way to handle. That would look a lot like a hard crash (incl. garbage spew on the terminal).
Is it possible to have some files of your project compile to byte code and some to machine code? I'm thinking about a software radio, with dsp compiled to machine code with quite a few largish buffers taking up memory and the gui running as byte code to fit in the remaining space. If this has been answered elsewhere, could someone point me to it please? Cheers, Bob
Unfortunately that is difficult to do. It is possible, if you can completely separate the two parts -- @Wuerfel_21 did something like this with one of her game emulators (NeoYume and/or MegaYume) where she basically compiled two independent programs with different flags, one of them with the
-E -H xxxflags so that it would run at a different hub address. This "upper" program could then be run by the "lower" program.Another possibility is to use the
-Wflag to produce "wrapped" Spin code that's basically inline assembly. But that isn't well tested and probably doesn't work very well.I would suggest as a first step just compiling everything into bytecode with
-2nu, and then using inline assembly to accelerate the dsp part as necessary. That would be much easier than the other options.Thank you for the advice, @ersmith . I've started with a DSP library made of inline assembly methods working on arrays - just about to add the cordic functions, which will be pretty fast thanks to the use of a cog pair with shared lut. Quite a tricky ballet dance to coordinate the two cogs to give 14 cycles per iq sample. My initial experiments indicate that a string of these methods running in a byte code program would spend by far the most time in the inline code and very little time in Spin.
So your compiler gives me a chance to compile either way and find out which fits inside 500k.
Cheers, bob