Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 02:45 05 May 2024 Privacy Policy
Jump to

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 : New PicoMite firmware release V5.07.06

     Page 3 of 6    
Author Message
Tinine
Guru

Joined: 30/03/2016
Location: United Kingdom
Posts: 1646
Posted: 05:33pm 10 Jan 2023
Copy link to clipboard 
Print this post

Good ol' AE



Craig
 
twofingers
Guru

Joined: 02/06/2014
Location: Germany
Posts: 1133
Posted: 06:05pm 10 Jan 2023
Copy link to clipboard 
Print this post

I made an observation regarding the copy command.
Apparently, the copy command for files of the same name (overwrite) requires at least as much additional free space as its size. This is rarely a problem for small files, but more often with very large files..

E.g. if I have 15MB free disk space and there are 2 files (Afile + Bfile) with 5.5MB each saved, then I cannot save Bfile under the same name (overwrite). I get an error message (Error : No space left on device).

In my opinion, overwriting shouldn't take up extra disk space. My workaround is to delete an existing file before "overwriting" it.
There may be reasons for this behavior that I don't know.

Regards
Michael
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8592
Posted: 06:23pm 10 Jan 2023
Copy link to clipboard 
Print this post

I just call LittleFS with the standard parameters for writing a file. How it then deals with handling flash blocks (minimum 256 bytes for write, minimum 4096 bytes for erase) and when it frees up the blocks from the pre-existing file is up to its internals. You will have to live with your workaround.
 
twofingers
Guru

Joined: 02/06/2014
Location: Germany
Posts: 1133
Posted: 06:38pm 10 Jan 2023
Copy link to clipboard 
Print this post

@Peter
Thanks for responding!
Michael
 
led-bloon

Senior Member

Joined: 21/12/2014
Location: Australia
Posts: 203
Posted: 07:06pm 10 Jan 2023
Copy link to clipboard 
Print this post

@matherp - Peter
With your Waveshare RP2040plus 16MB flash, can you confirm
that PicoMiteVGA.uf2 has no problems with the lfs file system.
I am unable to save any file greater than 256 BYTES, and end
up with a "PANIC" and a reset!  Flash slots are ok.
This is ONLY with the VGA version, the standard PicoMite.uf2
is fine.
led
Miss you George
 
Pluto
Guru

Joined: 09/06/2017
Location: Finland
Posts: 330
Posted: 07:16pm 10 Jan 2023
Copy link to clipboard 
Print this post

https://www.aliexpress.com/item/1005003199099382.html?spm=a2g0o.order_list.order_list_main.108.30be1802zpx6es

Lower freight from this supplier. At least freight to Finland. 16MB Pico including freight= 3.66Euro.
 
homa

Senior Member

Joined: 05/11/2021
Location: Germany
Posts: 242
Posted: 07:41pm 10 Jan 2023
Copy link to clipboard 
Print this post

  Tinine said  Good ol' AE

Craig

Thx, have tried
Matthias
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8592
Posted: 07:49pm 10 Jan 2023
Copy link to clipboard 
Print this post

  Quote  With your Waveshare RP2040plus 16MB flash, can you confirm
that PicoMiteVGA.uf2 has no problems with the lfs file system.


Works perfectly for me. Just saved a 70K program and written a 20K text file with no issues
 
TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 5913
Posted: 08:10pm 10 Jan 2023
Copy link to clipboard 
Print this post

  led-bloon said  @matherp - Peter
With your Waveshare RP2040plus 16MB flash, can you confirm
that PicoMiteVGA.uf2 has no problems with the lfs file system.

led

If your uf2 file date is before 8/1/2023 18:34, download again.

Jim
VK7JH
MMedit   MMBasic Help
 
led-bloon

Senior Member

Joined: 21/12/2014
Location: Australia
Posts: 203
Posted: 01:28am 11 Jan 2023
Copy link to clipboard 
Print this post

Thanks Jim, I was 99.9% sure I had the latest, but decided to do a complete
download and start from scratch. Compiling on my cobweb-ridden Win10 laptop
PicoMiteVGA.uf2 has the problem with the lfs file system. PicoMite.uf2 does not.
In complete alignment with my RaspberryPi builds!

However, there are too many differences between my setup(s) and Peter's.
He is using gcc compiler 'arm-none-eabi V11.2.1' whereas I am using 10.2 on
my laptop and 10.3 on my Pi.
The other major difference is I am using the Sparkfun PRO Micro 16MB Flash
device. So heaps of differences.
Will relegate the device to the "too hard" bin.

Peter, I noticed that your CMakelists.txt file in the PicoMiteVGA folder
on github is out of date (no lfs.c & lfs_util.c files in the source list)
led
Miss you George
 
vegipete

Guru

