a1 attached


PicomiteV5.07.00a1.zip


Autosave now uses Ctrl-Z to terminate and has crunch capability
XModem fully implemented as per MM+ including file transfer
Various tidying

There is nothing I can do about the characteristics of the USB connection as this uses the standard Pico implementation which is based on TinyUSB. Apparently the version used is very out-of-date and this will be updated in the next release of the SDK.

In general the SDK is a bit disappointing. None of the functions have either timeouts or error returns both of which are normally standard. So in the case of, for example, erasing flash it either works or just locks up with no ability to detect.

Autosave is tested with teraterm with a 5mSec line delay and works perfectly. Terminal programs without a line delay capability (Putty) will not work reliably

  matherp said  

There is nothing I can do about the characteristics of the USB connection as this uses the standard Pico implementation which is based on TinyUSB. Apparently the version used is very out-of-date and this will be updated in the next release of the SDK.

It is definitely looking at handshaking.
The DLL I wrote to handle the comms in MMEdit was compiled as ASCII but now my compiler only does unicode. I have just worked out how to do the required conversions so I can update the DLL.

I was using the handshaking as reset triggers etc but I don't think anyone is using that feature now so I can get rid of it.

Jim

TassyJim,
The issue you have between the Pico and MMedit isn't unique to them. I sometimes  get a similar thing between the F4 and TeraTerm on Win XP. Pressing the reset button on the F4 fixes it. (till next time) I assumed it was something to do with the STM USB driver, but maybe there is some other marginal incompatibility interfering.

I love the FLASH commands, but FLASH BLANKCHECK is a little confusing, returning nothing for a blank flash area but "Error: Erase Failed" if there is something there. Not totally illogical when you think about it and probably only needs documenting.

FLASH CHAIN n seems to work very nicely! :)

bug?



It's still there in flash 5. It doesn't matter if the program is newly entered or retrieved from flash, an extra [Esc} in command mode seems to be the problem. Using Tera Term at the default baud rate.

(Looking forward to having OPTION COLOURCODE ON again. lol)
Edited 2021-05-30 19:10 by Mixtel90

This is a fantastic effort and a simply superb Alpha(s)

Thanks for quickly sorting the Xmodem and Ctrl-Z stuff... got me out of a hole really quickly.

I am (still) usng Win7 here and had a fight with the drivers initially but used Zadig to force USBSer onto the CDC device, then an embarrassingly long head-scratch to realize it is handshaking, but after that the alpha was running immediately. The FLASH save reset thing is a nuisance but as I will only be using it when I am serious about saving it won't be getting in the way of things too much.

Superb effort Peter - thanks. Gonna load Alpha 2 and play a bit more later today (wife has other plans for my time today     )

This little device is shaping up to be my new goto for small controllers. Seriously, I cant make my little 170 controllers for GBP3.60. I ordered 3 Picos from Pimoroni and I had them in my hand 20 hours later so very happy with their service.

  Volhout said  

Tried to enter a program with autosave. Not succesfull.
Use Putty (an Putty cannot generate an EOL delay, so it works imaginary 38400 baud speed).

