Equip your Genius
Welcome to the Parallax Discussion Forums, sign-up to participate.
Learn with BlocklyProp
PropellerIDE Development Thread
2018-07-16 - 01:12:41
Could it be that the 13 and 14 are being sent directly to the terminal and executed as CR and SO. That would account for 13 starting in column 0. Not sure what the Shift Out function would do.
In science there is no authority. There is only experiment.
Life is unpredictable. Eat dessert first.
2018-07-16 - 05:01:17
edited 2018-07-16 - 05:05:10
Haven't looked specifically trying to position the cursor to those row/column values though I know there were some initial cursor positioning problems like this in the code when I started playing around with it. It's been a while and I thought I'd fixed them but you may have found some more or missing parts to the intended fix. I'll try to take a look if/when I get a chance.
2018-07-16 - 05:32:35
edited 2018-07-16 - 06:00:44
Looking at some of the console.cpp code changes I'd posted in the zip file I see I do clear this "c" value to 0 for handling position Y, but not for position X. I'm wondering if it might need that added as well (in bold below). Don't have access to go build and test it properly now and think through all the cases etc but you might be able to confirm in your own setup if you can build PropellerIDE to see if that fixes things for you or there are still other issues there. I know it was kind of messy logic in that part of the code as it needed to keep prior character values lying around for determining row/column positions from the incoming byte stream. That was an original cause of some of the terminal issues I had found some time ago. Seems there may still be something lurking there.
// backspace, tab, new line, and line feed
// do require special implementations
// beep speaker is no longer a relevant operation
if (lastChar == 14 || lastChar == 2)
cursor = positionX(cursor, c);
// add this line below
c = 0;
else if (lastChar == 15 || lastChar2 == 2)
cursor = positionY(cursor, c);
c = 0;
UPDATE: Looking more at the code I think this should be a fix, and I can see why without this line it would behave the way you reported for two special cases of positioning to columns 13 and 14. The "c" character value needs to be "eaten" when consumed as a position offset, otherwise column offset 13 is handled as a carriage return for line wraps lower down in the code, and column offset 14 is copied into the "lastChar" value needed to detect another positioning command next time around so the code would try to take the next character it sees as another position X offset. Clearing "c" should stop that behaviour as it would cause "lastChar" to be reset to 0 in the next iteration.
2018-07-24 - 23:23:04
Sounds like you both had the right idea - this change worked for me.
WIP Spin drivers for various devices:
LSM9DS1 IMU (SPI) | Newhaven 4x20 OLED (I2C) | MLX90621 (I2C) | SHT3x (I2C) | SSD1306 OLED (I2C; P1-SPIN, P2-SPIN2) | TCS3x7x (I2C) | MAX31856 (SPI) | BMP280 (I2C) | TMC2130 (SPI) | nRF24L01+ (SPI) | MLX90614 (I2C) | MAX9744 (I2C) | DS28CM00 (I2C) | TSL2591 (I2C) | CC1101 (SPI) | SX1231 (SPI)