 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : PicoMite V7.00.00b8 and release candidates
  Page 2 of 2 |
|||||
| Author | Message | ||||
| mozzie Guru  Joined: 15/06/2020 Location: AustraliaPosts: 450 |
Hi Peter, Some further testing and good news, a definite improvement: M12 Radio + Charger now works flawlessly, connects and plays every time, no audio problems noticed during test. Tested Generic BT Receiver and TX/RX units and still working correctly, no audio problems noticed during test. Testing with car stereo units: Environment: PicoMiteRP2350BTHV7.00.00rc0 loaded on new Pico2W with no other options or connections. Using WIN XP laptop and TeraTerm for console. Laptop wireless OFF (no bluetooth) Play tone of various frequencies used for tests as no audio stored on PicoMite (no SD Card connected) Iphone SE2 in general area (top pocket of shirt), bluetooth and wifi both OFF, GSM network still active. WIFI access point with GSM connection in shed approx 8m distant from test location for VDO TR723BU and AXIS AX1300BT, AXIS AX1801BT tested in vehicle (Land Rover Perentie 6x6) no active wireless devices in immediate test area. (NON Electronic vehicle) PicoMiteBTH within 0.5-2M of receiver during test. Results: VDO TR723UB now scans and connects with BLUETOOTH CONNECT "TR723UB-BU","1234" AXIS AX1801BT scans and connects as before, no longer has a pause in audio every 3 seconds. AXIS AX1300BT scans and connects as before All 3 units have a random audio "stutter" of variable length and variable spacing: Length can be a single or series of "pulses" (stutter??) at approx 5-10hz Spacing can be from 5 to 120 seconds and appear random in nature. (Hence the mention of the environment above) I believe this is improved since previous test (less frequent) but still exists. Changes in distance of devices (0.5-2m) makes no distinguishable difference. Other thoughts: All 3 car stereo units have microphones and handsfree capability. The AX1801BT and TR723UB can display track names and data from the streaming device if present. Bluetooth status files from all 4 tests in ZIP file: PicoMite_BLUETOOTH.zip Regards, Lyle. |
||||
| flip Senior Member  Joined: 18/07/2016 Location: AustraliaPosts: 131 |
Hi Peter, HostPC -- HDMIUSB Master -- RP2350 Zero Slave Problem with slave comms is largely fixed, however it seems that echoed characters from the slave PM are dropping out occasionally e.g. I type 'files', but 'fils' is echoed. The command completes successfully on the Slave and all other characters sent by the slave are fully received by the Master Error is displayed: [USB DATA_SEQ 1 @282] at which time I guess it gives up.[USB DATA SEQ 2 @282] ... [USB DATA SEQ 5 @282] Each error correlates to the dropped Rx echo from slave Regards Phil PS...unplugging the keyboard fixes the problem. (but it means it won't run stand-alone) Edited 2026-10-12 01:21 by flip |
||||
| DNSGeek Newbie  Joined: 22/12/2025 Location: United StatesPosts: 6 |
I put together a cheat sheet for v7.0.00b8. It's been useful for me, so I thought others might like it. https://drive.google.com/open?id=1j0KZLVJTJ6Ffqpx0eqtIAYyVZg818PIp&usp=drive_fs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 11990 |
Phil Just to confirm, you did update the slave to RC0? The USB report deliberately stops after 5 but everything keeps going. Please let me know: The keyboard's make and VID/PID: PRINT HEX$(MM.INFO(USB VID 1)), HEX$(MM.INFO(USB PID 1)). Whether the keyboard has its own hub. Whether characters still drop if you type in the PC terminal with the keyboard still plugged in. That separates the keyboard's presence from its traffic. Whether characters are ever droped when not echoing the command, e.g. the response to the files command It appears that the the commands themselves reach the slave intact; only the echo is affected. A program that showed the typed characters locally, instead of trusting the echo, would avoid the visible symptom if it only occurs on the echoes |
||||
v.lenzer Senior Member Joined: 04/05/2024 Location: GermanyPosts: 157 |
Brilliant and fantastic! Many thanks! Best wishes! Joachim |
||||
| flip Senior Member Joined: 18/07/2016 Location: AustraliaPosts: 131 |
Thanks Peter. Yes it was upgraded to PicoMiteHDMI MMBasic USB RP2350B Edition V7.00.00RC0 Yes, only the error messages stop, everything functions as before (occasional random dropped chars) Plug in KB while program running (or being present when starting (RAM RUN 2) typed on the host computer [USB DATA_SEQ 1 @182] > PRINT HEX$(MM.INFO(USB VID 1)), HEX$(MM.INFO(USB PID 1)) 413C 2003 I don't think the keyboard has its own hub, it's a KB only: - DELL Model SK-8115 YES - ONLY dropped when typing from keyboard...using GFXterm everything is fine even when KB is plugged in I can confirm Chars never dropped when not echoing the command, it's only the typing echoed characters that are randomly dropped. (Except when pushing it as follows: for i=1 to 1000:? i;:Next i 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 2 4 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 5251256 78 699 9111711111121111111111101110111 1111111111111102 22222 22222222 224222222232222222222222222133 313333336333533 3743 35333393337333833933444444444446444 44244 454446444443444244 24945555955655555555554555555555 55 5555555 855656 66164662666 66 66666666666666166666666666607777 7771778 777777 746 747 748 749 750 751 752 753 754 755 756 757 758 75 9 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 79 0 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 82 1 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 85 2 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 88 3 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 91 4 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 94 5 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 97 6 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 ) Interesting corruption in Rx at exactly the same point (49) and ends at 746 This seems to be unrelated to the KB problem. I tried same but with loop counter to 100 or 200 instead of 1000 and it was fine. Not that big an issue as I know I am pushing buffers too hard But at some stage I may try dropping the baudrate and report back. Thanks for following up. Regards Phil Edited 2026-10-12 06:47 by flip |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6624 |
It might be a few weeks before I make a start. Jim VK7JH MMedit |
||||
| JanVolk Guru Joined: 28/01/2023 Location: NetherlandsPosts: 420 |
Peter, Thanks for the update and for resolving my issue. I tested `zmodem r "help7RC0"` on a standard PicoMite MMBasic RP2040 V7.00.00RC0 and PicoMite MMBasic RP2350A V7.00.00RC0. It works very well for me. (The file "helpNed7RC0" is 620k and has been 25% translated into Dutch.) With a PicoMiteHDMI MMBasic USB RP2350A Edition V7.00.00RC0, the external RX/TX connection now also works with zmodem, though not as fast as via USB. The maximum speed was 10k/s, which is workable; nothing has changed for xmodem. (53 sec) I also discovered that, on my end, strange characters occasionally appear between spaces in Windows Notepad; they are invisible in Notepad itself but show up as odd symbols in TeraTerm and on the HDMI console—though they can be fixed within Notepad. I also converted characters with diacritics into standard characters for TeraTerm, ensuring good readability across all screens. I haven't tested the VGAUSB RP2040 firmware yet, but I will let you know if any issues arise. Jan. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 11990 |
Try OPTION BAUDRATE 750000 and set the terminal program to the same |
||||
| JanVolk Guru Joined: 28/01/2023 Location: NetherlandsPosts: 420 |
Peter, Thanks for this; it's now four times faster. Jan. |
||||
| mozzie Guru Joined: 15/06/2020 Location: AustraliaPosts: 450 |
G'day Peter, Some time this arvo for further testing, this time PicoMiteHDMIBTHV7.00.00rc0 with MP3 / WAV files from SDCARD. Otherwise same environment etc as previous. There is also an SMA solar inverter that has pretty good Bluetooth range as it shows up in a few tests. Hopefully this isn't a factor in the results. I have re-read your previous post and only used BLUETOOTH STATUS at the start (twice) and end of the test. > option list PicoMiteHDMIBTH MMBasic USB RP2350B Edition V7.00.00RC0 OPTION SERIAL CONSOLE COM2,GP8,GP9 OPTION SYSTEM I2C GP20,GP21 OPTION FLASH SIZE 16777216 OPTION COLOURCODE ON OPTION MOUSE SENSITIVITY 1.0000 OPTION KEYBOARD US OPTION PICO OFF OPTION RESOLUTION 1024x600 @ 252000KHz OPTION DISPLAY 50, 128 OPTION HDMI PINS 1, 3, 5, 7 OPTION SDCARD GP33, GP30, GP31, GP28 OPTION AUDIO BLUETOOTH 10 OPTION RTC AUTO ENABLE OPTION COUNT GP34,GP35,GP36,GP37 OPTION PLATFORM PICO COMPUTER 3 OPTION PSRAM PIN GP47 > M12 Radio + Charger tested with music and no problems found during test of 4 x MP3 and 1 x WAV file. Also played a couple of tracks off USB media with no problems. Car Stereo units: All BLUETOOTH FORGET - BLUETOOTH SCAN - BLUETOOTH CONNECT Tested with 4 x MP3 + 1 x WAV file. AXIS AX1801BT unit tested and no pauses / gaps in audio noticed. VDO TR723UB and AXIS AX1300BT: Very short (~0.2sec) pause in audio, random but approx every 2-3 mins Bluetooth status files from all 4 tests in ZIP file: PicoMite_BLUETOOTH_005.zip I think the box of units for further testing may be in the "TWILIGHT ZONE" back corner of the shed, still unable to locate. Also a short test of the BT Serial link has drawn a blank. Tested so far: Q-STARZ BT-Q1000 Bluetooth GPS Receiver: > bluetooth scan Scanning... 00:80:25:A5:10:60 -82 dBm "SMA001d SN: 2130134432 SN213013" 00:0B:0D:89:B2:49 -62 dBm "iBT-GPS" 2 devices found > bluetooth connect "ibt-gps" Error : Connection failed (Bluetooth error 0x04) > bluetooth connect "ibt-gps" Error : Connection failed (Bluetooth error 0x66) > bluetooth connect "ibt-gps" Error : Connection failed (Bluetooth error 0x69) > bluetooth connect "ibt-gps" Error : Connection failed (Bluetooth error 0x69) > bluetooth scan Scanning... 00:80:25:A5:10:60 -84 dBm 00:0B:0D:89:B2:49 -58 dBm "iBT-GPS" 2 devices found > bluetooth connect "ibt-gps" Error : Connection failed (Bluetooth error 0x66) > bluetooth connect "ibt-gps" Error : Connection failed (Bluetooth error 0x69) > This unit may not be BTLE. Generic Bluetooth 4.0 module (HM-10) set as slave > bluetooth scan Scanning... B4:10:7B:3C:64:A1 -59 dBm BLE serial "HMSoft" 1 device found > bluetooth connect "HMSoft" Error : The device has no HM-10 service > It is possible the HM-10 is no longer running the default settings, can you advise UUID / CHAR (GATT?) settings the PicoMite would be looking for? More testing to follow as time allows and I remember where the other BT modules are hiding. Regards, Lyle. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 11990 |
BT serial supports both classic and btle. BTLE has been tested by pairing a BT build with a BTH build. Classic has been tested using a GPS receiver. I don't know about your receiver but mine has a switch between some sort of Apple mode and normal serial. Does the GPS have a code? you can add that at the end of the connect command BLUETOOTH CONNECT "fred","1234" I will look further at the HM-10 issue and get that working. I think I have one somewhere in my junk boxes. I think we have taken the audio saga about as far as we can. Clearly it works in many cases but there is something going on with some car radios that causes a brief pause very occasionally. Edited 2026-10-12 20:40 by matherp |
||||
| mozzie Guru Joined: 15/06/2020 Location: AustraliaPosts: 450 |
Hi Peter, Fair enough, whilst playing music it's hard to hear the pause most of the time. The M12 radio works very well. I will still test the rest of the units when I dig them out. Further testing of Bluetooth Serial / Bluetooth Audio with RN52 module: Set RN52 to CMD mode (GPIO9 +V) and: SD,04 (Set Discovery Mask to 04 A2DP) SK,04 (Set Connection Mask to 04 A2DP) R,1 (Reset) > bluetooth forget > bluetooth scan Scanning... 00:06:66:53:98:F5 -73 dBm "RN52-98F5" 1 device found > bluetooth connect "rn52-98f5","1234" Connected to 00:06:66:53:98:F5: SBC 44100 Hz, joint stereo, bitpool 53 > play volume 50,50 > play tone 119,120 > play stop > Plays audio  Set RN52 to CMD mode (GPIO9 +V) and: SD,02 (Set Discovery Mask to 02 SPP) SK,02 (Set Connection Mask to 02 SPP) R,1 (Reset) Set RN52 to DAT mode (GPIO9 0V) > bluetooth forget > bluetooth scan Scanning... 00:06:66:53:98:F5 -72 dBm "RN52-98F5" 1 device found > bluetooth connect "rn52-98f5" Connected to serial device 00:06:66:53:98:F5 (RFCOMM channel 1) as COM7 > open "com7:" as #1 > print #1,"Hello from PicoMite Bluetooth Serial" > ? input$(100,#1) Hello back to PicoMite Bluetooth Serial > ? input$(100,#1) The Quick Brown Fox jumps a lazy dog :) > Works bloody brilliant, this is going to be very useful  The RN52 can do A2DP and SPP at the same time but I think that might be stretching the PicoMite a bit far. Thanks again for making this possible. Regards, Lyle. Edited 2026-10-13 00:15 by mozzie |
||||
| JanVolk Guru Joined: 28/01/2023 Location: NetherlandsPosts: 420 |
Peter, The character " ` " is occasionally used in help.txt; on an HDMI or VGA display, this appears as the degree symbol instead of the " ' " character. This can be fixed by selecting the character and performing a global replace in an editor. The ohm symbol also displays incorrectly. Jan. |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 9181 |
That's what I would expect from the Picomite fonts. The problem is with help.txt, which may have been edited on another system using a different font. I'm pretty sure the default Picomite fonts don't have the ohm symbol. Like the UK Pound sign, it's not standard ASCII. The Picomite fonts are standard 7-bit ASCII apart from the degree symbol, which is of far more use usually. These occupy from &h00 to &h7E. &h7F to &hFF are not defined as ASCII characters. Mick Zilog Inside! nascom.info for Nascom & Gemini |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 11990 |
V7.00.00RC1 is now available at https://github.com/UKTailwind/PicoMite/releases/tag/PicoMite-V7.00.00RC1 This will become the release unless anything major is found. New since RC0: the PicoMitePC3 A version of the firmware built for the Pico Computer 3 alone, which puts everything the PC3's hardware can do in one image: the PicoMiteHDMIUSB's HDMI video (the full set of resolutions and modes, USB keyboards, mice and game controllers, the OV7670 camera), the PicoMiteHDMIWEB's WiFi (TCP, UDP, TLS, MQTT, NTP, TFTP, the web server) and the PicoMiteHDMIBTH's Bluetooth (keyboards, mice and game controllers, speakers and headphones, serial devices on COM7). It needs the PC3's PSRAM and is not for other boards. • Program memory is 256K, against 180K on the PicoMiteHDMIBTH and 156K on the PicoMiteHDMIWEB. The editor, LOAD, AUTOSAVE, LIBRARY and the XModem, YModem and ZModem program transfers take their buffers from the PSRAM, so a 250K program can be edited and saved. With the PSRAM disabled (OPTION PSRAM PIN DISABLE) only a program that fits in the internal memory can be loaded. • The PSRAM reserve is 2.5 MB rather than 2 MB, for the bigger context area and RAM program slots that the 256K program needs; MM.INFO(PSRAM SIZE) reads 5767168 on an 8 MB part. • WiFi and a Bluetooth speaker share one radio. While a speaker is playing, the radio gives the sound priority (otherwise it broke up as soon as WiFi was merely associated); a WiFi transfer slows to a crawl until the sound stops and recovers the moment it does. A speaker that is connected but silent costs WiFi nothing. • It is as fast as the PicoMiteHDMIBTH, within 2% on solar_eclipse and the game benchmarks, and 7 to 9% behind the PicoMiteHDMIWEB; the difference is the Bluetooth host's polling, which every Bluetooth host build pays. Running the heap in PSRAM costs about 1%. • No PWM, MCP48n2 or VS1053 audio (sound goes through the PC3's I2S DAC or a Bluetooth speaker), no YModem on the USB console (the console is a serial port on the PC3; XModem and ZModem work as on every build), and no PS/2 or I2C keyboard, the same as the PicoMiteHDMIBTH. • MM.DEVICE$ reads PicoMitePC3 RP2350B and the sign-on is PicoMitePC3. Loading it over another version resets the options and wipes A:; the PC3 configures itself again at the next boot (OPTION RESET PICO COMPUTER 3 applies the preset by hand). Changed since RC0: the Bluetooth host builds run faster with a speaker configured On the PicoMiteRP2350BTH, PicoMiteHDMIBTH and PicoMitePC3 the Bluetooth service ran on every statement once OPTION AUDIO BLUETOOTH was set, whether or not anything was playing, and cost about a third of the interpreter's time. It now runs with the radio poll, once a millisecond. Measured on the PicoMiteHDMIBTH with a speaker connected and silent, solar_eclipse went from 16.4 to 15.3 s (15.2 s with audio disabled); with the speaker playing, from 19.9 to 18.5 s, the rest being the SBC encoder. The builds also start no faster than they did; the saving is in running programs. Also since RC0: the TLS handshake's working memory comes from the PSRAM on the boards that have it (WebMiteRP2350 and PicoMiteHDMIWEB with a PSRAM, and the PicoMitePC3), leaving the internal heap to the program; and the firmware builds without warnings again (a nested comment in configuration.h, and the CSUB call table's section, which the assembler had objected to on every build since V6 - the table is found by CSUBs through vector-table slot 7 at run time, so its move changes nothing for them). Fixed since RC0 • A USB host build's serial adapter (COM3 to COM6) lost a character when a USB keyboard was typed on at the same time: files typed on the keyboard came back from the adapter as fils, with a DATA_SEQ in the USB log for each lost character. Each keyboard transaction was followed within about 10 microseconds by a receive timeout that the USB host charged to the adapter's bulk IN, and a failed transfer left that endpoint's data toggle one ahead of the device, so the device's next packet was taken for a repeat and thrown away. A failed transfer now gives the toggle back. This is TinyUSB's RP2040/RP2350 host driver; the fix is offered upstream as #4213. • A Bluetooth LE serial module with a 16-bit service UUID was never found. The HM-10's service is FFE0, and the device stores a 16-bit UUID as two bytes, which a search for its 128-bit form could not match. BLUETOOTH CONNECT now searches for a UUID with the Bluetooth base as 16 bits, and for any other as 128 bits as before. • The help files showed degree signs where code was quoted. The supplementary manuals mark code with a backquote, which MMBasic's fonts draw as a degree sign; help.txt and helpmin.txt now use an apostrophe. A minus sign written in typographic form had also become a space (so -1 read 1), and the box diagrams in the FRAME topics were blank: the minus is now -, and the boxes use the code page 437 line-drawing characters that MMBasic draws, so HELP FRAME BOX shows its grid. • The firmware builds without warnings. A nested comment in configuration.h warned on every file, and the CSUB call table, placed in the code section as data, had drawn one assembler warning per build since V6. The table is now in a section of its own; CSUBs find it through vector-table slot 7 at run time, so nothing changes for them. Edited 2026-10-13 21:47 by matherp |
||||
| JanVolk Guru Joined: 28/01/2023 Location: NetherlandsPosts: 420 |
In FM, no cursor is visible on the bottom line for functions that require data entry. Jan. |
||||
| Page 2 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2026 |
