suggestion: put more work into SGC

[dudearent006]

Hi 4D systems! first post!
I've been playing with my uVGA (SGC) for a while, and I have to say, compared to the GFX version, it's much...ignored. I sort-of wish those gauges, meters and that keyboard was available as a command for the SGC version. for example, there's a button function, but it's not nearly as professional as the GFX chrome-style buttons.

It isn't well documented in some cases either. Somewhere, it lies about the font size and some functions wonât work at co-ordinates x=0 y=0, and instead need x=1 and y=1 for it to not act weirdly.

lastly, SD card functions are quite limited. directories/folders in FAT would be useful ,but I can understand how that might be hard to implement (but please do, the root folder on my projects is just a mess!) but functions like start reading from a certain point in a FAT file instead of from the beginning, and copying a FAT file to RAW at a certain sector (and vice-versa) could be seriously useful.

your GPU chips are really great, and I certainly will consider it in my future projects, but the documentation and some SGC functions could use some work in the near future. I hope you consider implementing/fixing this, but otherwise, it's a really nice chip!

P.S. does anyone have an eagle part for the Picasso chip? I can't find one anywhere, and I know from experience (well, sort-of) that I suck at making parts myself.

[ESPsupport]

I've been playing with my uVGA (SGC) for a while, and I have to say, compared to the GFX version, it's much...ignored. I sort-of wish those gauges, meters and that keyboard was available as a command for the SGC version. for example, there's a button function, but it's not nearly as professional as the GFX chrome-style buttons.
GFX and SGC have pretty similar graphics capabilities at the low level. Are you confusing the layer added by ViSi as part of GFX? You can always create objects in ViSi and use them in SGC, all the 'primitives' have equivalent commands. Using input objects in SGC will mean quite a bit more code on your controller though.

Are you looking for an SGC ViSi syle environment where the display does most of the grunt work to display graphics, processes touch inputs, receive commands from the host and inform the host of the user's input?

If so then watch this space

It isn't well documented in some cases either. Somewhere, it lies about the font size and some functions wonât work at co-ordinates x=0 y=0, and instead need x=1 and y=1 for it to not act weirdly.

Are you confusing 'Font multiplier' with 'Font number'? There are no known issues with SGC in this area, please give us some examples of problems so that we can fix them.

lastly, SD card functions are quite limited. directories/folders in FAT would be useful ,but I can understand how that might be hard to implement (but please do, the root folder on my projects is just a mess!) but functions like start reading from a certain point in a FAT file instead of from the beginning, and copying a FAT file to RAW at a certain sector (and vice-versa) could be seriously useful.

Adding directories/folders is not feasible for two reasons, every folder that is traversed requires an extra file be open which needs more memory that simply just not exist on most 'single chip' solutions. As soon as you have folder support you put more pressure on the performance of the FAT, which is why DOS/Windows etc cache the FAT, again something we cannot do. So even if we had a bit of memory, performance would be woeful.

The 8.3 filename system allows for around half a million trillion (short scale) filenames, you need to come up with a naming system that works for you within the 8.3 limitation.

[dudearent006]

well, font 0 that's supposed to be 5x7, seems to be 6x8 pixels. also, copying then pasting the full screen size to RAW (maximum provided resolution on uVGA, not a custom value) with starting point x0 y0, and the same for pasting, seems to paste weirdly. setting all co-ordinates to 1 fixes the problem. I think I once had a similar problem with text or something, I don't remember what that was exactly.

and yes, a sort of ViSi system would be useful, because the Serial commands are quite slow. possibly a script generator? I haven't looked into those script files yet. in the meantime, I'll see if it is possible to render ViSi style graphics trough serial.

The amount of filenames isn't the problem, it's the general neatness. my end product is meant to allow a user to remove the card and insert it into their PC, and add/remove/edit files that are used by the program. This gets quite messy

and yes, I sort-of expected it not to be capable of folders, but is the FAT-RAW file transfer possible? this would make reading files a user has made a lot faster and easer, since you can read from a certain point in FAT. and if not, can it at least be possible to read from a point in FAT files? Handshaking and just throwing away received serial data until you come to the point of the file you need is quite slow. If you can only implement one of these, I'd say the FAT-RAW transfer, since working with files in RAW is much easer and faster than in FAT (if you know what sector the file starts at, that is) and would be really useful.