same setup here (on Win 7) and I find this on the F4 as well, which is why I use XMODEM RECEIVE (with extra PuTTY). When you paste into the window with AUTOSAVE it is way faster than 38400. PuTTY has been my go-to for anything like this and I have used it professionally for decades because of its ability to establish TLS tubes really easily (not on serial tho . Alpha2 tweaks mean I don't have to change my terminal prog which is nice as I have all my sessions in one place

  TassyJim said  

It is as if there is flow control at play.

I had to turn on RTS/CTS flow control to get a console with PuTTY. Ashamed to admit it took me a few minutes to suss that one - so not used to it
Edited 2021-05-30 19:21 by CaptainBoing

Follow up...
Using 00a1 version.
I think it might be something to do with illegal commands.
LIBRARY LIST, which isn't supported, will also make the program disappear.

  Quote  

This little device is shaping up to be my new goto for small controllers.

Hold your horses, As I explore more I'm hitting more and more roadblocks. The Pico development environment is looking less and less like a proper professional set up compare to the likes of those for STM32 or PIC32.

Ah.... possibly related.
Create a sub:

Sub test
print "This is a test"
End sub
[F1] to save it

Now try to run it from command mode
>test
Error: Invalid character: 0
and the program disappears.

  matherp said  

Hold your horses, As I explore more I'm hitting more and more roadblocks. The Pico development environment is looking less and less like a proper professional set up compare to the likes of those for STM32 or PIC32.

heh... every silver lining has it's cloud

I know you are up to your eyebrows in stuff but just add this to your notebook. The XMODEM doesn't seem to come back - not even a timout. Could be me but I do the exact same procedure with other platforms with no issues. I thought maybe it was doing it's tea-dance with the reset-after-flash thing, but I had to power cycle it to get it back and then no prog.

early days. Still very good for first light

It's probably relatively early days for the Pico development tools too. The RP2040 is a pretty new microcontroller that's only been out for 4 months.

I'm pleasantly surprised at just how well these alpha versions of the firmware are running. :)

Alpha 0: Total of 82 commands
Alpha 1: Total of 81 commands: removed: COLOR, duplicates; added: Inc, Poke, Var, Xmodem

Alpha 0: Total of 92 functions and operators
Alpha 1: Total of 85 functions and operators
 Duplicates Removed: HEX(, OCT(, MM.Errno
 Removed: MM.FONTHEIGHT, MM.FONTWIDTH, MM.I2C, MM.Onewire

POKE but no PEEK? (Not that I've ever used those commands.)

~
Edited 2021-05-30 22:24 by lizby

  matherp said  

a1 attached

There is nothing I can do about the characteristics of the USB connection as this uses the standard Pico implementation which is based on TinyUSB. Apparently the version used is very out-of-date and this will be updated in the next release of the SDK.

hi peter,
   did you change something around how the flash is erased and written? with the alpha 1 version, erasing or writing flash seems to no longer causes a USB disconnect under linux mint. however, FLASH BLANKCHECK n does cause a crash, which it really shouldn't do as it doesn't even need to check the flash directly - it could just read from the CPU's memory space (which i assume is what FLASH LOAD n does).

might i suggest dumping FLASH BLANKCHECK n, and replace it with FLASH LIST which produces output similar to:



indicating that slots 3 and 6 are in use, while slots 0,1,2, 4,5, 7,8,9 are empty.

or it could recognize a comment in the first line of a program and use this as a title:



where slots 0,1, 4, 7,8,9 are empty, slots 2 and 3 are in use but contain no comment as their first line, and slots 5 and 6 contain programs with names (as a comment) in their first lines.


cheers,
rob   :-)

  Quote  

did you change something around how the flash is erased and written? with the alpha 1 version, erasing or writing flash seems to no longer causes a USB disconnect under linux mint.

Yes but it isn't reliable so may have to go back

  Quote  

might i suggest dumping FLASH BLANKCHECK n, and replace it with FLASH LIST which produces output similar to:

Good idea

Dear Peter,

I have checked the a1 release, and have following feedback

1/ (same as a0) a flash blankcheck n does not give a pass status, maybe it gives a fail status but I have not been able to verify that.

With release a0 I did a flash erase 1, that broke USB (reason for the fix)
With release a1 I did a flash erase 2

flash blankcheck 1
flash blankcheck 2
flash blankcheck 3
none of them gave a feedback, while 3 was not even erased.

2/ after flash erase 2 using software a1 the prompt did not return. Waited some 10 minutes, but nothing. But USB did not break, since the /dev/ttyACM0 was still visible.
Just the prompt did not return. I disconnected USB, and had to wait a while (tried without waiting) before /dev/ttyACM0 was gone. Normally when disconnecting this was immediate.

Another (general) remark. Have seen this on a0 but it is more obvious in a1: USB does not always mount after plugging in. Looks like you have to wait until all the voltage is gone from the pi pico. I think I will put an LED on the board as a bleeder. Honestly I cannot understand if this board was meant to be a maker board, that the pi foundation tried to save money to omit a power LED and a general purpose LED.
Starters need that immediately.

For your reference, I am using linux (ubuntu 18.04) with latest updates. Terminals: GFXterm64 and Putty. Above observations where noticed with both terminal programs.
Edited 2021-05-31 03:12 by Volhout

There is a general purpose LED on GP25, a port that is dedicated to just that (it's not on the connector). TBH I think the only hardware of note that's missing is a reset button to save on the plugging/unplugging. That can easily be externally wired.

Peculiarity. I tried to AUTOSAVE an 880-line, 26240-character program. It failed with "Sorry, internal error". I did an xmodem download with apparent success--it shows up with "FILES".

When I try LOAD "filename.bas", it locks up requiring unplugging and plugging back in. On one occasion, after several attempts, that did not result in getting a COM port--I had to reflash to get it.

XMODEM R "benchmark.bas" works and runs successfully.

Entering the editor with F4 for benchmark.bas and exiting and running with F2 also works.

Current status is that flash erase and program are too unreliable to be usable. Perhaps not surprising as the firmware is being pulled from flash. This is not influenced by whether the console is USB or UART. At the moment I'm at a dead end. The only current solution is to make the SDcard mandatory and give up on the flash completely.
Edited 2021-05-31 04:39 by matherp

It would be a shame if the flash could not eventually be made to work, but if functioning properly with SD card, I think it represents a very significant, easy-to-use, and inexpensive upgrade to the MM+.

It would indeed be a pity. Flash is one of the bits that I'm not seeing any problems with, apart from my previous note about an odd error message. I've no SD card connected so I'm using flash all the time for ERASE, SAVE and LOAD. ERASE was more reliable in the first version, I think. I've had a couple of lock-ups on return from ERASE on the second version, but the erase did complete correctly.


Edit: Famous last words! FLASH ERASE n has just locked up twice on the run, after the completion of the erase.
Edited 2021-05-31 06:04 by Mixtel90

Not a Pico ,

but has SD ....