jm_rgbx_pixel_demo.spin2 with flexspin

David Betz · 2020-12-19 16:28

To get ready for @JonnyMac's Christmas lighting project for the P2 I've been trying to get his RGB pixel demo program working with flexspin since I prefer to do my work on the Mac if possible. I was able to compile it easily enough with the simple command:

fastspin -2 jm_rgbx_pixel_demo.spin2

This produced jm_rgbx_pixel_demo.binary with I loaded onto my P2 Edge + Breadboard after having connected an RGB LED strip to P24. Unfortunately, nothing happened. No LEDs lit. I tried the same code with Propeller Tool 2.4.1 and it worked fine. I will use this thread to describe my attempts to find out what went wrong with the fastspin build.

Edit: I made one change to Jon's code. I changed STRIP_LEN to 8 to match the length of my AdaFruit LED strip.

David Betz · 2020-12-19 16:33

I should point out that I know my install of flexprop is working. I just cloned Eric's repository yesterday and built it from sources. I've also compiled cdemo.c and used loadp2 to load it into my P2 Edge+Breadboard and the P56 LED blinks and I see the "Toggle" messages on the console.

JonnyMac · 2020-12-19 17:45

I took an 8 LED AdaFruit strip and connected the ground pin to GND, the power pin to V24 and the signal pin to P24 and tried to run the demo but the LEDs don't light. Any idea what is going wrong? I also tried supplying the LED strip with 5V and still didn't see any output.

Connect the strip power connection to 5v. The 3.3v signal from the P2 (P24) into the first pixel is fine; it gets bumped to 5v before going to the next pixel.

This has nothing to do with compiler issues; I just don't want you trying to power a larger strip from the small 3.3v supply on the P2 Edge.

David Betz · 2020-12-19 18:07

JonnyMac wrote: »

I took an 8 LED AdaFruit strip and connected the ground pin to GND, the power pin to V24 and the signal pin to P24 and tried to run the demo but the LEDs don't light. Any idea what is going wrong? I also tried supplying the LED strip with 5V and still didn't see any output.

Connect the strip power connection to 5v. The 3.3v signal from the P2 (P24) into the first pixel is fine; it gets bumped to 5v before going to the next pixel.

This has nothing to do with compiler issues; I just don't want you trying to power a larger strip from the small 3.3v supply on the P2 Edge.

I did connect the strip power to 5V. The same connections work when I load the code compiled with the Propeller Tool. I have to figure out what's going wrong with the flexspin version.

Ariba · 2020-12-19 18:07

It works if I compile and load it with flexProp (the GUI) in Windows.

Andy

David Betz · 2020-12-19 18:15

Ariba wrote: »

It works if I compile and load it with flexProp (the GUI) in Windows.

Andy

Really? I wonder why loading it from the Mac would be any different? What commands did you type exactly? Maybe I need different options to loadp2.

Ariba · 2020-12-19 18:56

The flexProp Gui executes this command for compiling:

"<path>/bin/flexspin" -2 -l -D_BAUD=230400 -O1 -I "<path>/include"  "<path>/jm_rgbx_pixel_demo.spin2"

I have replaced my flexprop folder path with <path>

JonnyMac · 2020-12-19 18:56

It works if I compile and load it with flexProp (the GUI) in Windows.

Really?

Yes. I did that last night. Sorry if I wasn't clear about that.

What commands did you type exactly?

I used the default P2 options in FlexProp -- no changes.

David Betz · 2020-12-19 19:28

JonnyMac wrote: »

It works if I compile and load it with flexProp (the GUI) in Windows.

Really?

Yes. I did that last night. Sorry if I wasn't clear about that.

What commands did you type exactly?

I used the default P2 options in FlexProp -- no changes.

I don't suppose it tells you what options it passes to the underlying programs? I'm just running the command line tools.

David Betz · 2020-12-19 19:42

Okay, this is odd.

This doesn't work:

dbetz@Davids-Mac-mini-2 jm_rgbx_pixel_demo % loadp2 jm_rgbx_pixel_demo.binary

but this does work:

dbetz@Davids-Mac-mini-2 jm_rgbx_pixel_demo % loadp2 jm_rgbx_pixel_demo.binary -t

The program doesn't print anything to the console. Why should I have to enter console mode for it to work?

David Betz · 2020-12-19 19:44

Also, if I start the program with the -t option to enable the terminal it only runs as long as the terminal is open. If I exit terminal mode, the program stops running.

JonnyMac · 2020-12-19 19:58

I don't suppose it tells you what options it passes to the underlying programs? I'm just running the command line tools.

It does. You could start with Eric's GUI to get things going, then switch to your own editor (I assume using a different editor is the goal).

"C:/MyPrograms/flexprop/bin/flexspin" -2 -l -D_BAUD=230400 -O2    -I "C:/MyPrograms/flexprop/include" -I "C:/MyPrograms/Parallax Inc/Propeller Tool v1.3.2/Library"  "D:/programming/P2_Spin2/jm_rgbx_pixel_demo.spin2"

I have Full Optimization enabled.

cmd.exe /c start "Propeller Output  " "C:/MyPrograms/flexprop/bin/loadp2"  -b230400 "D:/programming/P2_Spin2/jm_rgbx_pixel_demo.binary" "-9D:/programming/P2_Spin2" -k

David Betz · 2020-12-19 20:17

So, it seems like my problem is that the P2 resets when the serial port is closed by the loader. Is that known behavior? Or maybe it's specific to the Mac?

evanh · 2020-12-19 20:55

I'm not much direct help ... but DTR sequencing issues have cropped up historically. I can't remember last time loadp2 was reported with this type issue on any platform.