Thanks for the quick reply and help so far!
EDIT: after downloading the software, I think most ViSi graphics are actually images (from what it looks like when it compiles, just a guess) but I have on idea where to find these files or how to use them in SGC. I would guess I need to display the 25% gauge picture when at 25% for example, but that would be a lot of entries in the graphics composer. so, how would I use these in SGC?

[ESPsupport]

After reading everything you've said I really think you should be coding in ViSi using GFX, otherwise you will be generating a lot of code to try and make SGC achieve things that it really isn't designed to.

EDIT: after downloading the software, I think most ViSi graphics are actually images (from what it looks like when it compiles, just a guess) but I have on idea where to find these files or how to use them in SGC. I would guess I need to display the 25% gauge picture when at 25% for example, but that would be a lot of entries in the graphics composer.

Correct, but ViSi superceeds GC and if you want to use ViSi created images in SGC you siply look inside the .dat file generated during the build process, it tells you the offset of the images withing the GCI and you then use them in SGC

[dudearent006]

well, one of the things I will later try to do is a sort of robot mapping controller. the CPU sends instructions to the robot via an Xbee radio and gets back information from it's sensors. the GPU will then display gauges on sensor data such as direction, battery, distance of objects in front of it etc. and also display a map of the explored area, done by calculations from the CPU. these maps are save-able to the SD card for retrieval on the PC for various purposes, obviously on FAT.

that's sort-of why I went for SGC. I want to be able to do math and processing on a dedicated device, and have the graphics be processed on another. looking at how long this GPU can take to do certain functions, it's probably best that way. if I were to make the interface in GFX, would it still be possible to have a large amount of data transfer to happen between the GPU and CPU? I think making a whole protocol for that is also a bit overkill as well.

Sorry if this is going a bit off-topic, as this is supposed to be for suggestions and not code help.

[ESPsupport]

if I were to make the interface in GFX, would it still be possible to have a large amount of data transfer to happen between the GPU and CPU? I think making a whole protocol for that is also a bit overkill as well.

It's more about getting complex work done on the display without overdoing the commands flying between the two. You should be able to find some samples in these forums that enable commands to be sent to the display whilst the display continues to monitor touch and whatnot. you can enlarge or condense them as required.

[dudearent006]

so, re-invent SGC mode in GFX but with my own graphics commands? I was just getting used to the SGC commands that took me a week, there goes my functions...

I'd need to re-invent about 30 or so commands in a programming language that I've never used, leaving behind code I've worked on for a week...to use a pretty gauge. I think I'd need to do a bit more research on both SGC and GFX before I make that decision! I don't even have a 4D programming cable (although it might work with a ICSP programmer and some jumper wires, I assume).

...so, I guess a FAT to RAW SGC command isn't possible?

[ESPsupport]

I'd need to re-invent about 30 or so commands in a programming language that I've never used, leaving behind code I've worked on for a week...to use a pretty gauge. I think I'd need to do a bit more research on both SGC and GFX before I make that decision! I don't even have a 4D programming cable (although it might work with a ICSP programmer and some jumper wires, I assume).

There is a 4D-SPE-V1_1.4dg in the PICASO\SPE samples folder that emulates much of the SGC protocol. Unfortunately its written in the original GFX language, so you will need to rename some of the functions and make changes etc. of of that will take time, but by the time you have finished you should be up and running in GFX. Maybe you can comment out the functions you don't need

...so, I guess a FAT to RAW SGC command isn't possible?

It's not going to get implemented, you are the only person who's ever asked for such a thing.

That was my main reason for suggesting you use GFX, because there you will be able to position FAT files to your hearts content.

Was just trying to help.

Maybe you need to stay with SGC and re-evaluate what you are trying to achieve and how to go about it?

[dudearent006]

There is a 4D-SPE-V1_1.4dg in the PICASO\SPE samples folder that emulates much of the SGC protocol. Unfortunately its written in the original GFX language, so you will need to rename some of the functions and make changes etc. of of that will take time, but by the time you have finished you should be up and running in GFX. Maybe you can comment out the functions you don't need

