 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 V6.00.02 release candidates - all versions
  Page 22 of 36   |
|||||
| Author | Message | ||||
| ville56 Senior Member  Joined: 08/06/2022 Location: AustriaPosts: 213 |
@Peter, is there a limit of 255 integer array elements for the I2C READ statement? I use the following form: i2c read i2c_addr, 0, num_bytes, eeprom_data() where num_bytes is 255 or 256 and the eeprom_data array has the corresponding size and is type integer. num_bytes=255 and less, all ok num_bytes=256 and up, firmware crashes and reboots Env: PicoMite MMBasic RP2350A Edition V6.00.02RC10 Gerald 73 de OE1HGA, Gerald |
||||
phil99 Guru  Joined: 11/02/2018 Location: AustraliaPosts: 2407 |
Deleted, brain fade. Edited 2025-04-08 09:42 by phil99 |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10008 |
Bug - will fix. Obviously no-one has ever tried to receive more than 255 before. |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4821 |
Yes, I did (not sure it No_One did as well ... No_One is the name of the guy who wrote the USB-PS2 conversion for mice and keyboard for pico originally). I thought it was a limitation from MMBasic (heritage from the MX170) that did not even have sufficient RAM to put all this data in an integer array. I wrote copy routines for 24LC32's that read 255 bytes, then 1 byte (the last) for each sector. Volhout Edited 2025-04-08 20:13 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| 58kk90 Regular Member  Joined: 14/06/2023 Location: United KingdomPosts: 59 |
So it looks like the bit command and function is not coming back, which is a massive msitake in my opinion, it was so useful, in that case would anyone still have a copy of the beta that DID have it and can possibly upload it for me somewhere, as I am going to stick with that version rather than lose it in favour of stuff that is no use at the moment to me. Tony |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4821 |
Hi 58kk90, This is RC8, and (just tested it) it still has the BIT command. For me (RP2040 VGA user) this was a stable version. The only issue I found was with font 7. But as I learned later, the above I2C issue with 256 bytes exists in rc8. 6.00.02rc8 But I think (when you ask Peter politely) he may bring the BIT command and function back, in addition to the FLAGS. Regards, Volhout Edited 2025-04-09 16:23 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7471 |
I'm sure it will all depend on the space and tokens available and whether BIT and FLAGS can get in the way of each other. Then it's a case of speed. FLAGS is faster as there is no variable lookup time. These are all things that need consideration - you can't just blindly put BIT back without some proper testing. Logic tests have been used for ages for testing serial data bytes as they come in (the serial routines on the Nascom did that in Z80 code). You have variable lookup delays there too so the question is, would BIT only be making the code appear simpler and not really give any speed advantage? Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4821 |
Hi Mick, a%=FLAGS(x) needs a lookup of 2 variables a%=BIT(b%,x) needs a lookup of 3 variables. Flags is best to managing flags. Flags may faster, but BIT is universal. You can use it at many variables. Also to decode/analyze data that is inside an integer. And if that is what you are doing, the loss of BIT may cause pain. Becaus the alternative { a%=(b% and 2^x)<>0) } is even slower. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4821 |
@Peter, Using RP2040 GEEK. It has an small OLED display, but since typically all communication goes through Teraterm, is there any way to prevent error messages going to the OLED display ? I tried OPTION LCDPANEL NOCONSOLE but - this option does not show in OPTION LIST (I have no idea if it is accepted) - still all error messages go to the LCD. I think this topic was brought up by Tom earlier (For the Game*Mite), but can't remember the outcome of the discussion. Volhout Edited 2025-04-09 17:28 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7471 |
But when you are testing serial data you are usually looking for byte codes (commands or addresses) not bit testing so a%=(data% AND &b00101000)>0 only requires 2 lookups. I can see BIT being useful for reading flags read from I2C modules, for example, but the read is already completed then (well, it should be!) and timing isn't usually as much of an issue. I guess it's horses for courses. :) I normally put bit routines in my Library. . Edited 2025-04-09 17:25 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4821 |
So there is need for it.  Volhout P.S. I can't use the library anymore. I have 1 flash slot reserved for the filemanager, many of the games use another flash slots (petscii) so whatever I put in there get's erased anyway. I did not think that when 5.07 was developed, I would be asking or more flash slots... At that time we still had 7 slots, and no A:/ drive and no MODBUF. Volhout . Edited 2025-04-09 17:34 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7471 |
Oh, there's a need for bit testing. :) But is it speed critical? When testing for commands and addresses you need to be quick so logic testing an entire byte or word in one operation is the best way. If you test more than a couple of bits it's slow. There are cases where you might, for example, test a received I2C bit in a loop but the time lost by testing using several variable lookups is nothing compared to the time taken to request and receive the bit into a buffer. (Didn't I say at the time that we shouldn't be reducing the flash slots? :) If a *simple* file manager can be sorted out and integrated into MMBasic then at least you get one back. Or fit the file manager into the Library.) . Edited 2025-04-09 17:44 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| circuit Senior Member Joined: 10/01/2016 Location: United KingdomPosts: 268 |
Would "on my knees and begging" be considered to be polite enough? As I emphasised in my last post; the BIT() command and function streamlines code for interfacing with power logic shift registers rather superbly, as well as setting PORT() interfaces. |
||||
electricat Senior Member Joined: 30/11/2020 Location: LithuaniaPosts: 288 |
I liked idea of Bit commands and functions too. Something I`we used in Mikroe`s "mikroBasic PRO for PIC" much. But FLAG command and function seems to me SUPER USEFULL too. Peter said once something like 'nobody wanted it, so I discarded' or something.. so my both sleepy cats would rise paws for BITs and FLAGs if asked to vote on this case  I see it, like well, problem can always be solved with any tool on hand. It`s only question of how fast/comfortable I could be done. I still ocassionally write DEC 1 instead of INC ,-1 while INC ,-1 is perfectly OKI do Bit manipulations shifting, ANDing, ORing and it`s perfectly OK, but Bit set, Bit reset etc. just seems so comfort  and speed is not always that important. And custom bit functions you still need to load/add etc. Takes spaceEdited 2025-04-09 18:22 by electricat My MMBasic 'sand box' |
||||
| phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2407 |
As a compromise would adding this feature to FLAG() make it usable for you ? Assuming it is possible. FLAG(all) = x% or FLAG(all) = 0 Then you can assemble your bits in FLAG(), send the value of MM.FLAGS out the door and use FLAG(all)=0 to clear it for recycling and start with the next batch. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7471 |
Or add the facility to set MM.FLAGS? MM.FLAGS = &h0FF7 for example. There's no need to change FLAG(n) at all then. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4821 |
I guess this suggestion boils down to copying the variable you want to test into the "FLAGS" variable, doing some bit manipulation, then copying it back to the variable. And (in doing this process) loosing FLAGS to do what it is intended for (keeping logic flags) since these are constantly overwritten by above mis-use of the FLAGS variable. I think that I summarize it well when I say, BIT is more appreciated than FLAGS, despite the good intention of Peter. Maybe time to do a small step back, and re-vive BIT, potentially at cost of loosing FLAGS. Volhout Edited 2025-04-09 18:56 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2137 |
welcome to the abyss... been here since 5.04.08 (but I'm ok with that)  Edited 2025-04-09 21:55 by CaptainBoing |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7471 |
:) (xkcd? If not it should be!) Anyone who is *depending* on a RC release is doing this wrong. RC (Release Candidate) is a beta that is more likely to be released without too many more changes, it's not a stable release yet and things may change. :) If you want a release that isn't going to break your program then use the newest full release, even if the future bells and whistles aren't in it... Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10008 |
V6.00.02RC11 is available on https://geoffg.net/Downloads/picomite/PicoMite_Beta.zip The Bit(ch) is back + > 255 i2c transfers should work - untested |
||||
| Page 22 of 36 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