msrobots · 2020-12-19 21:12

I am begging Parallax and others to include a reset-inhibiting jumper on all boards having build in USB, but with not much success.

opening and closing ports reset the Propeller, USB enumeration reset the Propeller (just plug your camera in), and on some boards even putting out serial with nothing connected to USB will reset the Propeller because the USB chip gets powered up by parasitic power on TX and - resets the Propeller.

it is a mess,

Mike

evanh · 2020-12-19 21:18

Like a PROG/RUN switch. EDIT: Problem is, it won't be compatible with load-to-RAM. Only load-to-EEPROM will work that way.

iseries · 2020-12-19 21:19

In windows I just tell the driver to not reset the DTR pin on Com close.

Mike

evanh · 2020-12-19 21:25

iseries,
When you're writing the program I presume?

David Betz · 2020-12-19 22:44

iseries wrote: »

In windows I just tell the driver to not reset the DTR pin on Com close.

Mike

How do I do that on Mac OS X? I don't recall proploader having this problem.

evanh · 2020-12-19 22:57

Just been googling a little for using the APIs under Linux, which is what loadp2 is using for the Mac too. I found nothing about this. All the examples are for examining and toggling DTR while the port is still open. And much of the documentation even mentions how DTR is always dropped upon close() for the purpose of hanging up the modem.

David Betz · 2020-12-19 23:05

Other than the reset on exit problem, it looks like flexspin will work fine for the Christmas project. You can either use the GUI or the command line. I prefer to use BBEdit to edit my code and do the loading on the command line. I suppose I could program BBEdit to do the build and load process but that would require me to actually read it's documentation!

ersmith · 2020-12-19 23:37

Can you double check proploader and see if it has the same problem? If not then presumably we can take whatever code proploader uses to disable the reset on close() and copy it into loadp2.

Also: I notice you're using "fastspin" in your command lines. The Spin compiler is called "flexspin" now. Have you aliased "fastspin" to "flexspin", or are you accidentally running an old version of the tool?

David Betz · 2020-12-20 01:35

ersmith wrote: »

Also: I notice you're using "fastspin" in your command lines. The Spin compiler is called "flexspin" now. Have you aliased "fastspin" to "flexspin", or are you accidentally running an old version of the tool?

That was a typo. I'm using flexspin. I don't even have fastspin in my path.

David Betz · 2020-12-20 01:43

ersmith wrote: »

Can you double check proploader and see if it has the same problem? If not then presumably we can take whatever code proploader uses to disable the reset on close() and copy it into loadp2.

I tried proploader from the flexprop build and a program loaded without the -t option continues to run after proploader exits.

dbetz@Davids-Mac-mini-2 samples % proploader blink_all_cogs.binary -r

David Betz · 2020-12-20 02:09

David Betz wrote: »
ersmith wrote: »

Can you double check proploader and see if it has the same problem? If not then presumably we can take whatever code proploader uses to disable the reset on close() and copy it into loadp2.

I tried proploader from the flexprop build and a program loaded without the -t option continues to run after proploader exits.
dbetz@Davids-Mac-mini-2 samples % proploader blink_all_cogs.binary -r

I had another thought. Is it possible that the P1 and P2 behave differently with respect to DTR?

Tubular · 2020-12-20 02:10

We've used FT_Prog to "invert DTR" on several boards, so they reset on exiting rather than entering terminal comms. This makes them more in line with the P1 experience. However I'm not sure whether FT_Prog will run on a mac

On the P2 eval board Rev C, switch 1 disables the DTR reset, which would be handy.

On the P2 edge board, switch 1 turns on the onboard leds, I don't think there is a similar DTR disable

David Betz · 2020-12-20 03:14

What command is needed to write a program to flash so that it will boot on reset?

evanh · 2020-12-20 04:52

loadp2 comes with a prop2 program, called P2ES_flashloader.spin2, originally written by Brian, that's located in the board/ subdirectory. It's not really documented. I assume there is a menu in flexgui that automates using them as one.

JonnyMac · 2020-12-20 08:01

What command is needed to write a program to flash so that it will boot on reset?

Having Eric's IDE would go a long way to helping you get where you want to go. Using Command-->Compile and Flash runs this code on Windows.

cmd.exe /c start "Propeller Output  " "C:/MyPrograms/flexprop/bin/loadp2"  -b230400 "@0=C:/MyPrograms/flexprop/board/P2ES_flashloader.bin,@8000+D:/programming/P2_Spin2/flash_56.binary" -t -k

David Betz · 2020-12-20 12:38

JonnyMac wrote: »
What command is needed to write a program to flash so that it will boot on reset?

Having Eric's IDE would go a long way to helping you get where you want to go. Using Command-->Compile and Flash runs this code on Windows.
cmd.exe /c start "Propeller Output  " "C:/MyPrograms/flexprop/bin/loadp2"  -b230400 "@0=C:/MyPrograms/flexprop/board/P2ES_flashloader.bin,@8000+D:/programming/P2_Spin2/flash_56.binary" -t -k

Thanks. Maybe I'll spend some time moving this feature into loadp2 so the external program isn't necessary. That is the way the older P1 loaders worked.

Ariba · 2020-12-20 15:18

If you add features to loadp2 can you also add the ability to use RTS instead, or concurrent to DTR for reset? Unfortunatly this is not possible yet.
I have showed a possible code here

RTS is normally not affected on open and closing a port, and you don't need the transistor circuit to invert the signal. Also some cheap USB to serial ICs only have a RTS output.

Andy

jm_rgbx_pixel_demo.spin2 with flexspin

Comments