Congratulations!

[Valid RSS] This is a valid RSS feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

Source: https://forums.parallax.com/categories/propeller-1-multicore-microcontroller/feed.rss

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <rss version="2.0"
  3.    xmlns:content="http://purl.org/rss/1.0/modules/content/"
  4.    xmlns:dc="http://purl.org/dc/elements/1.1/"
  5.    xmlns:atom="http://www.w3.org/2005/Atom">
  6.    <channel>
  7.        <title>Propeller 1 — Parallax Forums</title>
  8.        <link>https://forums.parallax.com/</link>
  9.        <pubDate>Sun, 14 Jul 2024 03:59:48 +0000</pubDate>
  10.        <language>en</language>
  11.            <description>Propeller 1 — Parallax Forums</description>
  12.    <atom:link href="https://forums.parallax.com/categories/propeller-1-multicore-microcontroller/feed.rss" rel="self" type="application/rss+xml"/>
  13.    <item>
  14.        <title>CAN FD</title>
  15.        <link>https://forums.parallax.com/discussion/175927/can-fd</link>
  16.        <pubDate>Wed, 10 Jul 2024 07:51:38 +0000</pubDate>
  17.        <category>Propeller 1</category>
  18.        <dc:creator>David Betz</dc:creator>
  19.        <guid isPermaLink="false">175927@/discussions</guid>
  20.        <description><![CDATA[<p>Has anyone implemented the CAN FD protocol on the P1 (or P2)? If so, how fast can it go?</p>
  21. ]]>
  22.        </description>
  23.    </item>
  24.    <item>
  25.        <title>simple ide question wifi  semi solved with a new queston based on the fix.  SOLVED</title>
  26.        <link>https://forums.parallax.com/discussion/175913/simple-ide-question-wifi-semi-solved-with-a-new-queston-based-on-the-fix-solved</link>
  27.        <pubDate>Sun, 16 Jun 2024 06:48:46 +0000</pubDate>
  28.        <category>Propeller 1</category>
  29.        <dc:creator>pilot0315</dc:creator>
  30.        <guid isPermaLink="false">175913@/discussions</guid>
  31.        <description><![CDATA[<p>Trying something else before sending the question through.</p>
  32.  
  33. <p>That idea did not work.<br />
  34. So I am back again with the question. Simple ide does not see the prop via wifi.<br />
  35. Using wifi.start routine does not work.<br />
  36. The connect file is directly from the learn files.<br />
  37. Any ideas any one please.<br />
  38. @VonSzarvas</p>
  39.  
  40. <p>Tried your suggestion. Cannot get into simple ide to change anything.<br />
  41. Thanks.<br />
  42. Martin</p>
  43. ]]>
  44.        </description>
  45.    </item>
  46.    <item>
  47.        <title>Microcomputer</title>
  48.        <link>https://forums.parallax.com/discussion/175347/microcomputer</link>
  49.        <pubDate>Sat, 06 May 2023 22:58:50 +0000</pubDate>
  50.        <category>Propeller 1</category>
  51.        <dc:creator>NickMikhay</dc:creator>
  52.        <guid isPermaLink="false">175347@/discussions</guid>
  53.        <description><![CDATA[<p>Hello,</p>
  54.  
  55. <p>I have been following several articles online on homebrew computers using vintage chips from Intel or Zilog as well as a few others, and I was thinking it would be great to use a Propeller or even a P2 as the main processor.</p>
  56.  
  57. <p>The question is on how to get started with the operating system, so that you would’t have to upload the program when you write spin programs and compile. If spin the tool simply tokenizes the code and translates it to binary, wouldn’t that be easy enough for the propeller to do this on its own.</p>
  58.  
  59. <p>It sounds to me like tokenizing is a lot like parsing which is just translating text data from one form to another? I have done this before on a gerberx2 file to convert it to g-code.</p>
  60.  
  61. <p>If anyone can help, I would appreciate it, just name your price. I have always wanted to build a computer from scratch and code it up with an interpreter, and make it do all kinds of stuff. In fact I had the idea while I was attending class, but due to deadlines decided not to since I wouldn’t be able to complete it in time for my final project.</p>
  62. ]]>
  63.        </description>
  64.    </item>
  65.    <item>
  66.        <title>P1 upload Protocol to EEPROM</title>
  67.        <link>https://forums.parallax.com/discussion/175905/p1-upload-protocol-to-eeprom</link>
  68.        <pubDate>Sat, 08 Jun 2024 12:34:06 +0000</pubDate>
  69.        <category>Propeller 1</category>
  70.        <dc:creator>pic18f2550</dc:creator>
  71.        <guid isPermaLink="false">175905@/discussions</guid>
  72.        <description><![CDATA[<p>Hello,<br />
  73. is the protocol described somewhere how the upload is done in the P1 into the EPROM?</p>
  74. ]]>
  75.        </description>
  76.    </item>
  77.    <item>
  78.        <title>P8X32A Emulation on Tang20K FPGA</title>
  79.        <link>https://forums.parallax.com/discussion/175828/p8x32a-emulation-on-tang20k-fpga</link>
  80.        <pubDate>Tue, 23 Apr 2024 14:54:39 +0000</pubDate>
  81.        <category>Propeller 1</category>
  82.        <dc:creator>ti85</dc:creator>
  83.        <guid isPermaLink="false">175828@/discussions</guid>
  84.        <description><![CDATA[<p>I came across a newer, low-cost FPGA called the Tang20K. I'm wondering if anyone has experience with it and the feasibility of running P8X32A emulation on this platform. Parallax has provided the Verilog files, but I'm unfamiliar with Verilog or hardware coding in general.</p>
  85.  
  86. <p>My question is: what steps would be necessary to get the Propeller 1 running on the Tang20K (if possible at all)? I'm interested in pursuing this because I'd like to explore options for increasing the Propeller 1's processing power, such as expanding hub RAM or adding more cogs.</p>
  87. ]]>
  88.        </description>
  89.    </item>
  90.    <item>
  91.        <title>Yet Another WS2812/SK6812 Driver</title>
  92.        <link>https://forums.parallax.com/discussion/175898/yet-another-ws2812-sk6812-driver</link>
  93.        <pubDate>Thu, 30 May 2024 21:27:42 +0000</pubDate>
  94.        <category>Propeller 1</category>
  95.        <dc:creator>Ding-Batty</dc:creator>
  96.        <guid isPermaLink="false">175898@/discussions</guid>
  97.        <description><![CDATA[<p>Just uploaded to the ObEx: Yet Another WS2812/SK6812 driver<br /><a rel="nofollow" href="https://obex.parallax.com/obex/yet-another-ws2812-sk6812-driver/">https://obex.parallax.com/obex/yet-another-ws2812-sk6812-driver/<br /></a></p>
  98.  
  99. <p>This driver manages one or two strings of WS2812-like addressable RGB LEDs. It handles mapping the color layout in memory to the color output order of different type of LEDs; it handles mapping the timing requirements of the LEDs based on the system clock speed; it is fairly flexible in how it is configured and controlled.</p>
  100.  
  101. <p>Features:</p>
  102.  
  103. <ul><li>Controls one or two strings of LEDs</li>
  104. <li>Normal or inverted output (for use with an inverting buffer/isolator/level-shifter).</li>
  105. <li>Clock cycle accurate timings in all cases (maximum 1/2 system clock error).</li>
  106. <li>Handles either three or four color LED string (with limitations, see below).</li>
  107. <li><p>Flexible configuration:</p>
  108.  
  109. <ul><li>Predefined configurations for:</li>
  110. <li>WS2811, WS2812, WS2812B, WS2813, WS2815</li>
  111. <li>SK6812RGB, SK6812RGBW</li>
  112. <li>SM16703</li>
  113. <li>User defined configurations:</li>
  114. <li>Should work for all LEDs that use pulse-width encoding of 0/1, with fixed time per bit.</li>
  115. <li>Timing specified in nanoseconds.</li>
  116. <li>The two strings can be different types (with a few limitations)</li>
  117. <li>The two strings can have different lengths</li>
  118. <li>The two strings can use different color byte order.</li>
  119. <li>The two strings can have normal/inverted output independently</li>
  120. <li>Flexible memory layout for colors per LED, and iteration over the memory locations for the individual LEDs in a chain.</li>
  121. </ul></li>
  122. <li><p>Should work for all clock speeds from 48 MHz up for a typical RGB LED that uses a 1.25 us bit time.</p>
  123.  
  124. <ul><li>It might work at 40 MHz, which would use a bit time of 1.5 us, which is 20% too long, but might fall within the acceptable tolerance for many LED types.</li>
  125. </ul></li>
  126. <li><p>Periodic refresh (e.g. 100 Hz), or on-demand refresh (refresh-and-pause)</p></li>
  127. </ul><p>Limitations:</p>
  128.  
  129. <ul><li>Typically requires a system clock of 48 MHz or higher.</li>
  130. <li>The two strings must have the same overall bit timing (but the zero and one times per bit may be different), e.g. 1.25 us as used by WS2812-type LEDs)</li>
  131. <li>The two strings must have the same number of colors, either 3 or 4. Four colors are used for RGBW LEDs.</li>
  132. <li>Color values of 8 bits are sent out high order bit first.</li>
  133. <li>The two strings use the same update frequency, because they are updated in parallel. The shorter string will not get "extra" channels of output.</li>
  134. <li><p>For the most flexibility, the memory layout of the colors for each LED in the string should be in a single LONG. There is a demonstration of using three bytes for a string of RGB LEDs, but there is little<br />
  135. flexibility of layout, and the string myst be a multiple of 4 LEDs in length.</p></li>
  136. <li><p>Currently, the number and types of LEDs in the strings is fixed at initialization. That might change in the future.</p></li>
  137. </ul>]]>
  138.        </description>
  139.    </item>
  140.    <item>
  141.        <title>Fast HUB75 display driver, display write routines, and other goodies.</title>
  142.        <link>https://forums.parallax.com/discussion/175765/fast-hub75-display-driver-display-write-routines-and-other-goodies</link>
  143.        <pubDate>Fri, 08 Mar 2024 21:27:09 +0000</pubDate>
  144.        <category>Propeller 1</category>
  145.        <dc:creator>Ding-Batty</dc:creator>
  146.        <guid isPermaLink="false">175765@/discussions</guid>
  147.        <description><![CDATA[<p>Here, something I have been playing with for a while now, and I think it's ready for the light of day.</p>
  148.  
  149. <p>I saw Parallax offering <a rel="nofollow" href="https://www.parallax.com/product/hub75-rgb-led-panel-128-x-128-mm-64-x-64-dots/">64x64 RGB LED displays</a>, and then saw the <a rel="nofollow" href="https://forums.parallax.com/discussion/172696/p2-p2-cube/p1">P2 LED Cube project</a>, I thought "that looks like fun!", and I thought it would be a good excuse to start working with the P2. So I got a few displays, and the <a rel="nofollow" href="https://www.parallax.com/product/p2-eval-hub75-adapter-board/">P2 Eval HUB75 Adapter Board</a>.</p>
  150.  
  151. <p>Then I though, why not get it working with the P1 as a warm-up, so that I fully understand what it takes. I saw Ray's thread on the work done (&gt; ten years ago!) but I wanted to write my own code, and address a few things I thought would work better. One long deep dive later, and here I am, with four versions of the PASM display refresh driver, PASM write helpers, and a pile of test programs. (And I still have not started working with the P2, sigh.)</p>
  152.  
  153. <p>Two versions of the display driver are bit-banged, and two use the video generator; the fastest one, which therefore allows the most bits per color, sends data at sysclock/4 for each row.</p>
  154.  
  155. <p>Here are the refresh rates for 64x64 and 64x128 displays at all the numbers of color bits:</p>
  156.  
  157. <pre spellcheck="false" tabindex="0">Display: 64x64
  158.  
  159.  Color
  160.  Depth   Waitcnt   Repeat    Vid8clk    Vid4clk
  161.  -----   ------    ------    -------    -------
  162.    1     2888.1    2942.5    4340.3     7800.3
  163.    2      963.9     988.1    1446.8     2601.5
  164.    3      413.2     425.6     620.0     1115.3
  165.    4      192.9     199.2     289.4      520.6
  166.    5       93.3      96.6     140.0      252.0
  167.    6       45.9      47.6      68.9      124.0
  168.    7       22.8      23.6      34.2       61.5
  169.    8       11.3      11.8      17.0       30.6
  170.  
  171. Display: 128x64 (two 64x64 panels in series)
  172.  
  173.  COLOR_DEPTH=8 is not available because the display buffer would take up _all_
  174.  of hub ram: 32KiB -- it also would flicker too much, anyway.
  175.  
  176.  Color
  177.  Depth   Waitcnt   Repeat    Vid8clk    Vid4clk
  178.  -----   ------    ------    -------    -------
  179.    1     1530.3    1545.5    2297.8     4336.5
  180.    2      510.5     517.2     765.9     1445.9
  181.    3      218.8     222.2     328.3      619.8
  182.    4      102.1     103.9     153.2      289.3
  183.    5       49.4      50.3      74.1      140.0
  184.    6       24.3      24.8      36.5       68.9
  185.    7       12.1      12.3      18.1       34.2
  186.    8       n/a       n/a       n/a        n/a
  187. </pre>
  188.  
  189. <p>Note that any refresh rate &lt; 60Hz will probably have too much flicker.</p>
  190.  
  191. <p>The display uses one byte for each pair of LEDs on the display, so a 64x64 display uses 2KiB for each bit of color.</p>
  192.  
  193. <p>Along with that, there is a PASM write helper to write to the display buffer, since the memory layout of the pixels is designed for display refresh speed, and is otherwise... inconvenient.</p>
  194.  
  195. <p>There are six test programs included, each of which exploring something specific. I was looking mostly at digit displays (think clocks or counters), and exploring digit change animations, so there is heavy focus on that in those test programs. The most recent, and probably most elaborate and complete, is <code spellcheck="false" tabindex="0">test_clock_bitmap.spin</code> which implements a digital clock, 4 or 6 digits, 12/24 hour, with control over time, color, intensity, and many digit change animations. (The digits are ROM font bitmaps.)</p>
  196.  
  197. <p>In addition, because using a higher numbers of color bits and larger displays, the display buffer can get quite large, I did some, ah, <em>unusual things</em> to maximize the available hub memory for the display buffer, including reusing not only all the PASM cog images in hub memory, but also other init-specific Spin code; the clock example recovers about 4KiB that way. This is discussed in the file <code spellcheck="false" tabindex="0">large_buffers.txt</code>.</p>
  198.  
  199. <p>I also have, if folks are interested, the set of about 14 test programs I wrote to get a handle on synchronizing the Waitvid data hand-off point, hub access, and a separate clock, based on video work @kuroneko  did many years ago.</p>
  200.  
  201. <p>Right now I only have displays based on the ICN2037 controller chip, so that is all I have tested. I know that the P2 HUB75 driver that @"Stephen Moraco" has shepherded can handle many more.</p>
  202.  
  203. <p>Here are a few photos of my set-up -- using a Board of Education to use the prototyping area -- and the P2 Hub Adapter Board, with breadboard pin adapters:</p>
  204.  
  205. <p><img src="https://forums.parallax.com/uploads/editor/0j/l6mzm32mqpeg.jpg" alt="" title="" /><br /><img src="https://forums.parallax.com/uploads/editor/8b/ys7y2lripcv9.jpg" alt="" title="" /><br /><img src="https://forums.parallax.com/uploads/editor/7u/dxw5qpc1zcdt.jpg" alt="" title="" /></p>
  206. ]]>
  207.        </description>
  208.    </item>
  209.    <item>
  210.        <title>Fastest method to share VAR between 2 P1's</title>
  211.        <link>https://forums.parallax.com/discussion/175880/fastest-method-to-share-var-between-2-p1s</link>
  212.        <pubDate>Wed, 08 May 2024 14:23:16 +0000</pubDate>
  213.        <category>Propeller 1</category>
  214.        <dc:creator>T Chap</dc:creator>
  215.        <guid isPermaLink="false">175880@/discussions</guid>
  216.        <description><![CDATA[<p>I have a P1 board that drives 1 BLDC motor with encoder and the code is very involved, the P1 is maxed out for cogs and ram.</p>
  217.  
  218. <p>I have a project that requires 3 motors and am thinking to add a second P1 to the board to handle the excess, using existing working code.  I want the P1MainBoard to act as if it  some values in it that are actually values used in the P1SubBoard VAR space and cogs.   There could be 10-20 Longs that need to be shared in real time as fast as possible. Most of the values are only moving from the P1SubBoard &gt; P1MainBoard constantly in repeat.  A few might move from P1MainBoard &gt; P1SubBoard on demand.  The goal is to try to keep existing code as in tact as possible, just move some engine blocks to another P1.  But to keep code intact the values from the SubBoard must be read very fast in a loop that never stops sending.</p>
  219.  
  220. <p>In thinking about this, it looks like many objects will have to get moved the SubBoard and the MainBoard can send Opcodes with values to the SubBoard serially as commands with updates, then the SubBoard drives the objects and does the work.  A typical example for one of the three motor engines is a PID that is driving an SPI DAC for motor speed, Direction Pin, checking encoder position.  Each PID loop is a cog(x3).  SPI DAC motor speed for all 3 motors can be 1 cog(use Chip select 1/2/3 in one SPI loop ie 1 cog).  Checking three quad encoders for 3 motors is 3 cogs.</p>
  221.  
  222. <p>SubBoard 3+1+3 = 7cogs plus a main loop keeping things updated and sharing data = 8</p>
  223.  
  224. <p>VARs SubBoard to MainBoard in a fast loop, never stops.<br />
  225. LONG EncoderValue1, EncoderValue2, EncoderValue3<br />
  226. WORD MotorSpeed1, MotorSpeed2, MotorSpeed3<br />
  227. Byte ErrorMessage1, ErrorMessage2, ErrorMessage3</p>
  228.  
  229. <p>VARs  MainBoard to SubBoard  as needed. <br />
  230. BYTE MotorEnable1, MotorEnable2, MotorEnable3<br />
  231. WORD MotorSpeed1, MotorSpeed2, MotorSpeed3</p>
  232.  
  233. <p>This is just a starting point of hashing this out, surely more to add to each VAR section for sharing.  But I first need to get a plan as to how to do this to get a board underway with 2xP1 chips.  With P1's next to each other on a PCB, one option is fast serial.  The SubBoard could send a packet with a packet header Opcode and always include a fixed length of values following.  The MainBoard looks for the packet header, and reads all subsequent values into their respective VAR values.  256k possible?  128 should be easy I think.  A repeat loop in SubBoard is always waiting for 1ms for a byte to come in from MainBoard with an Opcode and optional data bytes.  If it sees a valid Opcode, it handles the request, then resumes sending data.</p>
  234.  
  235. <p>SubBoard</p>
  236.  
  237. <pre spellcheck="false" tabindex="0">PUB MainLoop
  238.     WaitForByte(1).  ' wait 1 ms for a byte.  if no byte continue
  239.         'If opcode &gt; 0
  240.             ' Do the command
  241.     SendData
  242.       'Send all data in a packet back to MainBoard
  243.  
  244. </pre>
  245.  
  246. <p>Thanks for any suggestions on how to do this.</p>
  247. ]]>
  248.        </description>
  249.    </item>
  250.    <item>
  251.        <title>P1 WiFi module limitations for sockets and background tasks</title>
  252.        <link>https://forums.parallax.com/discussion/175764/p1-wifi-module-limitations-for-sockets-and-background-tasks</link>
  253.        <pubDate>Fri, 08 Mar 2024 14:11:38 +0000</pubDate>
  254.        <category>Propeller 1</category>
  255.        <dc:creator>Rsadeika</dc:creator>
  256.        <guid isPermaLink="false">175764@/discussions</guid>
  257.        <description><![CDATA[<p>In my WiFi module html program I am thinking about implementing some javascript background tasks and some html socket server code. Anybody have any idea as to what limitations I would be running into, and could the P1 WiFi module handle something like that. I know there is a ram limitation for the files, what else?</p>
  258.  
  259. <p>Ray</p>
  260. ]]>
  261.        </description>
  262.    </item>
  263.    <item>
  264.        <title>Propeller Activity Board WX and BME680 Environmental Sensor</title>
  265.        <link>https://forums.parallax.com/discussion/175803/propeller-activity-board-wx-and-bme680-environmental-sensor</link>
  266.        <pubDate>Fri, 12 Apr 2024 07:44:39 +0000</pubDate>
  267.        <category>Propeller 1</category>
  268.        <dc:creator>LyBui24</dc:creator>
  269.        <guid isPermaLink="false">175803@/discussions</guid>
  270.        <description><![CDATA[<p>There are totally 6 pins on the BME680 sensor. Using I2C connection, I want to connect the pin 28 with SCL and pin 29 with SDA of the sensor, but pin 28 and 29 are not on the breadboard to be accessed. How can I do it?</p>
  271. ]]>
  272.        </description>
  273.    </item>
  274.    <item>
  275.        <title>Thermocouple measurement</title>
  276.        <link>https://forums.parallax.com/discussion/154830/thermocouple-measurement</link>
  277.        <pubDate>Thu, 20 Mar 2014 03:10:06 +0000</pubDate>
  278.        <category>Propeller 1</category>
  279.        <dc:creator>ManAtWork</dc:creator>
  280.        <guid isPermaLink="false">154830@/discussions</guid>
  281.        <description><![CDATA[I plan to make a propeller based reflow oven controller. To measure high temperatures (up to 300°C) I have to use thermocouples. I think I'll use the LTC2440 as ADC. It has enough resolution to measure the thermo voltage directly without pre-amplifier, so I can get rid of any offset and calibration problems.<br /><br />
  282. But as thermocouples only measure relative temperatures I have to add an absolute temperature sensor for cold junction compensation. What is the preferable device for this? The LM75B would be nice as it has an I²C interface and doesn't require any extra pins but can be connected to pins 28/29 where the EEPROM already is connected. It is cheap but has relatively poor accuracy (+/-2° in the -25 to +100°C range).<br /><br />
  283. I have seen there is a TMP102 object in the OBEX and a DS2760 thermocouple kit. The TMP102 looks good but when I look at the datasheet of the DS2760 it shows a Li battery monitor that has nothing to do with a thermocouple, IMHO.<br /><br />
  284. I have to read at least 6 thermocouples. There is a 4-input version of the LTC2440 but as I need 6 I think I'd better handle multiplexing externally. (The 8 channel versions are single ended, only) Has anybody already done something similar. What would you suggest?]]>
  285.        </description>
  286.    </item>
  287.    <item>
  288.        <title>P1 counters can you configure a counter to divide a freq on one pin and output it on another?</title>
  289.        <link>https://forums.parallax.com/discussion/175776/p1-counters-can-you-configure-a-counter-to-divide-a-freq-on-one-pin-and-output-it-on-another</link>
  290.        <pubDate>Tue, 19 Mar 2024 00:59:55 +0000</pubDate>
  291.        <category>Propeller 1</category>
  292.        <dc:creator>Kurt123</dc:creator>
  293.        <guid isPermaLink="false">175776@/discussions</guid>
  294.        <description><![CDATA[<p>Hello<br />
  295. I want to divide a pulse train on one pin and output it on another pin. Looking at the documentation I can't understand counters enough to figure it out.<br />
  296. Any help would be appreciated.<br />
  297. Thanks<br />
  298. Kurt</p>
  299. ]]>
  300.        </description>
  301.    </item>
  302.    <item>
  303.        <title>Incompatible driver, Propeller tool</title>
  304.        <link>https://forums.parallax.com/discussion/175767/incompatible-driver-propeller-tool</link>
  305.        <pubDate>Sat, 09 Mar 2024 14:53:27 +0000</pubDate>
  306.        <category>Propeller 1</category>
  307.        <dc:creator>Moskog</dc:creator>
  308.        <guid isPermaLink="false">175767@/discussions</guid>
  309.        <description><![CDATA[<p>Hi.. not able to access my Propeller because of "incompatible driver" on my new win 11 desktop, after installing Propeller Tool, latest version.<br />
  310. Had to turn Memory integrity to Off, but it seems that's not good for the Core security.</p>
  311.  
  312. <p>A good advice on how to solve this problem would be highly appreciated!</p>
  313. ]]>
  314.        </description>
  315.    </item>
  316.    <item>
  317.        <title>PropTool 2.9.3 fails loading a (not too) large P1 program</title>
  318.        <link>https://forums.parallax.com/discussion/175762/proptool-2-9-3-fails-loading-a-not-too-large-p1-program</link>
  319.        <pubDate>Wed, 06 Mar 2024 20:55:10 +0000</pubDate>
  320.        <category>Propeller 1</category>
  321.        <dc:creator>Ding-Batty</dc:creator>
  322.        <guid isPermaLink="false">175762@/discussions</guid>
  323.        <description><![CDATA[<p>This is about the "Error: communication stalled due to system problem" that seems to happen sometimes. I started seeing that failure after installing V2.9.3, but only for some of my programs, and it seemed to happen only with the largest program images.</p>
  324.  
  325. <p>In fact, the large program is loaded, but PropTool reports a communications failure.</p>
  326.  
  327. <p>I have reduced the problem to a simple test program, which has a large LONG array in a DAT section, and when the size is increased by <em>one LONG</em>, the failure is triggered.</p>
  328.  
  329. <p>Program (also attached as no_op_memory.spin):</p>
  330.  
  331. <pre spellcheck="false" tabindex="0">CON { General constants }
  332.  _CLKMODE = XTAL1 + PLL16X
  333.  _XINFREQ = 5_000_000
  334.  
  335. DAT
  336.  ' Make the binary image big. Too big, and P1 load fails in PropTool 2.9.3 on
  337.  ' a Windows 7 machine with the latest FTDI drivers.
  338.  'KeepMemory     LONG 0[6083]    ' Loads OK
  339.  KeepMemory     LONG 0[6083 + 1] ' Fails
  340.  
  341.  ' PropTool error dialog:
  342.  '   "Error: communication stalled due to system problem"
  343.  
  344. ' ========================================================================
  345. PUB Main
  346.  repeat  ' wait forvever.
  347. </pre>
  348.  
  349. <p>This happens after a fresh install of 2.9.3. It does not happen with the old PropTool  1.3.2, nor the other Spin compilers.</p>
  350.  
  351. <p>My system:<br />
  352. Window 7, 32GiB memory<br />
  353. latest FTDI drivers, downloaded today from the FTDI website (I had originally allowed the PropTool installer to also install its USB drivers, but I saw the driver version seemed to be from 2016.)</p>
  354.  
  355. <p>I tried quite a few settings variations for the COM port (Advanced settings), but nothing seemed to help.</p>
  356.  
  357. <p>I saw that Prof. Braino (@profbraino) had <a rel="nofollow" href="https://forums.parallax.com/discussion/175427/error-communication-stalled-due-to-system-problem-prop-tool-2-9-3-prop-1">reported this back in Aug. 2023</a>, and I was surprised that no one responded.</p>
  358. ]]>
  359.        </description>
  360.    </item>
  361.    <item>
  362.        <title>Simpleide simpletools problem?</title>
  363.        <link>https://forums.parallax.com/discussion/175743/simpleide-simpletools-problem</link>
  364.        <pubDate>Sat, 24 Feb 2024 15:48:45 +0000</pubDate>
  365.        <category>Propeller 1</category>
  366.        <dc:creator>Rsadeika</dc:creator>
  367.        <guid isPermaLink="false">175743@/discussions</guid>
  368.        <description><![CDATA[<p>Up until recently I have been using libfdserial and libsimpletext without any problems. I am using a program that that uploads data via serial to my Raspberry Pi. On the SimpleIDE side the program runs as expected, but on the Raspberry Pi side,using Python, I have to use decode() on the incoming data. This is where the problem lies, ..."can't decode byte 0xea in position 0"... Not sure what is causing this problem? Any help will be appreciated.</p>
  369.  
  370. <p>Thanks<br />
  371. Ray</p>
  372. ]]>
  373.        </description>
  374.    </item>
  375.    <item>
  376.        <title>[Solved] Program works only when connected to PC via USB -- but I want to cut the cord!</title>
  377.        <link>https://forums.parallax.com/discussion/175742/solved-program-works-only-when-connected-to-pc-via-usb-but-i-want-to-cut-the-cord</link>
  378.        <pubDate>Sat, 24 Feb 2024 05:58:47 +0000</pubDate>
  379.        <category>Propeller 1</category>
  380.        <dc:creator>mpark</dc:creator>
  381.        <guid isPermaLink="false">175742@/discussions</guid>
  382.        <description><![CDATA[<p>I am dusting off an old project built on a USB protoboard. The program emits a lot of serial data that shows up in the Parallax serial terminal; so far so good. I actually don't care about the data and want to run the program disconnected from the PC, but when I try, the program does not work reliably. It'll do its thing for a little while, then stop briefly, then start working again, then stop... Not sure if it's rebooting or what. I assume the problem is related to the serial data having no place to go.</p>
  383.  
  384. <p>I vaguely recall that this was a known issue back in the day. Anyone remember what's going on and how to work around it?</p>
  385.  
  386. <p>I tried commenting out the term.init call (term being fullduplexserial) but that didn't help. In fact I think the program stopped working altogether, though it's hard to tell.</p>
  387.  
  388. <p>Any help appreciated!</p>
  389. ]]>
  390.        </description>
  391.    </item>
  392.    <item>
  393.        <title>Propeller schmartmodule</title>
  394.        <link>https://forums.parallax.com/discussion/175714/propeller-schmartmodule</link>
  395.        <pubDate>Sat, 03 Feb 2024 09:27:42 +0000</pubDate>
  396.        <category>Propeller 1</category>
  397.        <dc:creator>VonSzarvas</dc:creator>
  398.        <guid isPermaLink="false">175714@/discussions</guid>
  399.        <description><![CDATA[<p>Groovy!</p>
  400.  
  401. <p><a href="https://embeddedcomputing.com/technology/open-source/development-kits/dev-kit-weekly-schmartboard-parallax-propeller-schmartmodule-development-board" rel="nofollow">https://embeddedcomputing.com/technology/open-source/development-kits/dev-kit-weekly-schmartboard-parallax-propeller-schmartmodule-development-board</a></p>
  402. ]]>
  403.        </description>
  404.    </item>
  405.    <item>
  406.        <title>P1 SPIN code for SSD1306 OLED</title>
  407.        <link>https://forums.parallax.com/discussion/175715/p1-spin-code-for-ssd1306-oled</link>
  408.        <pubDate>Mon, 05 Feb 2024 20:45:16 +0000</pubDate>
  409.        <category>Propeller 1</category>
  410.        <dc:creator>VonSzarvas</dc:creator>
  411.        <guid isPermaLink="false">175715@/discussions</guid>
  412.        <description><![CDATA[<p>128x64 pixel display</p>
  413.  
  414. <p>Has anyone got a SPIN code demo running different size fonts ?</p>
  415.  
  416. <p>I found something in OBEX with a 5x7 font, but it's too tiny.<br />
  417. There's another with 16x32, but it's too large, taking 4 rows out of an available 8.</p>
  418.  
  419. <p>Looking for something in the middle, maybe taking 2 or 3 rows, perhaps 8x12 or 8x16 (or 12x...) size fonts?</p>
  420. ]]>
  421.        </description>
  422.    </item>
  423.    <item>
  424.        <title>Demo for jm_max30102 code</title>
  425.        <link>https://forums.parallax.com/discussion/175705/demo-for-jm-max30102-code</link>
  426.        <pubDate>Wed, 24 Jan 2024 18:39:40 +0000</pubDate>
  427.        <category>Propeller 1</category>
  428.        <dc:creator>masselon</dc:creator>
  429.        <guid isPermaLink="false">175705@/discussions</guid>
  430.        <description><![CDATA[<p>Hi for All</p>
  431.  
  432. <p>Somebody have the refered Demo or the link from where I could  download it?</p>
  433.  
  434. <p>Thanks in advance.</p>
  435. ]]>
  436.        </description>
  437.    </item>
  438.    <item>
  439.        <title>Determine which variable in a group contains the largest value!</title>
  440.        <link>https://forums.parallax.com/discussion/175684/determine-which-variable-in-a-group-contains-the-largest-value</link>
  441.        <pubDate>Thu, 11 Jan 2024 20:43:55 +0000</pubDate>
  442.        <category>Propeller 1</category>
  443.        <dc:creator>AGCB</dc:creator>
  444.        <guid isPermaLink="false">175684@/discussions</guid>
  445.        <description><![CDATA[<p>In a group of 10 variables that are incrementing randomly or some not at all, after a short time (say 1 minute), I want to determine which of the variables contains the highest value. <br />
  446. Aaron</p>
  447. ]]>
  448.        </description>
  449.    </item>
  450.    <item>
  451.        <title>Faster than hub</title>
  452.        <link>https://forums.parallax.com/discussion/175703/faster-than-hub</link>
  453.        <pubDate>Tue, 23 Jan 2024 22:53:33 +0000</pubDate>
  454.        <category>Propeller 1</category>
  455.        <dc:creator>K2</dc:creator>
  456.        <guid isPermaLink="false">175703@/discussions</guid>
  457.        <description><![CDATA[<p>A million years later, a sort-of accidental capability of P1 is still the salvation of many of my projects.  Today's pinch goes something  like this: A cog has only 25 instructions (1.25 uS) with which to fetch a five-bit value from another cog, do a local table look-up, a quick calculation, clock the results out serially, and finish a waitcnt (for sync purposes).</p>
  458.  
  459. <p>There is absolutely no time to wait for a variable length rdlong to execute.  Grabbing the 5-bit word from port A, written there by another cog, is the only way forward.  I LOVE that hack.</p>
  460.  
  461. <p>I was a stinker campaigning for something like that on P2, which Chip accommodated by letting neighboring LUTs talk.  I hope I'm not the only one that has benefited from its inclusion.</p>
  462. ]]>
  463.        </description>
  464.    </item>
  465.    <item>
  466.        <title>Strange SPIN behavior: WaitCnt stalls changing an &quot;unrelated&quot; statement SOLVED</title>
  467.        <link>https://forums.parallax.com/discussion/175699/strange-spin-behavior-waitcnt-stalls-changing-an-unrelated-statement-solved</link>
  468.        <pubDate>Sun, 21 Jan 2024 23:15:08 +0000</pubDate>
  469.        <category>Propeller 1</category>
  470.        <dc:creator>ErNa</dc:creator>
  471.        <guid isPermaLink="false">175699@/discussions</guid>
  472.        <description><![CDATA[<p>I face this strange behavior:<br />
  473. In a loop the variable "Winkel" is increased by one.<br />
  474. `        repeat</p>
  475.  
  476. <pre spellcheck="false" tabindex="0">      WaitCnt (DelayTime)
  477.      Delaytime += 35_000
  478.      Winkel    := Winkel + 1
  479.  
  480.      Winkel :=  Winkel // 1536
  481. </pre>
  482.  
  483. <p>`<br />
  484. So Winkel is robbing around from 0 to 1535. I want to control the increment and introduce a variable dWinkel</p>
  485.  
  486. <p>` <br />
  487.        dWinkel   := 5<br />
  488.        repeat</p>
  489.  
  490. <pre spellcheck="false" tabindex="0">      WaitCnt (DelayTime)
  491.      Delaytime += 35_000
  492.      Winkel    := Winkel + dWinkel
  493.  
  494.      Winkel :=  Winkel // 1536
  495. </pre>
  496.  
  497. <p><code spellcheck="false" tabindex="0">Next I wish to grow dWinkel slowly, so I scale up by 100 and devide by 100</code> <br />
  498.       dWinkel   := 500<br />
  499.        repeat</p>
  500.  
  501. <pre spellcheck="false" tabindex="0">      WaitCnt (DelayTime)
  502.      Delaytime += 35_000
  503.      Winkel    := Winkel + dWinkel/100
  504.  
  505.      Winkel :=  Winkel // 1536
  506. </pre>
  507.  
  508. <p>`<br />
  509. And now nothing happens, the programm stalls. Give it another try:</p>
  510.  
  511. <p>`dWinkel   := 5<br />
  512. repeat</p>
  513.  
  514. <pre spellcheck="false" tabindex="0">      WaitCnt (DelayTime)
  515.      Delaytime += 35_000
  516.      ddWinkel  := dWinkel
  517.      Winkel    := Winkel + ddWinkel
  518.  
  519.      Winkel :=  Winkel // 1536
  520. </pre>
  521.  
  522. <p>`<br />
  523. Return to the original scale and use a second variable: It stalls again. I can not print the value but do not see, what could provoke this?</p>
  524. ]]>
  525.        </description>
  526.    </item>
  527.    <item>
  528.        <title>PropellerIDE on MacOS with FTDI and other issues</title>
  529.        <link>https://forums.parallax.com/discussion/166516/propelleride-on-macos-with-ftdi-and-other-issues</link>
  530.        <pubDate>Mon, 17 Apr 2017 17:14:03 +0000</pubDate>
  531.        <category>Propeller 1</category>
  532.        <dc:creator>Tracy Allen</dc:creator>
  533.        <guid isPermaLink="false">166516@/discussions</guid>
  534.        <description><![CDATA[Since upgrading to OS X Sierra 10.12, I've started using PropellerIDE.  (Thanks, Brett, Steve, and Parallax!) Initially I had a problem with the FTDI serial ports, including but not limited to the Prop Plug and my own FT231X boards.  I hadn't seen this issue mentioned here and it took some hair tearing and googling to figure it out.  The issue is that Apple, starting with OS X Mavericks (10.9), has included a driver for FTDI serial ports along with the system install.  If you then go and download install the FTDI version 2.3 VCP driver directly from FTDIchip.com, the two will conflict.  The symptoms are that you will be able to use the port once, but then if you disconnect the dongle and then come back to it or try to use another one on the same USB port, you will find that it is locked. The only way to get another try is to move to another physical USB port until that gets locks and so on.  If you look in the system report under USB, you will probably find that the same VCP serial port is listed twice.  To fix this,<br />
  535. delete the FTDI driver.  <a href="http://www.ftdichip.com/Support/Documents/AppNotes/AN_134_FTDI_Drivers_Installation_Guide_for_MAC_OSX.pdf" rel="nofollow">AN134 from FTDI</a> describes how. Delete it using Terminal from /Library/Extensions/FTDIUSBserialDriver.kext.   Keep the Apple FTDI driver, which on Sierra is located at /System/Library/Extensions/AppleUSBFTDI.kext.   The name and exact location of the Apple driver on pre-Sierra OS versions is different though.<br /><br />
  536. I see that the instructions on the Parallax web site page for PropellerIDE specifically recommend downloading the FTDI version of the driver.  That suggestion should probably be stricken or nuanced.<br />]]>
  537.        </description>
  538.    </item>
  539.    <item>
  540.        <title>Touchscreens and the propeller - SPI, 8bit parallel, 16bit parallel, 8080 or 6800 - Whats realistic?</title>
  541.        <link>https://forums.parallax.com/discussion/163651/touchscreens-and-the-propeller-spi-8bit-parallel-16bit-parallel-8080-or-6800-whats-realistic</link>
  542.        <pubDate>Fri, 26 Feb 2016 03:42:08 +0000</pubDate>
  543.        <category>Propeller 1</category>
  544.        <dc:creator>Mahonroy</dc:creator>
  545.        <guid isPermaLink="false">163651@/discussions</guid>
  546.        <description><![CDATA[Hey guys,<br />
  547. I have been trying to source a decent touch screen for a while now, and I have hit a dead end.<br />
  548. There are a ton of touch screens out there, they range from using different drivers such as the ILI9325 and the ILI9488. These also come in variations in different methods of communicating with the screen which seem to be SPI, 8 bit parallel, 16 bit parallel, then there is the 8080 &amp; 6800 (I'm not entirely sure what this is, but I'm thinking one is 8 bit and the other is 16 bit?). I've very confused on what the best rout to go with is.<br /><br />
  549. I have a few questions:<br />
  550. * Are there any drivers out there that people have been able to use with any of these popular screens? I could not find one legitimate driver available for the propeller. Well, I found 1 by Mark Tillotson, but it did not work at all.<br />
  551. * Are all SPI commands universal for every touch screen? If I find a library for one SPI screen can it be used on another, or is every screen unique? Finding datasheets on most of the touch screens out there seems impossible.<br />
  552. * Is any of this stuff universal - for any of the parallel drivers? Or is this the same problem... each screen has its own methods of working?<br />
  553. * Is SPI the best rout, or should I be looking for one of the different communication methods?<br />
  554. * Are there some popular screens out there that you guys have been using and have had good results with?<br /><br />
  555. So far I have been experimenting with some of mcufriend.com screens, and some raspberry pi screens, but I am unable to find any information on how to get these to work, or even to start writing a custom library so I can use them.<br />
  556. I found these guys, and they seem to be pretty legit as far as screens go and cost, but I have no idea what I'm looking for:<br /><a href="http://www.buydisplay.com/default/tft-display/4-3-inch" rel="nofollow">http://www.buydisplay.com/default/tft-display/4-3-inch</a><br /><br />
  557. I have used 4D Systems screens in the past, and while they are nice, the price is insane. Surely there must be a better way of doing this.<br />
  558. What do you guys think? Any help is greatly appreciated, thanks!]]>
  559.        </description>
  560.    </item>
  561.    <item>
  562.        <title>New Prop Plug Rev E</title>
  563.        <link>https://forums.parallax.com/discussion/175628/new-prop-plug-rev-e</link>
  564.        <pubDate>Fri, 08 Dec 2023 14:49:03 +0000</pubDate>
  565.        <category>Propeller 1</category>
  566.        <dc:creator>iseries</dc:creator>
  567.        <guid isPermaLink="false">175628@/discussions</guid>
  568.        <description><![CDATA[<p>Just tried this plug on my Propeller Mini and on the dip version and they both fail to load a program.</p>
  569.  
  570. <p>Is there a work around for this or am I stuck using the old prop plug on these units?</p>
  571.  
  572. <p>The guide shows this should work but I tried two Rev E units and they both do not work on P1.</p>
  573.  
  574. <p>They work just fine on P2 though.</p>
  575.  
  576. <p>Mike</p>
  577. ]]>
  578.        </description>
  579.    </item>
  580.    <item>
  581.        <title>P1 Flip Multicore Module Carrier</title>
  582.        <link>https://forums.parallax.com/discussion/175645/p1-flip-multicore-module-carrier</link>
  583.        <pubDate>Fri, 15 Dec 2023 03:04:16 +0000</pubDate>
  584.        <category>Propeller 1</category>
  585.        <dc:creator>David Betz</dc:creator>
  586.        <guid isPermaLink="false">175645@/discussions</guid>
  587.        <description><![CDATA[<p>I missed the web session where this was being discussed. Is there a description of it somewhere?</p>
  588. ]]>
  589.        </description>
  590.    </item>
  591.    <item>
  592.        <title>Does anyone have signal generation code thats output matches the propscope readings?</title>
  593.        <link>https://forums.parallax.com/discussion/126521/does-anyone-have-signal-generation-code-thats-output-matches-the-propscope-readings</link>
  594.        <pubDate>Thu, 21 Oct 2010 14:06:30 +0000</pubDate>
  595.        <category>Propeller 1</category>
  596.        <dc:creator>turbosupra</dc:creator>
  597.        <guid isPermaLink="false">126521@/discussions</guid>
  598.        <description><![CDATA[I am trying to write some signal generation code that the frequency per second calculated in my code will match what I'm seeing on my propscope.<br /><br />
  599. Currently I'm seeing ~5.4khz on my propscope when by math from the code it should be 6khz<br /><br />
  600. If someone has a known good method that produces a solid XXkhz on their prop scope, I'd appreciate being able to test it. Thanks for reading.]]>
  601.        </description>
  602.    </item>
  603.    <item>
  604.        <title>Data from a sensor</title>
  605.        <link>https://forums.parallax.com/discussion/175612/data-from-a-sensor</link>
  606.        <pubDate>Mon, 27 Nov 2023 18:48:30 +0000</pubDate>
  607.        <category>Propeller 1</category>
  608.        <dc:creator>HughWN</dc:creator>
  609.        <guid isPermaLink="false">175612@/discussions</guid>
  610.        <description><![CDATA[<p>Hello,</p>
  611.  
  612. <p>I think I may be being hard of thinking here, but...</p>
  613.  
  614. <p>A doppler radar sensor sends to a P1 (for example) "-26.0", i.e., a string of bytes, 45, 50, 54, 46, 48, 13.</p>
  615.  
  616. <p>Is there an easy way to get this as a value with which I can do things within other parts of the spin code (even if I have to scale it to -260 as an integer to be able to use the tenths part), or do I need to work it out from scratch?  It's not zero-terminated as various string-handler spin files need.</p>
  617.  
  618. <p>I've been round in circles so many times, I'm starting to get dizzy!</p>
  619.  
  620. <p>Thanks,</p>
  621.  
  622. <p>Hugh</p>
  623. ]]>
  624.        </description>
  625.    </item>
  626.    <item>
  627.        <title>looking for an old debugging object</title>
  628.        <link>https://forums.parallax.com/discussion/175614/looking-for-an-old-debugging-object</link>
  629.        <pubDate>Tue, 28 Nov 2023 17:25:53 +0000</pubDate>
  630.        <category>Propeller 1</category>
  631.        <dc:creator>ti85</dc:creator>
  632.        <guid isPermaLink="false">175614@/discussions</guid>
  633.        <description><![CDATA[<p>Hey<br />
  634. I am looking for an old pasm object that was useful for debugging the P1.  It was only a few lines of code and ran in one COG.  You could see hub memory locations and other things.  Does anyone remember what the program called?<br />
  635. Thank you</p>
  636. ]]>
  637.        </description>
  638.    </item>
  639.    <item>
  640.        <title>Trouble with XOJO baud rate</title>
  641.        <link>https://forums.parallax.com/discussion/175611/trouble-with-xojo-baud-rate</link>
  642.        <pubDate>Mon, 27 Nov 2023 14:53:30 +0000</pubDate>
  643.        <category>Propeller 1</category>
  644.        <dc:creator>velocityxlrg</dc:creator>
  645.        <guid isPermaLink="false">175611@/discussions</guid>
  646.        <description><![CDATA[<p>I often use code written in XOJO to get and display telemetry  on a Laptop from my Propeller projects.<br />
  647. This has been occurring at 115200 baud using FullDuplexSerial.  No problems.</p>
  648.  
  649. <p>But today I tried to get XOJO and the Propeller to use 57600.  Nothing but errors from XOJO.  Seem to be frame errors, but hard to tell.  So I tried all the other standard bauds.  Nothing.  It only works at 115200.</p>
  650.  
  651. <p>This seems weird.  I've check all the settings I can think of for both XOJO and the Propeller.</p>
  652.  
  653. <p>Can someone think of a reason this might happen?</p>
  654. ]]>
  655.        </description>
  656.    </item>
  657.   </channel>
  658. </rss>
  659.  

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

  1. Download the "valid RSS" banner.

  2. Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)

  3. Add this HTML to your page (change the image src attribute if necessary):

If you would like to create a text link instead, here is the URL you can use:

http://www.feedvalidator.org/check.cgi?url=https%3A//forums.parallax.com/categories/propeller-1-multicore-microcontroller/feed.rss

Copyright © 2002-9 Sam Ruby, Mark Pilgrim, Joseph Walton, and Phil Ringnalda