Newbie question re outputting square wave.

I have the following code:
'' Max output frequency = 2.7KHz

PUB Main
    outa[0] := 1
    ' waitcnt(clkfreq/32000 + cnt) does not change output
    waitcnt(clkfreq/31000 + cnt)
    outa[0] := 0
    waitcnt(clkfreq/31000 + cnt)
The output will not toggle at frequencies greater than 2.7KHz. I have just received the P1 yesterday, but no crystal. The internal RC is certainly very temperature dependent. I have tried some serial comms but to no avail, probably pointless until I get the crystal. My goal is to set up the P1 as a multi-function I/O device (Servo, PWM, Sound, Pulse Counter etc.) for an educational board based on the ESP8266 that I have designed. I plan on using the P1 as an I2C slave, would anyone advise serial comms instead? I have more questions but I need to invest some time in reading the fine manual.


  • Welcome to the forums! As you have seen, serial communication is very dependant on a stable xtal frequency. Please ask more questions when you get the crystal.
  • Spin is pretty slow, that's why you get such low toggle frequencies.
    Attached is my serial object for RC fast communication. You need to press the space-key two times at begin. The waitForKey methode will then do an autobaud measurement with the timing of that space keys.

    Test code:
    '' Serial Test
      ser : "Serial_RCfast"
    PUB TestCode : key
        key := ser.rx

  • The P1 with Tachyon loaded is very fast and can do all those things out of the box such as sound (also WAV audio from SD), 32-channel 8-bit 7.6kHz PWM, Multi-channel servo control, and pulse counting. BTW, generating square waves and counting pulses can be done with the pair of counters that each cog has. For instance if you connect to a P1 from a serial terminal or a host, to make P5 output 38kHz just enter "5 APIN 38 kHz". The high speed serial communication that is built into Tachyon is also useful for controlling the P1 from a host etc.
  • JonnyMacJonnyMac Posts: 7,299
    edited 2020-02-08 - 22:00:33
    would anyone advise serial comms instead?
    I would. Still requires two wires, but a serial slave is easier to implement (IMO). Once you get the crystal situation sorted, you'll find things operate much more nicely, and there are a variety of objects available to assist in implementing your project.

    On PWM... if you only need one or two PWM outputs, you can use the cog counters and get much higher output frequency, even when using Spin; in that case, the counter generates the high pulse (based on duty cycle), and the Spin loop controls the period. Each cog has two counters. In Spin, you can get up to about 35kHz output on both (I've done this for DC motor controllers). If you move everything to PASM, You can get even high frequencies.
  • I downloaded the Tachyon binary but I got an error when loading it into RAM. I'd say the lack of crystal leaves my comms very dodgy. I have a 4k7 resistor in series with RX and TX because my AliExpress USB serial module is showing 5V on these lines. In addition I have another 4k7 in series with a 0.1uF cap on the DTR line and the reset action works. Spin downloads just fine but terminal examples do not work. From what I read about Tachyon it seems to fit the bill for what I need.
  • Glad you gave it a try, even though there is practically no P1 application that doesn't need a crystal :)

    Don't forget to read the intro to Tachyon document and remember that it's a bit like a piano, you can look at it and study it all you like but there's nothing stopping from playing that first note, and so on. Playing is much more fun.
  • Peter,

    I have received the 5MHz crystal and did a quick "Hello World" check using Simple IDE and the C program so my TX and RX is working OK. When I load the Tachyon.bin I notice that Xin is set at 10,000,000. The download seems to progress with my TX LED showing activity. After 5 seconds I get a message "Write failure on COM".

  • Peter JakackiPeter Jakacki Posts: 9,911
    edited 2020-02-12 - 00:16:12
    Tachyon starts off with 10Mhz x8 PLL setting and then automatically adjusts to 5Mhz x16 at startup which means that a 5Mhz crystal will initially start at 40MHz before switching to 80Mhz. You can thank @Phil Pilgrim (PhiPi) for that bit of clever code.

    As for the "Write failure on COM" I'm guessing since you have cobbled together a Prop chip and a crystal that maybe your hardware is to blame. Do you have decoupling capacitors properly connected? Do you have a clear photo of your setup?
  • Yea a bit of cobbliing together alright. Added 0.1uF at the chip power pins, both sides. Moved the resistors on the serial off the breadboard and generally tightened things up. The USB supplies power. My Test spin program loads perfectly, I saved as a binary and did a Load RAM and that's perfect too. XIN freq is 5MHz, Clock 80MHz. Tachyon appears to be downloading the data judging by the LED on the serial usb then throws the Write Failure error after 5 secs. I wouldn't imagine that downloading would even start if there was an issue around TX and RX because of handskakiing failure. I'm puzzled.
    1836 x 3264 - 3M
  • Do you need an eeprom?
  • Now there's a thought! I would expect that RAM should do but then I'm only dabbling with the P1 for less than a week.
  • Load to RAM should not need an EEPROM....

    Try creating a really large test program (just put something like
    long 1234[7500]
    into your Spin test program) and see if that uploads fine
  • We could be on to something here.
    I was getting a "Write failure on COM4" with any number of data items over 4000. I'm attaching the Object Info dialogue using the following code:
    long 1234[4000]

    I tried out my second P1 and the same applies.
    885 x 518 - 152K
  • Wuerfel_21Wuerfel_21 Posts: 1,074
    edited 2020-02-12 - 20:08:36
    If two chips don't work, it's likely got to do with the serial port.

    a) What kind of chip is your USB serial dongle using? If it came from Aliexpress, probably not a FT232 (maybe an illicit clone though :) ) (that being the "known good" one)

    b) try changing your serial port's buffer size to something else (the configuration for this is buried somewhere in device manager. Since this is like the 3rd time this is coming up for me, I made a handy PNG that hopefully illustrates how to find it. In German, because changing Windows' language is a mess). In my experience, the lowest value is best. Also try fiddling with some of the other settings in this dialog if that doesn't help.

    996 x 930 - 173K
  • Peter JakackiPeter Jakacki Posts: 9,911
    edited 2020-02-12 - 22:21:24
    Thanks for the photo. From there I can see at least two problems.
    1) Decoupling capacitors are normally 0.1uF ceramic due to their low esr at higher frequencies and they should be connected as close and as directly to the Vdd/Vss pins on each side as possible. Using high value caps or tantalums will be ineffective.

    2) Where is the 3.3V coming from? All the way over there on the breadboard? How is it decoupled?
    btw - don't use any 3.3V "supply" from the FTDI chip, it is not meant for this kind of thing and is insufficient.

    3) If that is strip board then make sure the crystal does not have a long "antenna" strip of copper. Keep it very tight and nowhere else.

    The P1 may appear to work with a poor layout and decoupling but as soon as it starts drawing heavier current and especially if it switches to the crystal, then it could very well fail.

    Anyway, if you really want to be able to use the P1 properly, you really need a EEPROM. Use 24LC256 at least but you I would recommend the 64kB(yte) or 128kB devices.
  • Peter,

    The caps are actually 0.1uF ceramics that look like tantalums.
    The crystal tracks are cut beside it.
    Hooked in external 3V3 and commoned the ground, same result.

    Thanks Wuerfel, I tried different buffer sizes all the down to the minimum, same result.

    It will load longs up to what appears to be almost exactly half of the 32K RAM, I wonder is there any significance in half being a limit.

    I have ordered 32k EEPROMS as I didn't see how anymore could be useful since RAM is that size, unless of course a program could access the area above 32K in EEPROM for constant data, lookup tables etc.

  • Peter JakackiPeter Jakacki Posts: 9,911
    edited 2020-02-12 - 23:22:49
    Use 64kB EEPROMs because there is only cents difference between them and Tachyon can use the upper half very effectively. Only use 32kB if that is all you can get.

    Do you have decoupling caps on the 3.3V regulator? Where is it? If the regulator ain't stable, the circuit ain't stable. Do you have a shot of the underside?

    It sounds as if your power supply is insufficient and it is drooping, that is, slowly decreasing in voltage as it starts to be used.
    btw, the BOE pin on the P1 should normally be grounded but this will also reset the P1 once the voltage drops too far.
    That definitely doesn't look like an FTDI chip though. Check your settings and make sure the IDE is not trying to switch to a higher baud rate - just in case.
  • The USB Serial is CH340. I know I could have issues around decoupling and wandering power voltages but my symptoms are rock steady and very reproducible on a laptop and a Lenova IdeaPad with and without external power. I would have imagined that I might get slightly varied results. The PSU is a lab bench type.
  • Sorry, I still don't know where and what the 3.3V supply is (not 5V of course).
  • Yes, larger EEPROMs can be used to store some extra data - in practice, 128K EEPROM costs barely more than 32K at one-off quantities.

    EEPROM loading won't work if RAM loading doesn't work...

    Do you have access to a different serial dongle?
  • Gotta get some sleep now but I do have a Silabs CP2102 that I'll try tomorrow. The PSU is outputting 3.3V.
  • Peter JakackiPeter Jakacki Posts: 9,911
    edited 2020-02-13 - 00:13:20
    3.3V is 3.3V at low current, but is it 3.3V at higher current. If this is being supplied from the module, then this will not work unless it is a discrete regulator but any data I have found for the Baite BTE13-009 (I worked it out) says it is not, it is simply 3.3V from/to the chip.

    Note - a tiny 3V watch battery will be 3V and power an unprogrammed P1 at reset, but droop and probably fail when you start loading up the P1 and loading up the supply. Watch the supply on a scope and I am sure you will see it droop and drop very badly.

    This is the only information I can find about the module that says anything about "3V output". It says up to 120ma :) But normally the CH340 can't supply that without losing regulation or shutting down after a short period due to overheating.
    Ahhh - found a reference, it says " it's a 3.3v LDO rated to 25mA " but in the same forum it is saying that the 3.3V is all over the place, even below 3V on some chips. Definitely DO NOT use this as your supply.
  • I used my bench PSU set at 3.3V delivering 18mA to supply power (the PSU is rated for 2A). I watched the supply line on an analogue scope and could not see any variation.
    I tried the Silabs CP2102 module and the COM Port wasn't even recognised on a scan by Prop Tool. Same thing applied to a FTDI module. My Aliexpress CH340 works perfectly every time unless I am writing to the upper half of RAM or maybe that the download is taking longer than something can tolerate.
    What is the Spin code to write a value to RAM and read it back. (I haven't had a chance to get into the language because of this issue). I want to see if Spin can actually access the upper half of RAM.
    Any chance that there are 16K P1's out there that I might have bought?
  • Admittedly it won't draw much current in RCFAST mode, but once the crystal is used the current ramps up. But there are too many strange things happening that you can't really dismiss any one of them if you want to get to the bottom of the mystery.

    Can you simplify this by compiling and loading the Tachyon5v7.spin file first off. If that works, then you can track down what's going on from there.

    I don't know what O/S you are using but you should be able to detect the CP2102 and FTDI in device manager in Windows.

  • Wuerfel_21Wuerfel_21 Posts: 1,074
    edited 2020-02-13 - 16:19:35
    Prop Tool won't detect a Propeller if it isn't being reset - try setting the reset signal in Edit->Preferences->Operation to DTR & RTS. Also change the serial port from AUTO to whatever your Prop is connected to.

    There is exactly one non-prototype, non-FPGA Prop1 variant, BTW. (And a RAM failure would result in a checksum error)

    If you want to access arbitrary RAM/ROM in Spin, simply use LONG[address] (where "address" is any expression). (there's also BYTE and WORD)
      LONG[$4000] := 1
      result := LONG[$4000]
  • jmgjmg Posts: 14,563
    pmulvey wrote: »
    Any chance that there are 16K P1's out there that I might have bought?
    None. Just one die exists.

    pmulvey wrote: »
    I tried the Silabs CP2102 module and the COM Port wasn't even recognised on a scan by Prop Tool. Same thing applied to a FTDI module.
    Do those detect on your OS as COMxx ports ?
    As mentioned above, a handshake line needs to be present to reset the Prop, but all serial ports should connect ok.
    A simple loop-back check on any terminal can verify your USB-Serials.

  • Btw, both VCC pins and both Vss pins on the Prop MUST be shorted together externally.
  • Ports for both modules showing up in Device Mngr. Scope shows reset pulse at pin of chip for both modules. Power pins cross connected under the board. I can write and read RAM up at $7000 so RAM Ok. I have 4k7 resistors on TX, RX and DTR because the modules are 5V, any issue here I wonder.
  • Peter mentioned it but it kinda got lost: do you have the BOE pin grounded? If no, try it with BOE grounded. If yes, try pulling BOE high and add an external pullup resistor on the reset line.

    Also maybe try a different PC if you have one laying around.
  • Peter JakackiPeter Jakacki Posts: 9,911
    edited 2020-02-14 - 03:05:48
    So how is the situation with using the CH340 which seems to work and loading the Tachyon kernel? Once that is loaded you can talk to the P1 and dump memory etc or even extend Tachyon with EXTEND.FTH which also has the EEPROM extensions for backing up.

    Maybe now is the time for a photo of the underside because maybe we will see something that you missed. This is simple hardware and usually when there is a problem, it is something very simple,
Sign In or Register to comment.