| Menu | JAQForum Ver 19.10.27 |
| Menu | JAQForum Ver 19.10.27 |
Forum Index : Microcontroller and PC projects : PicoMite V6.00.02 release candidates - all versions
  Page 49 of 52   |
||||||
Mick- latest projects - 2 hdmi break out arrived waiting for usb to ttl and micro usb sd card reader. dunno if retro ie soldered ribbon, no molex. let you know as may be useful... it will be like olimex on vero but working proper stan I also got a spare 2350 pre soldered from the pihut as did the sd card readers and hdmi breakout, they're good. fed up of soldering 40 pins...still got to do them for socket as never soldered pico board Edited 2025-06-03 02:36 by stanleyella |
||||||
the sd cards are 3V so that's why I'm solder wiring it all and sd and hdmi break out underneath the pico board if it's on headers. going for hdmi usb so usb to ttl for connect to pc. this has 5V and 333V out which will be used as power to pin 40 vbus, the swd card could be from the usb to ttl 3.3V or pico 3.3V see when usb to ttl arrive and test olimex again cos the 2 converters I got don't work |
||||||
Off topic? |
||||||
won't argue with you just a new hardware layout hdmi usb and open for suggestions like there's a dac chip that works and any ideas to try anything else welcome. nowt wrong with what I got so I'll blow this up for anyone... when built stan |
||||||
I haven't seen this mentioned in this thread, and did a search to see if it got brought up in another thread. Between 6.00.01 release and the 6.00.02 betas there seems to be a loss of functionality with MQTT. I say seems to be as there isn't any detail in the manual on how it is supposed to work (that I could find) so my usage has been derived from examples I've found. When a message is posted to a broker in a subscribed topic MM.MESSAGE$ holds the message and it can be displayed or used, as in .01, but MM.TOPIC$ does not seem to contain anything. I haven't done extensive testing to see if it returns a blank or null, but usage in a PRINT line produces no visible output. I see that a bit has changed in how these two are populated between .01 and now; and while I understand the code enough to see what it's supposed to be doing I don't understand it enough to identify why it might not be, My environment is as follows: MM.TOPIC$ works: Pico 2 W running: WebMite MMBasic RP2350A Edition V6.00.01 Options: OPTION FLASH SIZE 4194304 OPTION CPUSPEED 150000 'KHz OPTION WIFI [network appropriate data here] MM.TOPIC$ does not work: Pico 2 W running: WebMite MMBasic RP2350A Edition V6.00.02RC25 Options: OPTION FLASH SIZE 4194304 OPTION COLOURCODE ON OPTION CPUSPEED (KHz) 150000 OPTION WIFI [network appropriate data here] Code used to test: ' MQTT client test WEB MQTT CLOSE WEB MQTT CONNECT "test.mosquitto.org", 1884, "ro", "readonly", msgPrint WEB MQTT SUBSCRIBE "#", 0 Sub msgPrint Print DateTime$(now) Print "Topic : "; MM.TOPIC$ Print "Message: "; MM.MESSAGE$ End Sub Do Loop Until Inkey$ = "q" Sample Output from .02RC25: Connecting to 5.196.78.28 port 1884 03-06-2025 11:40:31 Topic : Message: 1748965230 03-06-2025 11:40:31 Topic : Message: oint_temperature":{"value":0,"status_code":"{null} @ def","units":""},"unoccupied_heating_setpoint_temperature":{" 03-06-2025 11:40:31 Topic : Message: {"command":0,"timestamp":1744046230,"node_id":8,"node_name":"ตู้ OPD 2","pla 03-06-2025 11:40:31 Topic : Message: tamp":"2025-05-31T11:01:30"} Sample Output from .01 Release: Connecting to 5.196.78.28 port 1884 03-06-2025 12:05:23 Topic : //16484256345/radio/rx_succe Message: 48122 03-06-2025 12:05:23 Topic : /116484256345/radio/rx_success Message: 48122 03-06-2025 12:05:23 Topic : /Acm_Moburapa/11C Message: {"slave":1,"temp":1,"co 03-06-2025 12:05:23 Topic : /MCP_Moburapa/11 Message: {"slave":1,"temp":1,"co Between each flash of firmware I've done a clear flash to make sure nothing lingered. MM.MESSAGE$ seems to be truncating, but I'm not sure if that's a limitation of the MQTT implementation or a buffer issue. Edited 2025-06-04 02:18 by jkdelauney |
||||||
Travelling at the moment, will look at it when I get home |
||||||
CHAIN might have a problem in RC25. Here are two programs. If this is the first time prog1 is run, it sets a to 4 and chains prog2. Prog2 prints a message, sets a to 1, and chains prog1. prog1: if a<>1 then a=4 chain "prog2" endif print "We're back!" prog2 print "Here's program 2" a=1 chain "prog1" When I run prog1, I get [LIBRARY] const true=-1 Error : true variable already declared I do have TRUE declared in my library but why is CHAIN trying to rerun the library commands? Even if I delete the library, CHAIN never prints the "Here's program 2" message. Edited 2025-06-05 12:56 by toml_12953 |
||||||
> save "Prog1.bas" > list "Prog1.bas" ' prog1 Print "Prog1.bas starting... a="a If a<>1 Then a=4 Print "a="a Chain "Prog2.bas" EndIf Print "We're back!" > list "Prog2.bas" Print "Here's program 2" a=1 Chain "Prog1.bas" > > RUN Prog1.bas starting... a= 0 a= 4 Prog1.bas starting... a= 4 a= 4 Prog1.bas starting... a= 4 a= 4 Prog1.bas starting... a= 4 a= 4 Prog1.bas starting... a= 4 a= 4 Prog1.bas starting... a= 4 a= 4 It would appear prog2 is called but does nothing except call prog1. Print and a=1 get skipped. Edit. No that isn't right. Prog1.bas restarts even if Prog2.bas no longer calls prog1 > list "Prog2.bas" ' prog2 Pause 500 Print "Here's program 2 a=";a if a <> 1 then a=1 ? "a is now =";a Pause 500 'Chain "Prog1.bas" > If I run Prog2 first a similar thing happens. Load "Prog2.bas" > RUN Here's program 2 a= 0 a is now = 1 Here's program 2 a= 1 a is now = 1 Here's program 2 a= 1 a is now = 1 Here's program 2 a= 1 a is now = 1 Here's program 2 a= 1 a is now = 1 Here's program 2 a= 1 a is now = 1 > Edited 2025-06-05 15:05 by phil99 Footnote added 2025-06-06 08:48 by phil99 Fixed in RC26 > RUN Prog1.bas starting... a= 0 a= 4 Here's program 2 a= 4 a is now = 1 Prog1.bas starting... a= 1 We're back! > |
||||||
Bug in chain - will include fix in the release |
||||||
Totally |
||||||
V6.00.02RC26 is available on https://geoffg.net/Downloads/picomite/PicoMite_Beta.zip Fixes bug in chain command Fixes bug in mm.topic$ (untested) |
||||||
Hi Peter, I have just converted an early HDMI Refrence design V1.2 to now drive a LCD display instead. PicoMite MMBasic USB RP2350A Edition V6.00.02RC25 OPTION SERIAL CONSOLE COM2,GP8,GP9 OPTION SYSTEM SPI GP18,GP19,GP16 OPTION SYSTEM I2C GP20,GP21 OPTION FLASH SIZE 4194304 OPTION COLOURCODE ON OPTION KEYBOARD UK, 0, 0, 170, 100 OPTION CPUSPEED (KHz) 396000 OPTION LCDPANEL CONSOLE ,,,, 50,NOSCROLL OPTION DISPLAY 26, 60 OPTION LCDPANEL ILI9488, LANDSCAPE,GP12,GP13,GP14,GP15 OPTION TOUCH GP17,GP28 OPTION SDCARD GP22 OPTION KEYBOARD REPEAT 170,100 OPTION AUDIO GP10,GP11', ON PWM CHANNEL 5 OPTION RTC AUTO ENABLE OPTION MODBUFF ENABLE 192 The intention is that I don't currently have a 2350 LCD layout and the 9488 will be replaced by a 7796 when it arrives. This is working great at the maximum overclock. ;-) So I've been stressing it. If I run a program that does not use framebuffers, so is writing directly to the LCD and I play a MP3 or WAV, all is good, however if I run the exact same program, with framebuffers and a Framebuffer Copy f,n with or without option b the music slows and distorts, it sounds like, as the Framebuffer copy is happening, a 100mS loop of sound repeats for the duration of the update, at the end of the screen update the sound goes back to normal, repeat. If I put a longish pause after the copy, the music plays fine for the duration of the pause, but at the next Framebuffer copy the same distortion. Hope you are having a good break, if it wasn't for us lot spoiling it! ;-( Any Ideas? Regards, Kevin. |
||||||
It does this because the audio isn't being buffered during the copy. On VGA and HDMI this happens quickly enough that it doesn't matter but SPI displays are slow so it runs out of audio and repeats the last buffer to avoid crashing. I'm not inclined to change this so late in the release cycle. |
||||||
In that case shouldn't the b (background) option be fine? but it triggers the same audio distortion. I've done a proof of concept (bodge). ' FRAMEBUFFER copy f,n,b Blit framebuffer f,n,0,0,0,0,480,80 Blit framebuffer f,n,0,80,0,80,480,80 Blit framebuffer f,n,0,160,0,160,480,80 Blit framebuffer f,n,0,240,0,240,480,80 Which sure enough cleans it up, at the expense of being slightly slower :-( Regards, Kevin. :-) |
||||||
Initial testing shows that mm.topic$ is producing the same results as in 6.00.01 Thanks :) |
||||||
No: The second processor puts a lock on the SPI channel to stop anything else using it so the audio queues on the lock. Remember, The SDcard and screen share the same SPI } else if(command==1){ uint8_t *s=(uint8_t *)multicore_fifo_pop_blocking(); mutex_enter_blocking(&frameBufferMutex); // lock the frame buffer copyframetoscreen(s,0,HRes-1,0,VRes-1,0); mutex_exit(&frameBufferMutex); } Edited 2025-06-06 00:55 by matherp |
||||||
Oh ok, didn't realise the PWM sound would get locked by the SPI? Ah yes the SD will be locked. Anyway, using 5 BLITS in a row, copying 64 lines each, cleans it up for both WAV and MP3 playback. Edited 2025-06-06 01:08 by Bleep |
||||||
|
||||||
just a typo in the order of strings in overlaid_functions[] in functions.c compared to the enum in configuration.h |
||||||
Hi Peter, As a feature request for the future, would it be possible to allow the Blit framebuffer...... to have a background option? |
||||||
| Page 49 of 52 |
||||||
 |
The Back Shed's forum code is written, and hosted, in Australia. |