I would try this, but I have no clue what to fix! If this becomes really necessary, I'll try this. I don't own a programming cable, and I don't want to risk "bricking" the processor with an ICSP programmer, unless I can find at least a little evidence that this won't completely destroy my uVGA

It's not going to get implemented, you are the only person who's ever asked for such a thing.

oh well. I hope others will suggest this, then!

Was just trying to help.

you are helping! quite a lot, in fact. I know know a lot more about the differences between GFX and 4DGL, and how ViSi works.

Maybe you need to stay with SGC and re-evaluate what you are trying to achieve and how to go about it?

Right now, I'm planning a system that basically works like this:

loop 1:
start recieving FAT file with handshaking at 256
keep file in incoming serial buffer
write sector to RAW, all data in serial buffer
loop 2:
start recieving FAT file with handshaking at 256
empty serial buffer, request next packet
keep file in incoming serial buffer
write sector to RAW, all data in serial buffer
loop 3:
start recieving FAT file with handshaking at 256
empty serial buffer, request next packet
empty serial buffer, request next packet
keep file in incoming serial buffer
write sector to RAW, all data in serial buffer
etc.

untested, probably very slow, but it should work. simply show a little waiting screen or something while it copies, and the rest of the program can use fast RAW file acess.
now I'm trying to find out how to get these ViSi images working in SGC. I was hoping it generated some sort of graphics composer file. (it generated a strangely large .gci file (just under a gigabyte!), but renaming to .gcs won't work.) It does generate a .dat file containing what's probably the file offsets, but I'm not sure witch one is witch. I guess one is the offset, one is how large each file is (so I know how much to multiply by if I need, say, the 6th frame of a meter) and one is either the last adress or how many pictures there are (or both types exist) and a few more, but I don't know witch ones.

"Slider1" 0000 0000 78 60

"Knob1" FA00 0012 EC 9C

"Coolgauge1" 4000 0029 1E4 AD

can you tell me how to decode this? I just need to know what each value means and if this is the new/old image format, etc.
thanks for helping so far, though!

[ESPsupport]

You should order a programming cable ASAP, you will need it one day.

Why not write your file straight to RAW rather than FAT?

"Slider1" 0000 0000 78 60
"Knob1" FA00 0012 EC 9C

"Coolgauge1" 4000 0029 1E4 AD

The name is self explanatory, the next two parameters are the offset in the file, 'reversed' (i.e. Knob1 is at offset 0x0012FA00 in the file) the last 2 are the x and y initial positions.

You can use the Open GCI, Set GCI Entry, Display Frame to access those objects.

FAT files, by definition are always new format, you don't need to use the control command to turn that option on

You can put files directly into the RAW partition of your SD card using a scriptc script, look at C:\Users\Public\Documents\4D Labs\SCRIPTS\PC files READUSD.4DSCRIPT and WRITEUSD.4DSCRIPT

[dudearent006]

You should order a programming cable ASAP, you will need it one day.

I really would, but I live in South Africa, and the only SA distributor doesn't stock it, and shipping here is really expensive. I got the uVGA in one of my "large scale international orders" from SparkFun, in witch I buy parts I can't usually buy locally all at once to save shipping and import taxes.
I am, however, planning to make an order directly from 4D systems so I can buy a few of those Picasso chips (by the way, I no longer need the eagle part, I got around to making it myself) in witch I'll buy one of those cables. I think I'll need it to configure it with TFT screens anyway.

Why not write your file straight to RAW rather than FAT?

in the case of the robot mapping, one of the planned features is to view the created map on a PC Java program, and to edit it so that the robot avoids invisible obstacles (such as chair legs). My other ideas have similar concepts in mind.

You can use the Open GCI, Set GCI Entry, Display Frame to access those objects.

ooooh! right! I completely forgot about that GCI command, and wondered what it was really for. Silly me trying to extract and decode the file!

You can put files directly into the RAW partition of your SD card using a scriptc script, look at C:\Users\Public\Documents\4D Labs\SCRIPTS\PC files READUSD.4DSCRIPT and WRITEUSD.4DSCRIPT

I guess I need a 4D programming cable for that too? I regret not ordering one now...

[ESPsupport]