Joined: 29/01/2013
Location: Canada
Posts: 1083
Posted: 04:03am 12 Jan 2023
Copy link to clipboard 
Print this post

I have a request for the PicoMiteVGA manual.

In my opinion, the chapter "Graphics Commands and Functions" really ought to start off with a description of modes. This would include a discussion of the two modes and their respective resolutions and colour possibilities. Currently, it takes a certain amount of wading through the manual to find these details, if you know to look for them. Newcomers might be left puzzled.

Also, perhaps the PRINT and PRINT@ commands could be included in this chapter, with some explanation of similarities and differences to the TEXT command, and why one might use one or the other.

Impressive work by all involved! Thank you for the effort you have put into this awesome platform.
Visit Vegipete's *Mite Library for cool programs.
 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3165
Posted: 08:48am 12 Jan 2023
Copy link to clipboard 
Print this post

Thanks Pete.  All good suggestions, I will try to fit them in.

Geoff
Geoff Graham - http://geoffg.net
 
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 3558
Posted: 06:05pm 12 Jan 2023
Copy link to clipboard 
Print this post

Peter,

There is one improvement that we could do for 50707. It is a bit of cleaning up that is not happening when you re-start a MMBasic program with PIO.

In case you write 4x to a fifo, the fifo is full.
When you end the program, even if you do a PIO CLEAR, and restart the program the pico stops (no USB UART comms anymore) at the next pio write.

'PIO clear
pio clear 1
dim d%=0

print "write"
 
for i=1 to 4
   pio write 1,0,1,d%
next i

print "ready"

end


You see I do not even start the PIO doing something. You can, but this is the simplest for to reproduce. When a FIFO is left full, and next run of MMBasic you do s simple write to FIFO, MMBasic is stuck.
Edited 2023-01-13 04:08 by Volhout
PicomiteVGA PETSCII ROBOTS
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8592
Posted: 06:41pm 12 Jan 2023
Copy link to clipboard 
Print this post

Will clear the FIFOs as requested.

On the interrupt issue. Please could you write me two simple test programs including the PIO code to test against

Assume the syntax is:

PIO INTERRUPT pio, sm [,rxnotemptyinterrupt] [,txnotfullinterrupt]

rxnotemptyinterrupt and txnotfullinterrupt are standard MMBasic interrupt subroutines

The use of the rxnotemptyinterrupt is obvious. It will indicate whenever data arrives in the FIFO and will re-trigger if, for example, two words are written into the FIFO and the interrupt only reads one.

The TX interrupt is not as obvious. I assume that it would trigger when the TX FIFO goes from full to not full allowing the Basic to know that it could send another value. It would still be up to the Basic code to not write data when the FIFO was full.

I would intend to enhance the FLEVEL function so that you can specify pio, sm and direction and it would then return the specific level of an individual FIFO rather than all the FIFO on one pio

For the avoidance of doubt RX and TX are from the perspective of MMBasic
 
Bleep
Guru

Joined: 09/01/2022
Location: United Kingdom
Posts: 414
Posted: 07:47pm 12 Jan 2023
Copy link to clipboard 
Print this post

  matherp said  
The TX interrupt is not as obvious. I assume that it would trigger when the TX FIFO goes from full to not full allowing the Basic to know that it could send another value. It would still be up to the Basic code to not write data when the FIFO was full.

For the avoidance of doubt RX and TX are from the perspective of MMBasic


Sorry to interject,
Quick question, to do with Tx FiFo, I've assumed it is blocking? so if I write out 9 values with say:-
PIO WRITE 1,0,9,f(0),f(1),f(2),f(3),f(4),f(5),f(6),f(7),f(8)
MMBasic will write out the first 3 values to the PIO FiFo, then stall until it can write another and another, until all done, then continue?

your statement "It would still be up to the Basic code to not write data when the FIFO was full" got me worried, or would this only be if I had activated the FiFo Tx interrupt you are discussing?
Thanks Kevin.
 
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 3558
Posted: 10:40pm 12 Jan 2023
Copy link to clipboard 
Print this post

@peter,
I'll work on it tomorrow. Is simple.

Volhout
PicomiteVGA PETSCII ROBOTS
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8592
Posted: 10:41pm 12 Jan 2023
Copy link to clipboard 
Print this post

PIO WRITE is always blocking so it would be bad programming practice to ever write to a PIO FIFO if it is full as this will stall all other processing. The interrupt just makes it easy to know there is space in the FIFO when there wasn't previously

