My P8X32A-D40 *Solved*

gamemaker90gamemaker90 Posts: 19
Hello all,

My problem is quite frustrating and I need some help. I looked all over google for this problem to no avail.
I recently bought the P8X32A hoping it would be a nice alternative to arduino, but for some reason it doesn't take well to inputs. I made my own Propeller board with a protoboard and a few components as well as a breadboard version. The software I am using is SimpleIDE on the C platform. The computer recognizes the chip and writes to it perfectly, but inputs are not working. I attached a tact switch to p0 and used a pullup resistor as with any microcontroller, but the input only works for a few seconds before going out and sometimes giving a quick flash. Outputs work fine, but inputs don't seem to work. Here's my code:

#include "simpletools.h"

int main() {
while (1) {
int button = input(0);
if (button == 1) {
high(1);
pause(10);
low(1);
pause(10);
} else {
pause(100);
}
}

return (0);
}

Prior to that:

int main() {
while (1) {
int button = input(0);
if (button == 1) {
high(1);
} else
if (button == 0) {
low(1)
}
}

return (0);
}

Please help. I don't know if it's me or just the way it's "supposed" to work, but I would hate to have spent money on a useless piece of junk.
Any help will be greatly appreciated.
«1

Comments

  • 46 Comments sorted by Date Added Votes
  • gamemaker90 -

    This sounds like more of a hardware issue than a software issue.

    Can you please give us a schematic of the circuit for the tact switch? This should include your power connections to the Propeller chip.

    Thanks,

    Walter
    Tulsa, OK

    My OBEX objects:
    AGEL: Another Google Earth Logger
    DHT11 Sensor

    I didn't do it... and I promise not to do it again!
  • Cluso99Cluso99 Posts: 12,578
    edited July 2016 Vote Up0Vote Down
    Sorry I cannot help with c code.
    Looks like you might be outputting the result to a led. If so, you need to slow it down.

    Most of us use PropTool and spin. It's a simpler language. Many objects like serial are written in assembler and run in their own cogs (CPU cores).

    How about you post a pic of your setup in case there is a problem with your board. Make sure you have all power and ground pins connected, BoE tied to ground, and have decoupling caps on the power pins. Of course you are supplying 3.3V DC regulated, and not 5V like the arduino processors mostly use.

    BTW once you understand the prop you will never go back to the AVR/Arduino !
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • How are you clocking the Prop? SimpleIDE assumes you are using a 5MHz crystal, and a system clock of 80 MHz.
  • lardomlardom Posts: 1,372
    edited July 2016 Vote Up0Vote Down
    Cluso99 wrote: »
    BTW once you understand the prop you will never go back to the AVR/Arduino !
    Yeah, I second that. The Prop has eight processors and 16 counters that work in parallel on any pin. This makes (many of) your projects cheaper and your circuits simpler.
    The biggest thing though is you will not find a more helpful or knowledgeable community anywhere.
    Welcome to the community.
    Larry

    If the grass is greener on the other side...it's time to water your lawn.
  • I assume that you have an LED connected to P1 with a current limiting resistor to ground.

    Try setting the pauses in the "if" loop to a larger value (at least 100). When trying something new I usually will use pause(500) after the high to make sure I don't miss it.

    What are you using as a power source?

    Hope this helps.
    Tom
    #include "simpletools.h"
    
    int main() {
      while (1) {
        int button = input(0);
          if (button == 1) {
            high(1);
            pause(200);            // pause for 0.2 sec, LED on
            low(1);
            pause(100);            // pause for 0.1 sec, LED off
          } else {
            pause(100);
          }
        }
    
      return (0);
    }
    
  • gamemaker90,

    It sounds like you have your button circuit wired in reverse.
    If High is to be On then it's an Active-High button so it should have a PULL-DOWN resistor.
    http://learn.parallax.com/tutorials/language/propeller-c/propeller-c-simple-circuits/check-pushbuttons

    Pull-Ups are if you want the button to be Active-Low, or pressing the button returns a Low or 0 value.
  • Well thanks for all the replies, but I just realized something. It's a problem with the output. To answer all of your questions in order:
    1:
    tectSwitch01.png
    This works on arduino and like I said and temporarily for the propeller chip

    2: I tried compiling some of the sample code and got the same results. Be it c or spin it does the same thing, and yes 3.3v is the only power on the thing. I skipped out on using any other voltage regulator than the LD33V voltage regulator from a 9v battery (outputs 6v though, getting kinda old). Also I read the datasheet cover to cover pretty much. I know about the cogs. BoE is tied to gnd and I do not have any caps on the circuit. (I just added one from vdd to gnd and it went out even sooner).

    3: A 5Mhz crystal oscillator it even says 5.000 on the thing itself. I made sure to get all the right parts minus the EEPROM which the datasheet says is optional (of course it says the crystal is too but you can't believe everything, lol).

    4: Yes I agree. Getting this was in hopes of getting away from arduino anyway. I really do hope this works, and thanks this is the only other forum I've been a member on besides the Game Maker Community.

    5: My powe source as stated above is a 3.3v voltage regulator. As I reassebled everything to test it however I noticed that it may be the outputs and not the inputs at all. I ran the demo "Blink Light.c" and the LED blinked about 70 times then stopped. Depending on the speed the LED flashes though it has the tendency to go out sooner or later...

    6: Sorry for the confusion I think I meant pull down. It was 2:45 in the morning when I posted this (Yeah I was up practically all night trying to get BOTH my P8X32A's working, and yes I have 2 they both are giving me the same problem though). As far as the link goes, every time I searched this up on google that page came up. Me and that page don't get along so well...

    Any way here's a picture of my current setup where the LED flashes a few (50-100) times before going out:
    WIN_20160711_11_33_45_Pro.jpg
    The breadboard is the target and behind it is the protoboard version. Both boards are functioning the same so I know it's not my solder joints.
    128 x 128 - 507B
    1280 x 720 - 185K
  • Some feedback/ideas about the interface schematic...

    It might be a good idea to insert a series resistor between the point you've got marked as P0, and the actual Propeller P0.
    This would protect the Propeller in case you have the P0 set to output low in code, then press the button to short that to 3.3V.

    The resistor values are not needing to be precise for a simple switch, but for example if you used 10K series resistor and 100K pulldown, that would work for most cases and be pretty robust for you.

  • gamemaker90gamemaker90 Posts: 19
    edited July 2016 Vote Up0Vote Down
    I'll give that a try, thanks. Also I ran the spin demo called "Output" and the LED hasn't stopped flashing since I ran it. Maybe C wasn't meant to be used for this chip...
    Also do you know of any good tutorial sources for spin?
  • An old 9V battery that actually reads 6V is a battery at the end of its life. No wonder you are having problems! Bin it and get yourself some reliable power, like a wall wart that has some current capability. Just make sure it has a proper DC output for your regulator. Even 3 or 4 AA batteries are much, much better than those 9V batteries.
    Florida, between St. Petersburg and the Gulf of Mexico

    Do not look directly into laser with remaining good eye...
  • I'll give that a try, thanks. Also I ran the spin demo called "Output" and the LED hasn't stopped flashing since I ran it. Maybe C wasn't meant to be used for this chip...
    Also do you know of any good tutorial sources for spin?

    Download the Spin Tool:

    https://www.parallax.com/downloads/propeller-tool-software-windows

    Open the Tool and go to Help, and open the Propeller Education Kit (pdf). It has the basic for getting a Propeller going.

    Infernal Machine
  • The other folks replying on this thread are much better at debugging your hardware issues, so I won't touch that. But the Propeller is great fun in C (and C++) so don't give up just yet. :) I (and others) would love to help you with any software issues you might have down the road.
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
  • gamemaker90gamemaker90 Posts: 19
    edited July 2016 Vote Up0Vote Down
    Hal you make an interesting point, Ill try different power, Publison I already have the spin tool. That's what I used to compile the spin files, and I appreciate that david :) hopefully I can get this thing working so I can build me a video game console!

    EDIT:
    One other thing: the chip itself doesn't hold the code after I disconnect power. My guess is that's what the EEPROM is for. Correct?
  • Publison wrote: »
    Download the Spin Tool:

    https://www.parallax.com/downloads/propeller-tool-software-windows

    Open the Tool and go to Help, and open the Propeller Education Kit (pdf). It has the basic for getting a Propeller going.

    This is good advice. If you follow the pdf you'll probably be able to blink LEDs in fancy patterns before the day is out!
    Larry

    If the grass is greener on the other side...it's time to water your lawn.
  • One other thing: the chip itself doesn't hold the code after I disconnect power. My guess is that's what the EEPROM is for. Correct?

    Yes, that is what the EEPROM is used for. Unlike the Arduino boards and most modern microcontrollers, the Propeller does not have any non-volatile memory.
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
  • Absolutely, when I first started off with this chip and got it working before all the madness I was able to write a small program that lit up an led row one by one with a for loop. Also in other good news I think I may have found out the problem. To start off upon various sources around the web, I stumbled upon a few schematics that showed 1 5v regulator and a 3.3v regulator. Me being the stubborn person I can be at times didn't think the 5v regulator was necessary. To my supprise using the arduino uno for temporary power, I managed to get 5v from it and 3.3v from the voltage regulator. That said the circuit works now with flying colors. And Hal you deserve brownie points or whatever system they use on these forums for positive reinforcement. The last thing on my mind was power requirements. Opening that possibility means my C code is now working and it is not getting disconnected. But before this topic is closed I just want verification that the EEPROM is for what I think. As stated before, when I disconnect the power, the chip forgets the program loaded into it. Now obviously this is how RAM works. Correct me if i'm wrong, but the "load RAM & run" is for temporary testing and "Load EEPROM & run" is to store it in memory so that when the power is disconnected, the program doesn't have to be loaded into memory again. It just sits there.
  • ElectrodudeElectrodude Posts: 1,074
    edited July 2016 Vote Up0Vote Down
    Yes, that's what load RAM and load EEPROM do.

    Even though you got your Propeller working with C, I'd still definitely recommend you give Spin a try at some point. Many will disagree, but I and many others find it to be much simpler and much better suited to the Prop.
  • My philosophy is learning something new is what makes life worth living. I want to thank everybody for your help. This forum seems to be a very active and helpful community. Thanks again. This topic can be closed as solved (hopefully lol).
  • Yes, you need an eeprom to store the code. Use PropTool with the program option.

    Probably bad power. You should have a 10uF tantalum on the output of the regulator. You will require at least a 100nF (0.1uF) at the prop's power/ground pins. I know it will work without if your power regulator is close by, but it can be unreliable!!!

    It's true that you can run without an xtal. Use the internal rc option. It will blink your LED and it will download code. But it will not work reliably serially to your PC because of the process variation in the RC oscillator. And as you found, you don't need the eeprom but it will not save and reboot your code.

    In one of the directories of PropTool there are examples/tutorials (about 10 IIRC) that goes through spin and starting multiple cogs. Doesn't take long and its easy to understand. There is also a cheat sheet - 2 pages each for spin and pasm (assembler). The base instructions for pasm are quite simple compared to any of the other micros around.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • gamemaker90,

    Good that you have it working but just so you know C has only been on the Propeller for 2 years so not everything is available in code.
    Spin is the Propeller's native language and to many is not as cryptic or quirky as C.
    The best Spin tutorial is the Propeller Education Kit text and you can also download the code from here.
    https://www.parallax.com/product/32305

    You can use a breadboard but Parallax makes some very great boards such as the new Propeller Activity Board WX that's used for Propeller C.
    https://www.parallax.com/product/32912
    http://learn.parallax.com/tutorials/propeller-c

    Most of the code for video I still in Spin and if you want to play games then the Hydra is what you want.
    https://www.parallax.com/downloads/hydra-manual

    Welcome to the Parallax forum and if you have any more questions then feel free to ask.
  • tomcrawfordtomcrawford Posts: 646
    edited July 2016 Vote Up0Vote Down
    Yes, that's what load RAM and load EEPROM do.

    Even though you got your Propeller working with C, I'd still definitely recommend you give Spin a try at some point. Many will disagree, but I and many others find it to be much simpler and much better suited to the Prop.

    Spin is precisely suited to the Prop, and makes perfect sense once you spend an hour studying it. As much effort as the "C" guys have put into splicing it to the prop, spin just plain ol' works better. In my opinion. tc

    Edit: Mostly because prop 1 doesn't have enough RAM, either hub or cog. P'raps prop 2 will be better suited to C. Ended it

    Re-inventing the wheel is not a waste of time if, when you are done, you understand why it is round.
    Cool, CA, USA 95614
  • I'm getting really tired of people saying how bad C is on the Propeller. I think Parallax should just introduce P2 with only Spin and forget C. Their customer base just isn't interested in C and many are openly hostile to it.
  • PASM (Propeller Assembly) is the "native" language for the Propeller, limited by cog memory size (512 32-bit words). Spin is the original language ... uses an interpreter built into the Propeller's ROM. The interpreter is automatically executed when the initial user program is loaded from a PC or the EEPROM, so the user program starts in Spin. Spin is fairly fast and has very compact compiled code. C can be compiled to native code limited by cog memory size. It can also be compiled to one of several other interpretive codes. One of these is faster than Spin, but nowhere near as compact. Others are slower than spin, but can be stored in external RAM or EEPROM and paged in from there allowing larger programs. One compiled form can be stored on an SD card and paged into hub RAM for interpretive execution ... fairly slow, but this allows for large programs. There's also a very fast Forth interpreter (Tachyon Forth).
  • David BetzDavid Betz Posts: 11,293
    edited July 2016 Vote Up0Vote Down
    Mike Green wrote: »
    C can be compiled to native code limited by cog memory size. It can also be compiled to one of several other interpretive codes. One of these is faster than Spin, but nowhere near as compact.
    In fact, the CMM memory model is usually faster than Spin and almost as compact.
    Others are slower than spin, but can be stored in external RAM or EEPROM and paged in from there allowing larger programs. One compiled form can be stored on an SD card and paged into hub RAM for interpretive execution ... fairly slow, but this allows for large programs.
    All of the modes you're talking about are the same. They are the XMM memory model with a variety of external backing stores. Also, you failed to mention external SPI flash which is actually the best choice and is supported by the Parallax C3 module.

  • David Betz wrote: »
    I'm getting really tired of people saying how bad C is on the Propeller. I think Parallax should just introduce P2 with only Spin and forget C. Their customer base just isn't interested in C and many are openly hostile to it.
    I hope your not really serious about not supporting C on the P2. With hubexec and a larger hub RAM the P2 will be a much better fit for C than the P1 is. I suspect that the P2 will have many new users that would prefer programming in C versus Spin. I'm hoping that Parallax initiates a P2 GCC project soon, like they did for the P1. I don't understand why this hasn't already started. The core P2 instruction set has been stable for quite a while, and I wouldn't expect any major changes in it. It seems like work on porting GCC to the P2 could have started 6 months ago. I believe it would be beneficial to having GCC available before the P2 is finalized in silicon. This would allow people to really test out the FPGA image with a variety of applications.

  • Dave Hein wrote: »
    David Betz wrote: »
    I'm getting really tired of people saying how bad C is on the Propeller. I think Parallax should just introduce P2 with only Spin and forget C. Their customer base just isn't interested in C and many are openly hostile to it.
    I hope your not really serious about not supporting C on the P2....
    Of course, what *I* think will have no bearing on what Parallax does. Their Learn materials are all focused on C so I'm sure C will exist for the P2. It's just that I found one of the strongest features of the Propeller was the very supportive people on the forums and the majority of the forum people seem to strongly prefer Spin. I think there are even more Forth supporters here than there are C supporters. So the hard reality is that Spin will always be the most productive language for the Propeller because it will be the one best supported by the most knowledgable Propeller users.

  • gamemaker90gamemaker90 Posts: 19
    edited July 2016 Vote Up0Vote Down
    Well I know C++ and honestly C isn't that much different. Is there a way to utilize both spin and C in one program?
  • Well I know C++ and honestly C isn't that much different. Is there a way to utilize both spin and C in one program?
    There are at least two ways to do that. You can use spin2cpp to convert your Spin code to either C or C++ and then you can link it with your own C or C++ code or you can use spinwrap to add a wrapper to Spin code to allow C or C++ to call it. The first produces much faster code and the second takes advantage of the compactness of Spin bytecode by allowing the Spin to run natively under the Propeller Spin VM.
  • evanhevanh Posts: 3,899
    edited July 2016 Vote Up0Vote Down
    I know my own little experience with C on the Prop1 caused all the blood to drain from my face upon first use of printf(). I've since noted Mr Zemon recommending alternatives to printf(). Can't remember what they were now ...
    $50,000 buys you a discrediting of a journalist
  • evanh wrote: »
    I know my own little experience with C on the Prop1 caused all the blood to drain from my face upon first use of printf(). I've since noted Mr Zemon recommending alternatives to printf(). Can't remember what they were now ...
    What exactly were you trying to do? I've certainly used printf with programs compiled for the CMM memory model without any problems. I think I've even used it with LMM although program size would be quite limited in that case.

Sign In or Register to comment.