@deets said:
I appreciate the insights. I read somewhere that spin is IRQ friendly - I guess that’s PNut then. Is there a way to safely store PASM and state somewhere? Or should I just declare spin state & it will be accessible?
There is no way to support interrupts in FlexProp compiled code at this time. There's no mechanism for saving and restoring the state of the compiled code.
Thanks to ManAtWork I was able to remove my blinking-COG and instead am using smartpin pulse mode now. However I'm flummoxed by a behavior I can't explain. The following is my spin:
pri setup_pins()
pinclear(conf.SYSTEM_STATUS_PIN)
pinclear(conf.SD_STATUS_PIN)
case system_status
SYSTEM_IDLE: pinlow(conf.SYSTEM_STATUS_PIN)
SYSTEM_CAPTURING: pinhigh(conf.SYSTEM_STATUS_PIN)
SYSTEM_ERROR: pinstart(conf.SYSTEM_STATUS_PIN, P_PWM_SAWTOOTH+P_OE, 5000<<16+(clkfreq/10000), 2500)
case sd_status
SD_OK: pinlow(conf.SD_STATUS_PIN)
SD_WRITING: pinhigh(conf.SD_STATUS_PIN)
SD_ERROR: pinstart(conf.SD_STATUS_PIN, P_PWM_SAWTOOTH+P_OE, 5000<<16+(clkfreq/10000), 2500)
I have two status-pins that can be off, on, or blinking. And that works just marvelous for the SD_STATUS_PIN. However the SYSTEM_STATUS_PIN that should switch from IDLE to CAPTURING and back to IDLE does not perform the last step. It stays high.
Both are electrically setup the same way, LED + current limiting resistor.
I tried making the case explicit, and DEBUGed the case branches, which worked as expected. The LED just doesn't fall dark.
The following is the assembly generated, it looks reasonably similar for both cases to my untrained eye:
@deets : are you sure that the system_status variable is in fact being set back to SYSTEM_IDLE at the appropriate time? And that it's staying in that state?
Also, you might consider commenting out the pinclear() calls; they're redundant I think.
@ersmith I am sure, I did use an if cascade & debug-printed the case. It entered the correct one. I’ll check if the pinclear is needed. However there is the weird behavior difference to the SD card pin 🤔
Here's a test program that shows the setup_pins() function is working fine -- it responds correctly to any combination of settings I enter on the terminal. So I don't think your problem lies there, it must be somewhere else in your program.
CON
_clkfreq = 180_000_000
SYSTEM_STATUS_PIN = 58
SD_STATUS_PIN = 56
#0, SYSTEM_IDLE, SYSTEM_CAPTURING, SYSTEM_ERROR
#0, SD_OK, SD_WRITING, SD_ERROR
OBJ
ser: "jm_serial"
VAR
byte system_status
byte sd_status
pub main() | a, b
ser.start(230_400)
repeat
setup_pins()
ser.str(string("Enter 2 characters for state of SD and system: ", 13, 10))
ser.str(string("0 for idle/ok, 1 for capturing/WRITING, anything else for ERROR", 13, 10))
ser.str(string("> "))
a := ser.rx()
ser.tx(a)
b := ser.rx()
ser.tx(b)
ser.tx(13)
ser.tx(10)
if a == "0"
system_status := SYSTEM_IDLE
else
system_status := (a == "1") ? SYSTEM_CAPTURING : SYSTEM_ERROR
if b == "0"
sd_status := SD_OK
else
sd_status := (b == "1") ? SD_WRITING : SD_ERROR
pri setup_pins()
pinclear(SYSTEM_STATUS_PIN)
pinclear(SD_STATUS_PIN)
case system_status
SYSTEM_IDLE: pinlow(SYSTEM_STATUS_PIN)
SYSTEM_CAPTURING: pinhigh(SYSTEM_STATUS_PIN)
SYSTEM_ERROR: pinstart(SYSTEM_STATUS_PIN, P_PWM_SAWTOOTH+P_OE, 5000<<16+(clkfreq/10000), 2500)
case sd_status
SD_OK: pinlow(SD_STATUS_PIN)
SD_WRITING: pinhigh(SD_STATUS_PIN)
SD_ERROR: pinstart(SD_STATUS_PIN, P_PWM_SAWTOOTH+P_OE, 5000<<16+(clkfreq/10000), 2500)
Have a question about what it does if the constant "_clkfreq" is defined, but not sure where to ask...
I believe it's just being ignored, but not really sure...
@Rayman said:
@ersmith Is spin2cpp considered part of FlexProp?
Not really. It's related to FlexSpin (uses the same libraries) but isn't included in FlexProp.
Have a question about what it does if the constant "_clkfreq" is defined, but not sure where to ask...
I believe it's just being ignored, but not really sure...
On P2 it's just being ignored. On P1 it outputs some PropGCC specific defines to set the clock frequency, but those are protected by #ifdef and will be ignored on Catalina.
I think the most common use case for spin2cpp is for converting drivers, and ignoring _clkfreq seems reasonable for this.
The new Flexprop cannot run SimpleSound demo by Ahle2. It compiles and run, but it gives no audio. The same SimpleSound compiled using Flexprop 5.3.1 version works and plays music - 5.5.1 and later are silent
Another strange UI problem in 5.9.3 Windows: I cannot detect and select a serial port as in earlier versions. "Find port automatically" can not be unselected. A bug or a feature?
I'm also seeing SimpleSound not working any more.
This might be a tough one to trouble shoot as it's a bit big...
It does work with version 5.4.3, broke with 5.5.2
Tried, but getting this:
1>EXEC : error : No implementation for __lockio' found inlibsys/fmt.c'
1>EXEC : error : No implementation for __unlockio' found inlibsys/fmt.c'
Here's the file Ok, that won't help...
Maybe use a different browser?
Edge complained about the file for me, but I was able to get it after clicking on "more info" or something like that...
Update: Actually it now says "can't download, virus detected" for me too... What a pain...
I think Eric can sign the actual release and this problem will go away...
@Mickster said:
My longwinded method is to download/unpack to my Android phone and transfer the files via Bluetooth.
This cannot help in this case as the Defender deletes the file as soon as it detects it. Unsip->quarantine-remove from quarantine-try to run-quarantine.
Now this is not important anymore, as
@Rayman said:
Ok, the new FlexSpin does work with the Spin2 version of SimpleSound
and we can remove the test compiler and not use it anymore
This means there is something in SimpleSound which is not compatible with the new Flexspin and it is SimpleSound where we have to find it. Then:
if this is a bug in SimpleSound which is unnoticed earlier, as it worked, correct the bug in SimpleSound
if this is a bug in the compiler, correct the compiler
Comments
There is no way to support interrupts in FlexProp compiled code at this time. There's no mechanism for saving and restoring the state of the compiled code.
Good to know.
Thanks to ManAtWork I was able to remove my blinking-COG and instead am using smartpin pulse mode now. However I'm flummoxed by a behavior I can't explain. The following is my spin:
I have two status-pins that can be off, on, or blinking. And that works just marvelous for the SD_STATUS_PIN. However the SYSTEM_STATUS_PIN that should switch from IDLE to CAPTURING and back to IDLE does not perform the last step. It stays high.
Both are electrically setup the same way, LED + current limiting resistor.
I tried making the case explicit, and DEBUGed the case branches, which worked as expected. The LED just doesn't fall dark.
The following is the assembly generated, it looks reasonably similar for both cases to my untrained eye:
Any suggestions?
Got it. Worked with my Rev b out of the box first time.
Mobdro
@deets : are you sure that the system_status variable is in fact being set back to SYSTEM_IDLE at the appropriate time? And that it's staying in that state?
Also, you might consider commenting out the pinclear() calls; they're redundant I think.
@ersmith I am sure, I did use an if cascade & debug-printed the case. It entered the correct one. I’ll check if the pinclear is needed. However there is the weird behavior difference to the SD card pin 🤔
Here's a test program that shows the setup_pins() function is working fine -- it responds correctly to any combination of settings I enter on the terminal. So I don't think your problem lies there, it must be somewhere else in your program.
@ersmith Is spin2cpp considered part of FlexProp?
Have a question about what it does if the constant "_clkfreq" is defined, but not sure where to ask...
I believe it's just being ignored, but not really sure...
Not really. It's related to FlexSpin (uses the same libraries) but isn't included in FlexProp.
On P2 it's just being ignored. On P1 it outputs some PropGCC specific defines to set the clock frequency, but those are protected by #ifdef and will be ignored on Catalina.
I think the most common use case for spin2cpp is for converting drivers, and ignoring _clkfreq seems reasonable for this.
@ersmith It appears that the enum way of setting the P2 clock frequency no longer works...
It works for me:
Pls try with this enum before that one:
//override the default heapsize
enum { heapsize = 8000 };
@Rayman : that's a weird bug! For now you can work around it by putting the two constants into the same enum.
The new Flexprop cannot run SimpleSound demo by Ahle2. It compiles and run, but it gives no audio. The same SimpleSound compiled using Flexprop 5.3.1 version works and plays music - 5.5.1 and later are silent
Another strange UI problem in 5.9.3 Windows: I cannot detect and select a serial port as in earlier versions. "Find port automatically" can not be unselected. A bug or a feature?
I'm also seeing SimpleSound not working any more.
This might be a tough one to trouble shoot as it's a bit big...
It does work with version 5.4.3, broke with 5.5.2
My wave player still works...
Looks like it's between 5.5.0 and 5.5.1 when SimpleSound stopped working..
Original Spin2 version still works with Prop Tool, but not FlexProp...
It looks like the change in 5.5.1 to move all objects until after the other member variables may have broken SimpleSound.
Here's a version of flexspin that reverts that change. Could someone give it a try and see if it fixes the problem?
Tried, but getting this:
1>EXEC : error : No implementation for
__lockio' found in
libsys/fmt.c'1>EXEC : error : No implementation for
__unlockio' found in
libsys/fmt.c'Windows Defender didn't allow me to unpack the zip.
Trojan:Win32/Wacatac.B!ml
@Rayman : I'm surprised __lockio would come up for any Spin2 program. Did you have debugging enabled, perhaps?
@pik33 : I built the executable on Linux with a cross-compiler, so it's highly unlikely indeed to have been infected with a Windows virus.
@ersmith This was the C version with Spin2 drivers... What is _lockio anyway?
Ok, the new FlexSpin does work with the Spin2 version of SimpleSound
Maybe it is Defender's oversensibility - I noticed such oversensibility earlier - but I cannot do anything with the file.
Here's the file Ok, that won't help...
Maybe use a different browser?
Edge complained about the file for me, but I was able to get it after clicking on "more info" or something like that...
Update: Actually it now says "can't download, virus detected" for me too... What a pain...
I think Eric can sign the actual release and this problem will go away...
Now if the changed compiler worked with Simple Sound, maybe a change in the Simple Sound can be made to make it work again.
Why this
caused a problem in it?
My longwinded method is to download/unpack to my Android phone and transfer the files via Bluetooth.
This cannot help in this case as the Defender deletes the file as soon as it detects it. Unsip->quarantine-remove from quarantine-try to run-quarantine.
Now this is not important anymore, as
and we can remove the test compiler and not use it anymore
This means there is something in SimpleSound which is not compatible with the new Flexspin and it is SimpleSound where we have to find it. Then:
The new/current flexspin behavior is/should-be the same as PNut/Proptool.... Has anyone tried it there?
Reverting the variable/object reordering change is certainly not the right solution (and will totally mess up code density for bytecode mode)
Yes, simple sound works with PropTool still