For reference this is my proposed interrupt handling code. Volhout please comment if it makes sense for what you are looking for

   if(piointerrupt){  // have any PIO interrupts been set
#ifndef PICOMITEVGA
       for(int pio=0 ;pio<2;pio++){
#else
       for(int pio=1 ;pio<2;pio++){
#endif
           PIO pioinuse=(pio==0 ? pio0 :pio1);
           for(int sm=0;sm<4;sm++){
               int TXlevel=((pioinuse->flevel)>>(sm*4)) & 0xf;
               int RXlevel=((pioinuse->flevel)>>(sm*4+4)) & 0xf;
               if(RXlevel && pioRXinterrupts[sm][pio]){  //is there a character in the buffer and has an interrupt been set?
                   intaddr=pioRXinterrupts[sm][pio];
                   goto GotAnInterrupt;
               }
               if(TXlevel !=4 && pioTXlast[sm][pio]==4 && pioTXinterrupts[sm][pio]){  // was the buffer full last time and not now and is an interrupt set?
                   intaddr=pioTXinterrupts[sm][pio];
                   pioTXlast[sm][pio]=TXlevel;
                   goto GotAnInterrupt;
               }
               pioTXlast[sm][pio]=TXlevel;
           }
       }
   }

Edited 2023-01-13 08:43 by matherp
 
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 3558
Posted: 08:12am 13 Jan 2023
Copy link to clipboard 
Print this post

Hi Peter,

Looks like you are looking at levels in FLEVEL, not the flags in the FSTAT register.
That may work as well. Not sure.

I will work on the examples how I would use it.

But we need a way to independently start and stop the interrupt.
In SETPIN that happens by the SETPIN GPx, OFF designator. Is that envisioned here ?

How can we stop the RX interrupt and keep the TX untouched (keep runnign when interrupt running / keep stopped when stopped) ? Empty field for TX ?
Or split the command in independent TX interrutp and RX interrupt.

Regards,

Volhout
Edited 2023-01-13 18:15 by Volhout
PicomiteVGA PETSCII ROBOTS
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8592
Posted: 08:48am 13 Jan 2023
Copy link to clipboard 
Print this post

That's all OK

PIO INTERRUPT pio, sm [,RXinterrupt] [TXinterrupt]

Either can be omitted. Use 0 to disable the interrupt

My current thinking is that if you set up a RX interrupt you MUST read the FIFO in the interrupt routine. Otherwise it will continue to fire.
I could code it such that it interrupts on change of the FIFO count upwards but that runs into race conditions with the Basic code that I don't see how to handle
 
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 3558
Posted: 08:57am 13 Jan 2023
Copy link to clipboard 
Print this post

Hi Peter,

This is how I envision that the RX FIFO would work under interrupt.
' demo program to deomnstrate the use of the PIO interrupt
' the PIO is programmed to push 1 word into FIFO at every rising edge of the GP0 pin.
' the GP0 pin is controlled from MMBasic in this demo, but could also be driven from
' an external source.
 
'-------------------------------- PIO state machine -----------------------------------

'PIO clear
 pio clear 1
 
'the PIO program
'address    code    mnemonics         comment
'  0      2000      WAIT GP0=0
'  1      2080      WAIT GP0=1
'  2      8000      PUSH noblock
'  3      0000      JMP 0
 
'program pio1
 pio program line 1,0,&h2000
 pio program line 1,1,&h2080
 pio program line 1,2,&h8000
 PIO program line 1,3,&h0000
 
'write the configuration, running 100kHz (data in FIFO 10us after rising edge GP0)
 PIO init machine 1,0,1e5,0,,,0



'-------------------------------- MMBasic MAIN ---------------------------------------
 
'Halt the PIO from GP0 from MMBasic before it fills the FIFO out of control
 setpin gp0,dout
 pin(gp0)=0
 
'variables
 dim d%
 dim newdata%=0
 
'start the pio1 code, state machine 1.0 will be waiting for a rising edge on the GP0 pin
'then it will push 1 word into fifo. Then it will wait for the falling edge. The cycle repeats.
 PIO start 1,0
 
'interrupt format PIO INTERRUPT PIO,SM,RX_SUB,TX_SUB
 PIO interrupt 1,0,GetFifo,OFF
 
'freguently feed data into the fifo
 Settick 100,FeedFifo
 
'Main: check if data, when yes, then print
 do
   if newdata%=1 then
     print d%
     newdata%=0
   end if
 loop



'----------------------------------- SUBS ---------------------------------------
 
'in this sub get get 1 word from the Fifo. We can expand that to read data until
'the fifo is empty by repeated read and check of the fifo empty flag.
SUB GetFifo
 PIO READ 1,0,1,d%
 newdata%=1
end sub
 
'in this sub we toggle the GP0 pin to force the PIO to put data in the FIFO
sub FeedFifo
 pin(gp0)=1:pause 1:pin(gp0)=0:pause 1
end sub
 
 
 


Working on a similar demon program for TX. If you think I am going the wrong way then please tell me.
Edited 2023-01-13 19:01 by Volhout
PicomiteVGA PETSCII ROBOTS
 
     Page 3 of 6    
Print this page
© JAQ Software 2024