![[Valid RSS]](images/valid-rss-rogers.png "Valid RSS")
This is a valid RSS feed.
This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.
<?xml version="1.0" encoding="utf-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"> <channel> <title>Propeller 1 — Parallax Forums</title> <link>https://forums.parallax.com/</link> <pubDate>Fri, 26 Apr 2024 17:10:09 +0000</pubDate> <language>en</language> <description>Propeller 1 — Parallax Forums</description> <atom:link href="https://forums.parallax.com/categories/propeller-1-multicore-microcontroller/feed.rss" rel="self" type="application/rss+xml"/> <item> <title>P8X32A Emulation on Tang20K FPGA</title> <link>https://forums.parallax.com/discussion/175828/p8x32a-emulation-on-tang20k-fpga</link> <pubDate>Tue, 23 Apr 2024 14:54:39 +0000</pubDate> <category>Propeller 1</category> <dc:creator>ti85</dc:creator> <guid isPermaLink="false">175828@/discussions</guid> <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> <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>]]> </description> </item> <item> <title>P1 WiFi module limitations for sockets and background tasks</title> <link>https://forums.parallax.com/discussion/175764/p1-wifi-module-limitations-for-sockets-and-background-tasks</link> <pubDate>Fri, 08 Mar 2024 14:11:38 +0000</pubDate> <category>Propeller 1</category> <dc:creator>Rsadeika</dc:creator> <guid isPermaLink="false">175764@/discussions</guid> <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> <p>Ray</p>]]> </description> </item> <item> <title>Fast HUB75 display driver, display write routines, and other goodies.</title> <link>https://forums.parallax.com/discussion/175765/fast-hub75-display-driver-display-write-routines-and-other-goodies</link> <pubDate>Fri, 08 Mar 2024 21:27:09 +0000</pubDate> <category>Propeller 1</category> <dc:creator>Ding-Batty</dc:creator> <guid isPermaLink="false">175765@/discussions</guid> <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> <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> <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 (> 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> <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> <p>Here are the refresh rates for 64x64 and 64x128 displays at all the numbers of color bits:</p> <pre spellcheck="false" tabindex="0">Display: 64x64 Color Depth Waitcnt Repeat Vid8clk Vid4clk ----- ------ ------ ------- ------- 1 2888.1 2942.5 4340.3 7800.3 2 963.9 988.1 1446.8 2601.5 3 413.2 425.6 620.0 1115.3 4 192.9 199.2 289.4 520.6 5 93.3 96.6 140.0 252.0 6 45.9 47.6 68.9 124.0 7 22.8 23.6 34.2 61.5 8 11.3 11.8 17.0 30.6 Display: 128x64 (two 64x64 panels in series) COLOR_DEPTH=8 is not available because the display buffer would take up _all_ of hub ram: 32KiB -- it also would flicker too much, anyway. Color Depth Waitcnt Repeat Vid8clk Vid4clk ----- ------ ------ ------- ------- 1 1530.3 1545.5 2297.8 4336.5 2 510.5 517.2 765.9 1445.9 3 218.8 222.2 328.3 619.8 4 102.1 103.9 153.2 289.3 5 49.4 50.3 74.1 140.0 6 24.3 24.8 36.5 68.9 7 12.1 12.3 18.1 34.2 8 n/a n/a n/a n/a</pre> <p>Note that any refresh rate < 60Hz will probably have too much flicker.</p> <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> <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> <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> <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> <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> <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> <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> <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>]]> </description> </item> <item> <title>Propeller Activity Board WX and BME680 Environmental Sensor</title> <link>https://forums.parallax.com/discussion/175803/propeller-activity-board-wx-and-bme680-environmental-sensor</link> <pubDate>Fri, 12 Apr 2024 07:44:39 +0000</pubDate> <category>Propeller 1</category> <dc:creator>LyBui24</dc:creator> <guid isPermaLink="false">175803@/discussions</guid> <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>]]> </description> </item> <item> <title>Thermocouple measurement</title> <link>https://forums.parallax.com/discussion/154830/thermocouple-measurement</link> <pubDate>Thu, 20 Mar 2014 03:10:06 +0000</pubDate> <category>Propeller 1</category> <dc:creator>ManAtWork</dc:creator> <guid isPermaLink="false">154830@/discussions</guid> <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 />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 />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 />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?]]> </description> </item> <item> <title>P1 counters can you configure a counter to divide a freq on one pin and output it on another?</title> <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> <pubDate>Tue, 19 Mar 2024 00:59:55 +0000</pubDate> <category>Propeller 1</category> <dc:creator>Kurt123</dc:creator> <guid isPermaLink="false">175776@/discussions</guid> <description><![CDATA[<p>Hello<br />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 />Any help would be appreciated.<br />Thanks<br />Kurt</p>]]> </description> </item> <item> <title>Incompatible driver, Propeller tool</title> <link>https://forums.parallax.com/discussion/175767/incompatible-driver-propeller-tool</link> <pubDate>Sat, 09 Mar 2024 14:53:27 +0000</pubDate> <category>Propeller 1</category> <dc:creator>Moskog</dc:creator> <guid isPermaLink="false">175767@/discussions</guid> <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 />Had to turn Memory integrity to Off, but it seems that's not good for the Core security.</p> <p>A good advice on how to solve this problem would be highly appreciated!</p>]]> </description> </item> <item> <title>PropTool 2.9.3 fails loading a (not too) large P1 program</title> <link>https://forums.parallax.com/discussion/175762/proptool-2-9-3-fails-loading-a-not-too-large-p1-program</link> <pubDate>Wed, 06 Mar 2024 20:55:10 +0000</pubDate> <category>Propeller 1</category> <dc:creator>Ding-Batty</dc:creator> <guid isPermaLink="false">175762@/discussions</guid> <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> <p>In fact, the large program is loaded, but PropTool reports a communications failure.</p> <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> <p>Program (also attached as no_op_memory.spin):</p> <pre spellcheck="false" tabindex="0">CON { General constants } _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 DAT ' Make the binary image big. Too big, and P1 load fails in PropTool 2.9.3 on ' a Windows 7 machine with the latest FTDI drivers. 'KeepMemory LONG 0[6083] ' Loads OK KeepMemory LONG 0[6083 + 1] ' Fails ' PropTool error dialog: ' "Error: communication stalled due to system problem" ' ========================================================================PUB Main repeat ' wait forvever.</pre> <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> <p>My system:<br />Window 7, 32GiB memory<br />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> <p>I tried quite a few settings variations for the COM port (Advanced settings), but nothing seemed to help.</p> <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>]]> </description> </item> <item> <title>Simpleide simpletools problem?</title> <link>https://forums.parallax.com/discussion/175743/simpleide-simpletools-problem</link> <pubDate>Sat, 24 Feb 2024 15:48:45 +0000</pubDate> <category>Propeller 1</category> <dc:creator>Rsadeika</dc:creator> <guid isPermaLink="false">175743@/discussions</guid> <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> <p>Thanks<br />Ray</p>]]> </description> </item> <item> <title>[Solved] Program works only when connected to PC via USB -- but I want to cut the cord!</title> <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> <pubDate>Sat, 24 Feb 2024 05:58:47 +0000</pubDate> <category>Propeller 1</category> <dc:creator>mpark</dc:creator> <guid isPermaLink="false">175742@/discussions</guid> <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> <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> <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> <p>Any help appreciated!</p>]]> </description> </item> <item> <title>Propeller schmartmodule</title> <link>https://forums.parallax.com/discussion/175714/propeller-schmartmodule</link> <pubDate>Sat, 03 Feb 2024 09:27:42 +0000</pubDate> <category>Propeller 1</category> <dc:creator>VonSzarvas</dc:creator> <guid isPermaLink="false">175714@/discussions</guid> <description><![CDATA[<p>Groovy!</p> <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>]]> </description> </item> <item> <title>P1 SPIN code for SSD1306 OLED</title> <link>https://forums.parallax.com/discussion/175715/p1-spin-code-for-ssd1306-oled</link> <pubDate>Mon, 05 Feb 2024 20:45:16 +0000</pubDate> <category>Propeller 1</category> <dc:creator>VonSzarvas</dc:creator> <guid isPermaLink="false">175715@/discussions</guid> <description><![CDATA[<p>128x64 pixel display</p> <p>Has anyone got a SPIN code demo running different size fonts ?</p> <p>I found something in OBEX with a 5x7 font, but it's too tiny.<br />There's another with 16x32, but it's too large, taking 4 rows out of an available 8.</p> <p>Looking for something in the middle, maybe taking 2 or 3 rows, perhaps 8x12 or 8x16 (or 12x...) size fonts?</p>]]> </description> </item> <item> <title>Demo for jm_max30102 code</title> <link>https://forums.parallax.com/discussion/175705/demo-for-jm-max30102-code</link> <pubDate>Wed, 24 Jan 2024 18:39:40 +0000</pubDate> <category>Propeller 1</category> <dc:creator>masselon</dc:creator> <guid isPermaLink="false">175705@/discussions</guid> <description><![CDATA[<p>Hi for All</p> <p>Somebody have the refered Demo or the link from where I could download it?</p> <p>Thanks in advance.</p>]]> </description> </item> <item> <title>Determine which variable in a group contains the largest value!</title> <link>https://forums.parallax.com/discussion/175684/determine-which-variable-in-a-group-contains-the-largest-value</link> <pubDate>Thu, 11 Jan 2024 20:43:55 +0000</pubDate> <category>Propeller 1</category> <dc:creator>AGCB</dc:creator> <guid isPermaLink="false">175684@/discussions</guid> <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 />Aaron</p>]]> </description> </item> <item> <title>Faster than hub</title> <link>https://forums.parallax.com/discussion/175703/faster-than-hub</link> <pubDate>Tue, 23 Jan 2024 22:53:33 +0000</pubDate> <category>Propeller 1</category> <dc:creator>K2</dc:creator> <guid isPermaLink="false">175703@/discussions</guid> <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> <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> <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>]]> </description> </item> <item> <title>Strange SPIN behavior: WaitCnt stalls changing an "unrelated" statement SOLVED</title> <link>https://forums.parallax.com/discussion/175699/strange-spin-behavior-waitcnt-stalls-changing-an-unrelated-statement-solved</link> <pubDate>Sun, 21 Jan 2024 23:15:08 +0000</pubDate> <category>Propeller 1</category> <dc:creator>ErNa</dc:creator> <guid isPermaLink="false">175699@/discussions</guid> <description><![CDATA[<p>I face this strange behavior:<br />In a loop the variable "Winkel" is increased by one.<br />` repeat</p> <pre spellcheck="false" tabindex="0"> WaitCnt (DelayTime) Delaytime += 35_000 Winkel := Winkel + 1 Winkel := Winkel // 1536</pre> <p>`<br />So Winkel is robbing around from 0 to 1535. I want to control the increment and introduce a variable dWinkel</p> <p>` <br /> dWinkel := 5<br /> repeat</p> <pre spellcheck="false" tabindex="0"> WaitCnt (DelayTime) Delaytime += 35_000 Winkel := Winkel + dWinkel Winkel := Winkel // 1536</pre> <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 /> dWinkel := 500<br /> repeat</p> <pre spellcheck="false" tabindex="0"> WaitCnt (DelayTime) Delaytime += 35_000 Winkel := Winkel + dWinkel/100 Winkel := Winkel // 1536</pre> <p>`<br />And now nothing happens, the programm stalls. Give it another try:</p> <p>`dWinkel := 5<br /> repeat</p> <pre spellcheck="false" tabindex="0"> WaitCnt (DelayTime) Delaytime += 35_000 ddWinkel := dWinkel Winkel := Winkel + ddWinkel Winkel := Winkel // 1536</pre> <p>`<br />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>]]> </description> </item> <item> <title>PropellerIDE on MacOS with FTDI and other issues</title> <link>https://forums.parallax.com/discussion/166516/propelleride-on-macos-with-ftdi-and-other-issues</link> <pubDate>Mon, 17 Apr 2017 17:14:03 +0000</pubDate> <category>Propeller 1</category> <dc:creator>Tracy Allen</dc:creator> <guid isPermaLink="false">166516@/discussions</guid> <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 />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 />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 />]]> </description> </item> <item> <title>Touchscreens and the propeller - SPI, 8bit parallel, 16bit parallel, 8080 or 6800 - Whats realistic?</title> <link>https://forums.parallax.com/discussion/163651/touchscreens-and-the-propeller-spi-8bit-parallel-16bit-parallel-8080-or-6800-whats-realistic</link> <pubDate>Fri, 26 Feb 2016 03:42:08 +0000</pubDate> <category>Propeller 1</category> <dc:creator>Mahonroy</dc:creator> <guid isPermaLink="false">163651@/discussions</guid> <description><![CDATA[Hey guys,<br />I have been trying to source a decent touch screen for a while now, and I have hit a dead end.<br />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 & 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 />I have a few questions:<br />* 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 />* 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 />* 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 />* Is SPI the best rout, or should I be looking for one of the different communication methods?<br />* Are there some popular screens out there that you guys have been using and have had good results with?<br /><br />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 />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 />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 />What do you guys think? Any help is greatly appreciated, thanks!]]> </description> </item> <item> <title>New Prop Plug Rev E</title> <link>https://forums.parallax.com/discussion/175628/new-prop-plug-rev-e</link> <pubDate>Fri, 08 Dec 2023 14:49:03 +0000</pubDate> <category>Propeller 1</category> <dc:creator>iseries</dc:creator> <guid isPermaLink="false">175628@/discussions</guid> <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> <p>Is there a work around for this or am I stuck using the old prop plug on these units?</p> <p>The guide shows this should work but I tried two Rev E units and they both do not work on P1.</p> <p>They work just fine on P2 though.</p> <p>Mike</p>]]> </description> </item> <item> <title>P1 Flip Multicore Module Carrier</title> <link>https://forums.parallax.com/discussion/175645/p1-flip-multicore-module-carrier</link> <pubDate>Fri, 15 Dec 2023 03:04:16 +0000</pubDate> <category>Propeller 1</category> <dc:creator>David Betz</dc:creator> <guid isPermaLink="false">175645@/discussions</guid> <description><![CDATA[<p>I missed the web session where this was being discussed. Is there a description of it somewhere?</p>]]> </description> </item> <item> <title>Does anyone have signal generation code thats output matches the propscope readings?</title> <link>https://forums.parallax.com/discussion/126521/does-anyone-have-signal-generation-code-thats-output-matches-the-propscope-readings</link> <pubDate>Thu, 21 Oct 2010 14:06:30 +0000</pubDate> <category>Propeller 1</category> <dc:creator>turbosupra</dc:creator> <guid isPermaLink="false">126521@/discussions</guid> <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 />Currently I'm seeing ~5.4khz on my propscope when by math from the code it should be 6khz<br /><br />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.]]> </description> </item> <item> <title>Data from a sensor</title> <link>https://forums.parallax.com/discussion/175612/data-from-a-sensor</link> <pubDate>Mon, 27 Nov 2023 18:48:30 +0000</pubDate> <category>Propeller 1</category> <dc:creator>HughWN</dc:creator> <guid isPermaLink="false">175612@/discussions</guid> <description><![CDATA[<p>Hello,</p> <p>I think I may be being hard of thinking here, but...</p> <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> <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> <p>I've been round in circles so many times, I'm starting to get dizzy!</p> <p>Thanks,</p> <p>Hugh</p>]]> </description> </item> <item> <title>looking for an old debugging object</title> <link>https://forums.parallax.com/discussion/175614/looking-for-an-old-debugging-object</link> <pubDate>Tue, 28 Nov 2023 17:25:53 +0000</pubDate> <category>Propeller 1</category> <dc:creator>ti85</dc:creator> <guid isPermaLink="false">175614@/discussions</guid> <description><![CDATA[<p>Hey<br />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 />Thank you</p>]]> </description> </item> <item> <title>Trouble with XOJO baud rate</title> <link>https://forums.parallax.com/discussion/175611/trouble-with-xojo-baud-rate</link> <pubDate>Mon, 27 Nov 2023 14:53:30 +0000</pubDate> <category>Propeller 1</category> <dc:creator>velocityxlrg</dc:creator> <guid isPermaLink="false">175611@/discussions</guid> <description><![CDATA[<p>I often use code written in XOJO to get and display telemetry on a Laptop from my Propeller projects.<br />This has been occurring at 115200 baud using FullDuplexSerial. No problems.</p> <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> <p>This seems weird. I've check all the settings I can think of for both XOJO and the Propeller.</p> <p>Can someone think of a reason this might happen?</p>]]> </description> </item> <item> <title>Propforth v5.5 is available for download</title> <link>https://forums.parallax.com/discussion/146693/propforth-v5-5-is-available-for-download</link> <pubDate>Sun, 17 Mar 2013 09:38:27 +0000</pubDate> <category>Propeller 1</category> <dc:creator>prof_braino</dc:creator> <guid isPermaLink="false">146693@/discussions</guid> <description><![CDATA[Propforth v5.5 is available for download from Google code<br /><br /><a href="http://code.google.com/p/propforth/downloads/detail?name=PropForth-V5.5-20130317.zip" rel="nofollow">http://code.google.com/p/propforth/downloads/detail?name=PropForth-V5.5-20130317.zip</a><br /><br />Propforth 5.5 is now on GitHub<br /><br /><a href="https://github.com/prof-braino/PropForth5.5" rel="nofollow"><br />https://github.com/prof-braino/PropForth5.5</a><br /><br />Thanks to the team members and users that help with testing and documentation, this is the hardest part. Thanks for your patience with getting the release up.<br /><br />The kernel is unchanged since v5.0, only the packaging has been modified to be easier for new users to get started with the kerrnel. The build and test automation has been moved to a subdirectory, since it is only for advanced users; most folks won't use it until they are comfortable with using the kernel.<br /><br />The kernel itself is very stable, we don't even see interrmittent issues. That might mean we've been looking at it too long, hopefully new sets of eyes can discover and point out things we've missed.<br /><br />Focus is now shifting from developing the kernel to using the kerrnel. Now the REAL fun begins!<br /><br />Please give PropForth v5.5 a try. In particular, try to follow the docs included in teh download, and let us know what neds to change. Post comments and questions here or on the google code site, or PM me.]]> </description> </item> <item> <title>Working with 8 bit gray code and Prop 1</title> <link>https://forums.parallax.com/discussion/175598/working-with-8-bit-gray-code-and-prop-1</link> <pubDate>Sat, 18 Nov 2023 18:54:00 +0000</pubDate> <category>Propeller 1</category> <dc:creator>AGCB</dc:creator> <guid isPermaLink="false">175598@/discussions</guid> <description><![CDATA[<p>I have an 8-bit absolute encoder that I'd like to use with a wind direction indicator. Does Propeller 1 know about gray code <img src="https://forums.parallax.com/resources/emoji/wink.png" title=";)" alt=";)" height="20" /> . My previous try used a total of 8 magnet/switches to get 16 8-bit hex outputs. I'm not sure how to start with this or if I wasted my money. Help<br />Aaron</p>]]> </description> </item> <item> <title>Propberry</title> <link>https://forums.parallax.com/discussion/175597/propberry</link> <pubDate>Sat, 18 Nov 2023 17:26:17 +0000</pubDate> <category>Propeller 1</category> <dc:creator>HughWN</dc:creator> <guid isPermaLink="false">175597@/discussions</guid> <description><![CDATA[<p>Ages and ages ago there was a thread on combining a Prop 1 and a Raspberry Pi (related to <a rel="nofollow" href="https://zuzebox.wordpress.com/2012/07/31/propberry-propeller-raspberry-pi-combo/">this</a>). Has anyone managed to do something similar, i.e., sending serial data from the P1 to Pi and might be able to give some pointers?</p> <p>I'm happy on the Prop end and using FullDuplexSerial (presumably //ttyUSB0 on the Pi uses pins 31 and 30?)</p> <pre spellcheck="false" tabindex="0">ser[rPi].start(31, 30, 0, 9600)repeat ser[rPi].dec(10) ser[rPi].tx(13) ser[rPi].tx(10)</pre> <p>The other end using Python seems to be a nightmare! <img src="https://forums.parallax.com/resources/emoji/confused.png" title=":/" alt=":/" height="20" /></p>]]> </description> </item> <item> <title>OLED no longer displays</title> <link>https://forums.parallax.com/discussion/175595/oled-no-longer-displays</link> <pubDate>Thu, 16 Nov 2023 17:16:06 +0000</pubDate> <category>Propeller 1</category> <dc:creator>t_hitesman</dc:creator> <guid isPermaLink="false">175595@/discussions</guid> <description><![CDATA[<p>I have come across an issue where, after having wired up the 96x64 OLED to the board and loading an image from the SD card, the display no longer..... displays.</p> <p>I'll try and convey how / when this occurred.</p> <p>Following the tutorial:</p> <p><a href="https://learn.parallax.com/tutorials/language/blocklyprop/oled-display-blocklyprop/displaying-bitmaps-sd-card" rel="nofollow">https://learn.parallax.com/tutorials/language/blocklyprop/oled-display-blocklyprop/displaying-bitmaps-sd-card</a></p> <p>I began to jump between Blockly and SimpleIDE, having a very minimal background in C, I wanted to work in that and continue experimenting. While swapping images back and forth to the SD card ( removing and installing from my computer to the Prop board ) and occasionally turning off the board so as not to damage the OLED, the OLED stopped displaying any image. Where it would display any image I designated in the code, it seemed to suddenly stop doing so by around my 4th or 5th attempt to display a new image.</p> <p>Both Blockly and SimpleIDE would compile, transmit, and execute any code I would send in an attempt to display an image, but nothing would show. The COM port registers, everything checks out according to the software.</p> <p>Things I have considered, but unable to test for:</p> <ol><li>I probably broke it.</li><li>Operator error ( also broke it )</li><li>Maybe, accidentally wiped out some critical part of the chip coding from repetitive powering on and off?</li><li>I need a volt meter to check the pins.</li></ol><p>Probably not the best idea, jumping into the deep end, but after going over some search results online and poking around the forums, I hadn't been able to resolve the issue.</p> <p>Any thoughts, even a reference to a good book(s) on the matter, would be greatly appreciated.</p>]]> </description> </item> <item> <title>cognew Spin vs C</title> <link>https://forums.parallax.com/discussion/174526/cognew-spin-vs-c</link> <pubDate>Wed, 06 Apr 2022 17:03:37 +0000</pubDate> <category>Propeller 1</category> <dc:creator>KevinW</dc:creator> <guid isPermaLink="false">174526@/discussions</guid> <description><![CDATA[<p>I have been playing around with the P1 for a few years now, programming it exclusively in C. I decided to finally take a look at Spin, mostly on a whim. The first thing that stood out was that when you called cognew to start a process in a separate cog, you are able to have arguments. When programming in C, using SimpleIDE and the SimpleTools.h library, the cognew does not allow your functions to take any arguments.</p> <p>One of the first bits of example code in either language is a multicore version of the blinking light "Hello World" program. The C version has two separate blink functions with the delay times hard coded. The Spin version has the blink method take several arguments, including pin number, and the counter ticks for the delay. So the same method can be used for both cogs. There seems to be no way to do this in C or C++.</p> <p>I never understood why the C version of cognew does not allow your functions to take arguments. I thought it must be using function pointers, which allow you to pass arguments to the function being pointed to. Seeing the cognew in Spin makes me even more confused as to why the C version is that way.</p> <p>Is there something preventing the C cognew function from allowing the called function to take arguments?</p> <p>Thanks in advance for any information.</p>]]> </description> </item> <item> <title>Cannot upload to Prop - Com port problems</title> <link>https://forums.parallax.com/discussion/175583/cannot-upload-to-prop-com-port-problems</link> <pubDate>Thu, 09 Nov 2023 12:15:48 +0000</pubDate> <category>Propeller 1</category> <dc:creator>HughWN</dc:creator> <guid isPermaLink="false">175583@/discussions</guid> <description><![CDATA[<p>Hello,</p> <p>I have a Propeller Project board. When in the Prop Tool (2.7.0 Beta) I 'Identify Hardware', it finds the prop on COM2. However, if I try to compile and upload to the prop, the Prop Tool complains that "<em>no propeller was found on any serial port. Scanned COM 2. One serial port was excluded from the search</em>". If I go to 'Edit ports' via Edit -> Preferences, the only port showing active (i.e., bold) is COM 2. Setting the search to 'AUTO' or specifying COM 2 makes no difference. A different PC makes no difference. A different prop board makes no difference. v2.9.3 of the Prop Tool makes no difference. The drivers are up to date. Obsessionally, the message is "<em>More than ten serial ports were excluded from the search. Click Edit Ports for more information</em>". The Edit ports dialogue shows only COM 1 and COM 2, as does Windows Device Manager.</p> <p>Flexprop works perfectly.</p> <p>Any suggestions gratefully received.</p> <p>Thanks,<br />Hugh</p>]]> </description> </item> </channel></rss> If you would like to create a banner that links to this page (i.e. this validation result), do the following:
Download the "valid RSS" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
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:
