Adaptive projects
EmptyBit
Posts: 72
This forum offers a great knowledge base to the realities and limitations I have come up against using this platform for single board small footprint adaptive technology. I think I have exhausted most suggestions within the forum that I can find.
I have been working with the prop demo board for about a month. Not much experience for optimizing code, but I am resourceful in finding what I need and using it to the best of my abilities.
The first phase toward our goal was to create a simple large digit video display counter with voicing. This prop seemed to our benefit and within its capacity as confirmed by Parallax tech support and sales.
Well, I have the large character 4 digit counter display working on the small Parallax TV panel, with modifications and superficial optimization to the Graphics demo incrementing digits. Everything else was stripped out. It is lean to the point where removing anything else inhibits its function.
Separately, I have a 2g uSD card loaded with voiced number wav files. This section works as expected using Seluk's flexible player and the minimized fsrw for read only. Not sure how much more trimming I can do here besides using all assembler by default.
So far, so good? No, not so fast......these 2 sections will not run together given the 32k limit as I am currently just downloading to ram during development stages and debugging. I am still around 2k-4k longs over the limit. From what I have read here, this is the brick wall reality on single board prop projects using video and memory storage due to the drivers, stacks and buffers. Leaving very little room for actual program application area while using the basic infrastructure interfaces. Some solutions with SRAM or eeprom's end up compounded trying to resolve when adding more drivers for I2C routines to access external space.
What are my options? 2-3 prop proto boards with intercom and eeprom? The Cluso's Tri-blade prop's?
The original intent was this platforms ability to do VGA, but if it cannot handle a little 5x7 inch LCD TV, I must ask, what chance does it have for doing this with a 800x600 running graphics and mass storage?
I can use basic pin inputs to change color for contrast and voicing outputs. No keyboard or mouse drivers eating up valuable rare turf.
The final stages were to incorporate a small custom Braille display to tie the package together for reading digital gauges like Mitutoyo with digimatic outputs. Although this could be as another side project in itself using the objects mentioned above.
It is so close......
Sincerely appreciate any and all the guidance I can recruit!
I have been working with the prop demo board for about a month. Not much experience for optimizing code, but I am resourceful in finding what I need and using it to the best of my abilities.
The first phase toward our goal was to create a simple large digit video display counter with voicing. This prop seemed to our benefit and within its capacity as confirmed by Parallax tech support and sales.
Well, I have the large character 4 digit counter display working on the small Parallax TV panel, with modifications and superficial optimization to the Graphics demo incrementing digits. Everything else was stripped out. It is lean to the point where removing anything else inhibits its function.
Separately, I have a 2g uSD card loaded with voiced number wav files. This section works as expected using Seluk's flexible player and the minimized fsrw for read only. Not sure how much more trimming I can do here besides using all assembler by default.
So far, so good? No, not so fast......these 2 sections will not run together given the 32k limit as I am currently just downloading to ram during development stages and debugging. I am still around 2k-4k longs over the limit. From what I have read here, this is the brick wall reality on single board prop projects using video and memory storage due to the drivers, stacks and buffers. Leaving very little room for actual program application area while using the basic infrastructure interfaces. Some solutions with SRAM or eeprom's end up compounded trying to resolve when adding more drivers for I2C routines to access external space.
What are my options? 2-3 prop proto boards with intercom and eeprom? The Cluso's Tri-blade prop's?
The original intent was this platforms ability to do VGA, but if it cannot handle a little 5x7 inch LCD TV, I must ask, what chance does it have for doing this with a 800x600 running graphics and mass storage?
I can use basic pin inputs to change color for contrast and voicing outputs. No keyboard or mouse drivers eating up valuable rare turf.
The final stages were to incorporate a small custom Braille display to tie the package together for reading digital gauges like Mitutoyo with digimatic outputs. Although this could be as another side project in itself using the objects mentioned above.
It is so close......
Sincerely appreciate any and all the guidance I can recruit!
Comments
This is a VGA display using Baggers 256x240 tile driver (see the full color thread). For a bitmap 160x120 this would take 19200 bytes. By using tiles, you can reduce that to 4.3+3.7k = 8k. Probably less if you store vertical segments in one set of tiles and horizontal segments in another.
Hopefully that will save you enough memory to add in the extra code.
How big is the code?
Small world, I am also based in the Seattle area.
Here is a picture of the display. The thing about this is the graphics feature is so nice to be able to change the line thickness, fore and background colors. Even adding in digits is a snap, although smaller in width.
I have white/blue, black/white, white/black and black/yellow as options for highest contrast choices. The legally Blind have a rather limited perception of colors. This often leaves out reds, greens and ambers. Hence the avoidance of the fixed color large industrial LED displays currently on the market.
With that being said, I had considered reducing the custom character set to 0-9, - and period. Or going further with a simpler seven segment like display font. I have already stripped out the bits above the character 9. There is another 33 or so font definitions below 9 that I do not plan to use. Roughly 16 longs worth.
Although what is here is quite nice, it is ram hungry. Even if after storing what is left over to the eeprom to save ram will require another sacrifice driver to fetch it out of the prom. Not sure there is much of a win there. Why fear two steps forward, three steps back?
I am so impressed with all the talent I have read here over the years. Most of my previous work has been with stamps and the SX. I am not new, just another armature with admiration at a distance.
Thanks for your contribution to my conundrum.
$0
However, the ram is very difficult to handle. If you have a bitmap screen driver, you can overlay fonts, eg draw a white screen, read in a "A", draw it, read in a "B" and draw it.
However, using tile drivers means you either need to pre-process an entire screen, which limits the flexibility, or do tile driving construction from within code, which takes a lot of code. Either way, you may end up running out of ram.
I ran out of ram on the propeller very quickly. Hence the motivation to add external ram. Others have simplified the sram (CPLD), added lots more ram (32mb) and one can even think about external serial ram, which is a very simple 8 pin chip solution.
None of this is working 'out of the box' yet. There are several threads and there are going to be several solutions.
For me - I want it all! I want at least 20k of color hub ram devoted to video, and I want so much code space that I will never run out of memory. This isn't to trivialise it to lampooning Mr Gates for saying '640k will always be enough', because I know how fast I can code and I know how much compiled space that code takes, and for me, I can quite confidently state that I need about 100k to 400k of program space. 32k on the propeller is not enough, because once you load up 8 cogs, you really only have about 18k for coding space. I can do a lot more in 48k on CP/M on the propeller but it still is not quite enough.
I suspect that a solution to this will involve rolling up ones sleeves and getting one's hands dirty. By that, I mean you might have to heavily edit some existing obex code, or perhaps join in with some of the coding work with the full color video driver thread.
Right now, I'm deep inside Catalina, as this has an external memory mode that gives hundreds of kilobytes of code space as well as freeing up all the hub ram for video.
It is not simple. It involves programming in four languages at once (vb.net, spin, pasm and C). It involves diplomatically testing the (almost infinite) patience of those that have written code up to this point.
But - I am trying to build something the same as what you want - nice looking graphics as well as plenty of code space.
I would very much appreciate some help!
The current graphics code mod is quite simple. Doesn't need much. You have the idea per pic!
The flexible driver pretty much worked as is. I just changed a few pointers to my wav file names. I was preparing for integration of D1-D4 strings to file name with calls to the voice section or FSRW when I had to holler fer hep, after much fighting my folly trying to chain things together!
Point me in the right direction and I'll do the work. I have been reading( more like mental osmosis ) your contributions on pretty much every question I could query the forum search with.
$0
''*************************************** ''* Count Demo * ''* Author: Chip Gracey * ''* Modified by D.Case for LHB * ''* Copyright (c) 2005 Parallax, Inc. * ''* See end of file for terms of use. * ''*************************************** CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 _stack = ($6000 + 100) >> 2 'accomodate display memory and stack x_tiles = 16 y_tiles = 12 paramcount = 14 bitmap_base = $2000 display_base = $5000 lines = 5 thickness = 2 VAR long mousex, mousey long tv_status '0/1/2 = off/visible/invisible read-only long tv_enable '0/? = off/on write-only long tv_pins '%ppmmm = pins write-only long tv_mode '%ccinp = chroma,interlace,ntsc/pal,swap write-only long tv_screen 'pointer to screen (words) write-only long tv_colors 'pointer to colors (longs) write-only long tv_hc 'horizontal cells write-only long tv_vc 'vertical cells write-only long tv_hx 'horizontal cell expansion write-only long tv_vx 'vertical cell expansion write-only long tv_ho 'horizontal offset write-only long tv_vo 'vertical offset write-only long tv_broadcast 'broadcast frequency (Hz) write-only long tv_auralcog 'aural fm cog write-only word screen[x_tiles * y_tiles] long colors[64] OBJ 'ses : "voice" tv : "tv" gr : "graphics" mouse : "mouse" 'kb : "Keyboard" PUB start | i, dx, dy, numx, D1, D2, D3, D4 'ses.play_wav(1) longmove(@tv_status, @tvparams, paramcount) tv_screen := @screen tv_colors := @colors tv.start(@tv_status) 'init colors repeat i from 0 to 63 colors[i] := $00001010 * (i+4) & $F + $2B1c0C07 '2B_Foreground_0C_Background color '1C=Blue 07=White '8E=Yellow 02=Black '07=White 02=Black '02=Black 07=White 'init tile screen repeat dx from 0 to tv_hc - 1 repeat dy from 0 to tv_vc - 1 screen[dy * tv_hc + dx] := display_base >> 6 + dy + dx * tv_vc + ((dy & $3F) << 10) 'start and setup graphics gr.start gr.setup(16, 12, 128, 96, bitmap_base) 'start mouse mouse.start(24, 25) D1 := "0" D2 := "0" D3 := "0" D4 := "0" repeat 'clear bitmap gr.clear gr.textmode(10,16,6,5) gr.colorwidth(2,8) 'text color and width 'if right mouse button pressed, pause 'repeat while mouse.button(1) 'draw incrementing digit if D1 > "9" D1 := "0" D2++ gr.text(100,0,@D1) if D2 > "9" D2 := "0" D3++ gr.text(35,0,@D2) if D3 > "9" D3 := "0" D4++ gr.text(-30,0,@D3) gr.text(-95,0,@D4) 'copy bitmap to display gr.copy(display_base) repeat until mouse.button(0) 'increment counter that makes everything change D1++ repeat while mouse.button(0) if D4 == "9" and D3 == "9" and D2 == "9" and D1 > "9" D4 := "0" D3 := "0" D2 := "0" D1 := "0" DAT tvparams long 0 'status long 1 'enable long %001_0101 'pins long %0000 'mode long 0 'screen long 0 'colors long x_tiles 'hc long y_tiles 'vc long 10 'hx long 1 'vx long 0 'ho long 0 'vo long 0 'broadcast long 0 'auralcog {{To save on space, you could then compile with BST and eliminate unused methods.
I have a dream of having full color video for Catalina. Trouble is, the video code keeps getting better and better but I think it has stabilised now - two solutions, Kye's 160x120 driver, and Bagger's 256x240 tile driver.
Are you cool about programming in C?
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ tv : "tv_wtext" PUB Start tv.start(4 << 24 | 1 << 16 | $20 << 8 | 12) tv.str(string("1234")) repeatOf course, at this scale, the embedded ROM font has some jagged edges. But it's still a nice-looking font.-Phil
I have eliminated the double buffering and reduced the display area to 320 x 160 pixel. So the video memory goes down from 24kB to 10kB. Gives you 14kB more RAM for code.
''*************************************** ''* Count Demo * ''* Author: Chip Gracey * ''* Modified by D.Case for LHB * ''* Copyright (c) 2005 Parallax, Inc. * ''* See end of file for terms of use. * ''*************************************** CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 _stack = ($2800 + 100) >> 2 'accomodate display memory and stack x_tiles = 16 y_tiles = 10 paramcount = 14 bitmap_base = $5800 display_base = $5800 lines = 5 thickness = 2 VAR long mousex, mousey long tv_status '0/1/2 = off/visible/invisible read-only long tv_enable '0/? = off/on write-only long tv_pins '%ppmmm = pins write-only long tv_mode '%ccinp = chroma,interlace,ntsc/pal,swap write-only long tv_screen 'pointer to screen (words) write-only long tv_colors 'pointer to colors (longs) write-only long tv_hc 'horizontal cells write-only long tv_vc 'vertical cells write-only long tv_hx 'horizontal cell expansion write-only long tv_vx 'vertical cell expansion write-only long tv_ho 'horizontal offset write-only long tv_vo 'vertical offset write-only long tv_broadcast 'broadcast frequency (Hz) write-only long tv_auralcog 'aural fm cog write-only word screen[x_tiles * y_tiles] long colors[64] long old1, old2, old3, old4 OBJ 'ses : "voice" tv : "tv" gr : "graphics" mouse : "mouse" 'kb : "Keyboard" PUB start | i, dx, dy, numx, D1, D2, D3, D4 'ses.play_wav(1) longmove(@tv_status, @tvparams, paramcount) tv_screen := @screen tv_colors := @colors tv.start(@tv_status) 'init colors repeat i from 0 to 63 colors[i] := $00001010 * (i+4) & $F + $2B1c0C07 '2B_Foreground_0C_Background color '1C=Blue 07=White '8E=Yellow 02=Black '07=White 02=Black '02=Black 07=White 'init tile screen repeat dx from 0 to tv_hc - 1 repeat dy from 0 to tv_vc - 1 screen[dy * tv_hc + dx] := display_base >> 6 + dy + dx * tv_vc + ((dy & $3F) << 10) 'start and setup graphics gr.start gr.setup(16, 10, 128, 80, bitmap_base) 'start mouse mouse.start(24, 25) D1 := D2 := D3 := D4 := "0" longmove(@old1, @D1, 4) 'set font gr.textmode(10,16,6,5) repeat 'clear only changed area gr.colorwidth(0,8) 'text color and width dx := 70 if old2<>D2 dx += 65 if old3<>D3 dx += 65 if old3<>D3 dx += 65 gr.box(135-dx,-70, dx, 140) 'draw digits gr.colorwidth(2,8) 'text color and width gr.text(-95,0,@D4) gr.text(-30,0,@D3) gr.text(35,0,@D2) gr.text(100,0,@D1) longmove(@old1, @D1, 4) 'copy new digits to old repeat until mouse.button(0) 'increment counter that makes everything change D1++ repeat while mouse.button(0) if D4 == "9" and D3 == "9" and D2 == "9" and D1 > "9" D4 := "0" D3 := "0" D2 := "0" D1 := "0" if D1 > "9" D1 := "0" D2++ if D2 > "9" D2 := "0" D3++ if D3 > "9" D3 := "0" D4++ DAT tvparams long 0 'status long 1 'enable long %001_0101 'pins long %0000 'mode long 0 'screen long 0 'colors long x_tiles 'hc long y_tiles 'vc long 10 'hx long 1 'vx long 0 'ho long 0 'vo long 0 'broadcast long 0 'auralcogAndyThe nice thing about reading here is seeing how big projects evolve through different rev's far above my experience. I am in awe with code you guys reduce to bear minimum which accomplishes the same function or speed exponetials. That takes far more experience than I have career time left for.
So, in effect your challenge states the prop is up to the task, but am I?
Wish I could answer that in the affirmative without sweat on my brow and trembling knees. LOL!
I am motivated as long as I can squeek past little issues to some workable solution toward the present goal. I am spending someone else's money, so tossing aside this platform would not make me a hero. The input end and output ends seem so simple. The black hole in the middle so mysterious.
Let's see where it leads me.
$0
This does load the counter display and voice my "Hello" intro so far. I have been going through your changes and it is stunning such small changes in structure make such big differences. You made my counting coding look like shook up dice just thrown on the screen! Not to far off though eh? HA!
I will work with this here and see what I can do for file names with D1-D4 and append them to strings to create *.wav passed to the voice object based on each digits denomination. Can't imagine that will eat up what has been gained.
Phil,
I worked with your TV_wtext and could not reproduce what you had going. I'd like to see it as you had pictured, but my display only put up 4 small digits, 1/4" high character in the center. I changed cols=4 and rows=1 in TV_wtext without any change. I see you have the mode set in the Pub start, Hmmm. I must have missed another setting between the 3 objects. This sounds like another viable option if I try and stuff more functions here or in future projects.
Thanks for all the guidance in such a short time frame. What a blessing you all are! I'll sure sleep better tonight. I thought I was on the ropes.
$0
The one I posted is 64 color, but of course, if you only want 2 color, it will save a lot of memory.
This forum works 24/7 and for every piece of code you might post, someone will be able to shrink it somehow.
I gather you cut a few things out of the code to make it fit. Can you give us a bit more detail about what ideally you would like in the entire code. Maybe there are some other optimisations?
Most certainly. Ariba's optimising has given me new optimism!
The list of requirements is as follows.
Most basic production counter with voicing:
To include a video display and 3 push buttons for inputs. One for clearing the counter, one for voicing and one for contrast options that scroll through as listed in the code comments and preferably retain settings and counts(which means writing to the uSD). Using the smallest platform which can be utilized for accessibility for specific individuals adaptive needs as to screen size, loaded with the appropriate display driver and environmental variable attributes. The basic LCD TV proves the concept with VGA at a later date.
My next task is:
Getting the voicing object methods to read the D4-D1 counts from left to right. Ignoring leading zeros, but consider them inside the count. From this I will create a play list from variables D4-D1 using strings to append Dx.wav. Thereby sending a play list to the voice object sequentially.
For example: 1234 can say 1.wav, thousand.wav, 2.wav, hundred.wav, 30.wav, 4.wav. While 2009 will be just 2.wav, thousand.wav, 9.wav. I do not have an and.wav at this time. Or it can just state the numbers without denominations, not that big a deal.
Space and pins permitting, an optional com port for a custom Braille display ad on would be ultimate. I have two 80 cell braille displays that are not economical to repair. With high hopes, the Braille cells could be recycled into something down the road.
Something similar here. http://www.wseas.us/e-library/transactions/circuits/2010/89-677.pdf
Once the output ends are well in place, I have some old SX asm code I wrote 5 years ago to grab the digimatic output burst from Mitutoyo's measuring instruments. We already have voicing for these, but a large video display will be an enhancement to the package. Once this data is in the prop, it is only a matter of how it is used at the outputs. Displayed, voiced or brailled.
It is starting to look a lot like Christmas. The smell of fresh electronics in the air.
My second order just came in from Parallax. Woohoo! I hope to have the first counter installed very soon.
$0
I've zipped this in two files. The Voic'm file contains my gibberish spin someone might appreciate for what it is. NumWavs will contain the number wave files I have on the uSD. The left mouse button increments and the right button voices for now. Ignore the gr.text debugger lines. I've yet to learn viewport for debugging and its edit capabilities suck worse than P-tool besides that not having a direct debugger like the SX.
Be aware that the associated zipped files may be heavily edited for my particular application. For that I apologize to the author for butchering their original artwork. It’s what I thought I needed at the time.
So far the progress is getting it to voice up to 20. I know there are bugs after that, but that is where the progress ends to date.
There are far too many posters to thank for clues in just getting this far. Every little tidbit has helped in small ways as well as huge steps in the right direction.
I am a bit concerned about the play clarity. Could be my tracts, but dunno.
At least a bit of success for 2 thumbs and an untrained index finger coder. Certainly lots more fiddling to do.
Play around with it if you desire and let’s here some feedback as to the approach or better optimizing eyes. I have considered going back to the CASE section process as the Flexible wav player was originally set up, then put the wav file names in a data array.
$0
$0
If I am not mistaken, Andy's(ariba) optimising the code removed the buffering and repaints over the old character prior to placing the new character. It is pretty slick how that works so simple....provided one has the experience to achieve it.
If anything, this learning curve is filling some of the buffer between my ears. It remains to be seen if I can change my user name to $FFullbyte anytime in the near future.
$0
Many thanks to all that have helped along the way and for all the information here that put me on a better understanding of how to get things working.
$0
Many parts of your contributions as well as others here on the forum went into this project.
I hope the Blind are impressed with its looks.........errr, uhhh, useful purpose. Half of me thinks it is kind of clunky rugged and the other half says it is what it is to meet the need.
pedward,
As in the earlier part of the thread, Most basic production counter with voicing. It is adaptive hardware for those who are Blind in the manufacturing industries.
This can be used on any of our production cycling machines. A punch press, chop saw or blanking shear for example. These are intended to replace the old mechanical odometer style counters that are worthless for the visually impared.
Secondarily, this was an initial investment in using the prop platform for the expansion into other adaptive interface uses once the groundwork had proven something to build on. At least I am hoping the develpment learning curve gets exponentially shorter as we find more applications.
$0
Great project!
Alan.
Enjoy!
http://seattlelighthouse.org/what-we-do/manufacturing
More on youtube and around the web.
Besides the fact that I get to play with some really cool toys, uhhhh tools! Shhhhh!
$0
What they have lost in one sensory perception, they make up for in others. Feel, smell, hearing. Whatever powers of observation they have left will be used and or trained to the best of their ability.
Regardless, OH $%^*$ moments are going to happen.