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.
I have been playing with micromites for a little while and find the lack of direct handling of numeric Bytearray through serial UART frustrating.
I have applications where I need a reasonably fast byte array buffer data throughput, but with micromite Basic bytearrays have to be converted to strings and back again making the process slow and time consuming.
Sorry if this sounds like a rant, but in embedded controller world this is very important.
I hope that Geoff will give it some consideration.
Best Regards
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9588
Posted: 01:05am 05 Nov 2016
Copy link to clipboard
Print this post
Do you mean that cos you are using the serial port, you have to suck the data from the port buffer as a byte or string before you can put it into the array?
Perhaps matherp could write a Cfunction that would take the data from the serial port buffer, and move it directly into an array of your choice.
Not sure if this is even possible, or if I correctly understand what you are trying to do......
Welcome aboard anyway. Smoke makes things work. When the smoke gets out, it stops!
JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4034
Posted: 01:16am 05 Nov 2016
Copy link to clipboard
Print this post
I'm wondering what the problem is other than a wish to work a particular way. Why wouldn't an ordinary array be OK, for example? Or a string?
The CPUs are fast so speed should not be an issue. So what is?
John
kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671
Posted: 02:25am 05 Nov 2016
Copy link to clipboard
Print this post
I put my voice in support for that. This has been raised before as well. I think BYTE type variable would be a very welcome addition as it gives the needed flexibility to work effectively with hardware. Advancing with answers - anything other than BYTE (except BIT maybe, in future) is not needed because can be expressed with a certain number of bytes. I do miss the effectiveness of declaring a byte array in C and then working with it the way I find necessary. Geoff, please consider this addition. It does not take much resource and will be very useful to a large number of people who interact with hardware. Thanks http://rittle.org
--------------
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10202
Posted: 05:06am 05 Nov 2016
Copy link to clipboard
Print this post
Implementing a new BYTE datatype would be a huge job. I now know the internals of the Micromite firmware pretty well and my estimate to do it would be at least a month full time + it would likely introduce many obscure bugs in the same way that adding the INTEGER datatype did in the early betas of 4.6.
It is though very easy to simulate a byte array using an integer array. This of course could also be done in a CFunction
[code] DIM INTEGER A(40) ' == DIM BYTE a(320) DIM aADD=peek(varaddr a())
function getBYTE(i as integer) as integer 'get the value of byte i getBYTE=peek(byte aADD+i) end function
sub setBYTE(i as integer, j as integer) 'set byte i to value j poke Byte aADD+i,j end sub [/code]
kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671
Posted: 05:19am 05 Nov 2016
Copy link to clipboard
Print this post
Peter, I also happen to know the internals of the mite pretty well and I am a bit more optimistic about this. generally it comes down to approved strategy, otherwise can be implemented. Probably there will be some bugs in the beginning, but nothing too scary that can't be fixed in time.http://rittle.org
--------------
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209
Posted: 06:10am 05 Nov 2016
Copy link to clipboard
Print this post
If it is easy to do in BASIC, then it is easier to use the same concept in C. Seems like only a few lines of code (as shown in BASIC) when INTEGER datatype is used to store the BYTES.
Microblocks. Build with logic.
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10202
Posted: 06:42am 05 Nov 2016
Copy link to clipboard
Print this post
Yes, just every single command and operator to be modified to use BYTE (signed or unsigned by the way?) or to report BYTE is an invalid datatype, parsing to be modified, datatype conversions, SPI, I2C, Variable table, VAR SAVE , File handling, UART etc. etc.
Would also definitely blow the memory on the MX170 as an additional case would need to be added all over the firmware. e.g.
if(type & T_NBR) f = *(float *)v; if(type & T_INT) i64 = *(long long int *)v; if(type & T_STR) strcpy(s, (char *)v);
now add
if(type & T_BYTE) i8 = *(unsigned char *)v;
lots and lots of times
easy-peasy
kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671
Posted: 06:51am 05 Nov 2016
Copy link to clipboard
Print this post
Ah, I see now why you are scared :) Normally people who use bytes don't care about functions telling them about overflow, etc (I was talking about implementing *only* raw unsigned byte as everything else is descendant from it). So, no overflow checks, no sign, nothing, just plain good raw bytes available to do with them whatever you like.http://rittle.org
--------------
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10202
Posted: 07:24am 05 Nov 2016
Copy link to clipboard
Print this post
Yes that is easy enough but the OP wanted to use them with UART. I want them with I2C, SPI, Files and others will have other reqs. Eventually it either has to be done fully or not at all. It is very easy to use byte arrays in CFunctions - I do it all the time and then just pass them to/from Basic as integer arrays - 8 bytes per integer.
JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4034
Posted: 07:59am 05 Nov 2016
Copy link to clipboard
Print this post
Looking at the OP's post... how many bytes? (An estimate.)
Why not just use an ordinary array?
Or a string?
In either case you can write simple functions to make it cleaner, if you wish.
Unless you're talking about a vast number of bytes I can't see the issue so please explain what makes it so frustrating etc.
(The internals of adding BYTE are awkward, and will negatively affect everyone who doesn't need this feature, so compelling reasons look to be needed.)
JohnEdited by JohnS 2016-11-06
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209
Posted: 06:37pm 06 Nov 2016
Copy link to clipboard
Print this post
Why not base a byte array on a string datatype. MyBytes(100) could then be a synonym for MyString LENGTH 100
Instead of getting a single byte value out of a string width asc(mid$(MyString,1,1)). The easier syntax would be MyBytes(1).
If manipulation of single bytes is the main task of the program, the speed advantage of supporting that in firmware would be significant.
Only limit is the current maximum length of a string which will not allow you to dimension a bytearray bigger then 255.
Thanks to everyone that understand and support this concern.
As Microblocks has suggested. If a compromise of some sort could be implemented, where a numeric array that is equivalent to bytearray where individual elements are equivalent to 8 bit bytes (between 0-255), that can be transmitted and received directly through serial UART without the conversion to and from strings. I am not concerned about the limited length of the array, as I am transmitting it in packets protocol anyway, 255 bytes per packet should be OK. Multiple packets can be sent if need be.
I am not very good at programming in C and having to set up a separate Microchip C toolchain for C functions to mix with basic, would drive me to something like Arduino environment and program the whole damn thing in less difficult C that has plenty of support.
From memory other old basics have had PUT and GET to send and receive individual numbers or bytes through serial port.
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10202
Posted: 12:13am 07 Nov 2016
Copy link to clipboard
Print this post
a string is nothing more than a byte array that has the number of bytes in position 0
try the following:
dim s$ dim i% s$="ten" i%=peek(varaddr s$) 'get the physical memory address of the string s$ print "length of string s$ is : ",peek(byte i%) poke byte i%,6 'now make the string 6 bytes long poke byte i%+4,48 'add a '0' poke byte i%+5,49 'add a '1' poke byte i%+6,50 'add a '2' print s$
Now if you wrap that concept up as some simple functions/subroutines you can manipulate a string exactly like a byte array and have the advantage that all commands like print and print # work properly.
Without the length in byte 0 you have to have new versions of print that take an additional length parameter
Of course Basic could have used C type strings (0 terminated) but these also have a disadvantage for comms that you can't then transmit a zero byte without also reverting to an additional length parameter
JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4034
Posted: 01:14am 10 Nov 2016
Copy link to clipboard
Print this post
You can already very easily send and receive single bytes (or numbers). Nothing new needed.
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.
Print this post
