display a bitmatrix

Go To Last Post
34 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hello,

i have a in a atmega32 a bitmatrix from 300x300 bits (just 1 or 0), its a 2D array.

the 1's in the matrix makes a simple image.

i want this to make visible, on a display. don't really mather what for kind of display it is.

i preferred to see on the display black boxes (1) and white boxes (0), beccouse it make the images more visible.

what is the best or easiest to do this.

 

thanks in advance for the answers.


 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It takes 11,250 bytes to hold the 0/1 status of 300x300. How on earth do you plan to do that in a mega32 with just 2K SRAM?
.
Or do just plan to blit direct from flash? Even so 32K only probably has room for 2 pictures

Last Edited: Fri. Apr 19, 2019 - 04:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

but its have 32 Kbytes flash, ore is that not posible ?

Last Edited: Fri. Apr 19, 2019 - 05:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Flash is not writeable during runtime. You need to have enough sram for the data you want to be updating live, plus a fair bit of extra space for overhead.

 

There's compression techniques that might help, but not that much probably -- on one of the larger systems with 8KB of memory, if you got really sneaky you might be able to handle things if there were enough patterns or duplication in the bits, but even then it'd be hard.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

no compressing, i want it to keep it easiest as posible. 

i thought that i can write to the flash while the program is running ? 

but if it is not, then i'm gonna use a extern eeprom ore something like that.

 

but i stil heve the question how i gonna display ?

 

thanx for your help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Build an LED matrix? That would only take 300 x 300 = 90,000 LEDs!

 

Part of your problem is that 300 x 300 is not a standard display size. Actually, you can use virtually any pixel-accessible (e.g. "graphic") display, whether LED, OLED, LCD, ... The display technology really makes little difference. Mouser sells graphic displays with sizes of 320 x 240, 800 x 480, and 800 x 600. See:

 

https://www.mouser.com/Optoelect...

 

This list will at least give you an idea of what is available, even if you don't want to buy from them.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Fri. Apr 19, 2019 - 05:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

800x480 whil do the job, the image don't have to fill the whole screen.

but is it posible to connect the display directly to the avr ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Most of those displays have a display controller. These controllers are typically set up with either I2C (e.g. AVR TWI) or SPI interface. Provided the logic levels are compatible, you can connect these directly to the microcontroller. A sort of "interface code" or "interface language" is used; the codes let you address individual pixel locations or a byte-width set of pixels. You can also do things like erase, move a cursor, and such.

 

Some of the standard ones already have Arduino libraries for access. That makes it much easier to get started.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Fri. Apr 19, 2019 - 05:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A key question here is what kind of display technology are you talking about. There's a whole heap of difference between 300x300 LCD pixels, 300x300 OLED pixels, 300x300 eInk pixels or 300x300 LEDs. As Jim says that would be 90,000 LEDs. Even just wiring them up is a challenge but then providing the PSU/current to drive will be a monumental headache. Even if you break it down and use 8x8 tiles you'd be looking at 37 tiles in either dimension to deliver 296x296. You'd still be looking at 1396 such tiles (37x37). What you are talking about is fairly monumental engineering and not really the job for a mega32. You might get somewhere with 1284P as the 16K RAM could hold an 11.25K display buffer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

of course i'm gonna not use 90k leds :)

to supplement: i wand to display once in about 2-3 minuts a image. very very slow.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, the image duration does not matter much once you get below persistence-of-vision rates. What DOES matter is how long you can tolerate for refreshing the image. 

 

Lets suppose that you can transfer an entire block of 8 pixels as a byte. That means 90K/8 bytes per refresh, or 12K bytes. If you want to do that in 10ms (much slower becomes really obvious to the user, even better if 5ms), than that is about 1K/ms or 1Mbyte per second. That would be really hard with standard TWI/I2C. With SPI, thats 8Mbit/second, which is nearly impossible with an 8MHz MCU. Half that, for an SPI master, is usually possible. 

 

So, if you can allow a really slow refresh, say 1 second (observers may perceive that as "as slow as molassas"), then you could do it with TWI or SPI at 800Kbit/second.

 

You clearly have some work ahead of you!

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Fri. Apr 19, 2019 - 08:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok so not LEDs so I'll ask again what is the output device? If it's LCD/OLED/eInk then perhaps the panel has an intelligent local controller with its own display RAM?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Methinks the OP has no idea what the output device is. I think, instead, that trixio is trying to choose a device, probably with very limited knowledge about how such devices even work.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The adafruit tft libraries can show an image from flash. GIMP can write out an xbm file that contains (almost) the C code you need to put the image in flash.

 

Careful, an image takes LOTS of flash. I tend to stick to like 32x32 images.

 

I have drawn a full color image on a tft, but with an arm, not an avr. Even that did not have enough ram for a 320x240 16-bit image.

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is perfectly normal to hold monochrome bitmaps in Flash memory.

After all,  that is what Fonts are.

Colour images take a lot of memory.   So they tend to be smallish "icons" in Flash e.g. 32x32.   Or full size images held on SD card e.g. 320x240 24-bit colour .BMP or .JPG

 

Yes,  you can display images on TFT,  OLED,  LCD,  ... LED arrays.

You have the same problem with colour and size.   I have a 240x240 18-bit colour TFT in 1.3 inch diagonal.

 

240x240 made with discrete tri-colour LEDs is pretty big and involves a lot of wires and power supplies.   e.g. a single "tile" from an advertising display or "video wall" behind a pop group concert.

 

Scrolling Text message displays in the Doctor's Waiting Room are "low resolution" e.g. 1024 x 16 monochrome red LED array.   Some have tri-colour LEDs.

 

E-Paper displays are either monochrome or have a "few" grayscales.

 

Make a nice cup of tea.   Think about what you actually want to do.    Write it down on paper.

Then post your message here.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk said:

instead, that trixio is trying to choose a device, probably with very limited knowledge about how such devices even work.

yes thats true, more or less.

perhaps it wil go on a computer monitor whit help of a small program. 

 

i already said in the start post, that it doesn't matter what for kind of display it is. if i can see the total image i'm verry happy.

the refresh may take a second of even more.

for your imaging i explaine how the bitmatrix arises.

it starts whit a vertical scanner of 300 x IR led's whit 300 x a receiver.

a object moves trough the scanner and every 10 mm, all the vert. IR eyes (300x) looks where the object is. (light & dark)

the object can be max. 3000mm long.

so that wil give you a 300x300 matrix in bits.

that movement of the object is about 6 mtr/minute.

the proces is very slow, so the refresh can be tast as well.

 

but for me it is verry important, to see of the scan was OK.

 

Last Edited: Sat. Apr 20, 2019 - 05:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It should be very easy to create a faux 300x300 "display" on any desktop/laptop monitor. Python ought to be able to do it. Xojo (effectively object-oriented BASIC) can do it in a snap and free if you don't need to compile it into an executable (on Win/Mac/linux). I'd even take the few minutes to write it for you (well, more than a few minutes, but not much more).

 

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sat. Apr 20, 2019 - 05:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thanx,  i'm try to gonna find out how xojo works.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Contact me with a PM for pointers or help. I use it regularly. Inside the PM, I can give you my direct e-mail.

 

The FIRST thing you need to decide is how you are going to get the pixel data from your "sensor" to the display computer. USB as a COM port is probably simplest at the display end. But, tcp/ip (UDP, TCP, etc) also works.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sat. Apr 20, 2019 - 06:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i was just cheking or it is a good idee, to do it like this:

scanner -> avr -> raspberry PI whit xojo -> monitor

 

but i think its a bit of overkill

Last Edited: Sat. Apr 20, 2019 - 06:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Overkill?

 

It depends on whether you are attempting a "proof of concept" or a "prototype"? Proof of concept will show you whether or not the idea will work. Prototype will show how the idea might be practically constructed. RPi might be a great proof of concept way, but probably not useful as a prototype. Prototype will take a lot of effort, researching appropriate displays, display control methods, hardware design, power, and more. 

 

Its your choice. Your choice will (e.g. should) depend strongly on the time you have available to do it, the money and design resources you have, the degree of "finish" a prototype should have (e.g. should it look like a commercial product?). This is the call YOU have to make.

 

Side comment: It sounds like this might be an academic project. If it is, I have worked in a university and am familiar with what goes on in such projects.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sat. Apr 20, 2019 - 07:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

no it is not a academic project, it is indeed a proto type.

this "scanner" is a part of a bigger project. but to develop the program i need to see or the scan is OK.

whit the scan i do some more things, for example filtering.... when i see a 1 surrounded whit 8x a 0 it is a 0.

000      000

010  = 000

000     000

and some more things. so i want to see after every step or the bitmap is stil ok.

later on when everything is working i actually don't need that displaying no more.

well maybe to make the proto type a little bit look good.

 

 

to go one step ahead, if i not only want to display, but also want to make the user interface (button, control lights) whit xojo ore something else.

is that maybe also possible. 

 

Last Edited: Sat. Apr 20, 2019 - 07:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am working on a project for an old customer that wants full color graphics and a touchscreen.  Full color on a 320/240 screen is not a small file(well 100k)  But with touch buttons and slifders etc, I opted for one of these:

 

https://nextion.itead.cc/

 

They are not cheap, but they are also not out of reach price wise.  I can add buttons anywhere I want on the screen and I write a small program for teh screen that does the interpretaion.  The interface between the screen and the host processor(ARM, Xmega, AVR) is a USART which connects directly to the AVR's usart.  THE images and control program are stored on an SD card which loads a new update if needed at Power up.  You can create the command/replies any way you want and you simply put a handler function in your AVR code to talk to the screen.

 

THe GUI based programming software has very little documentation, and the support community is not so great, but I can sometimes get a decent answer.  I have learned how to program the screen so I do not have to ask much in the way of support.

 

Anyway the point is, if you want a simple way to have graphics and touch buttons take a look at the link I posted.

 

Right Side Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Something like an Rpi sounds like a good plan. Certainly a better choice than a 2K RAM AVR.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Physical buttons? Or, virtual buttons (that is, clicked objects on a display)?

 

Using xojo and some RPi examples, you certainly can to physical buttons. You might need to mix python and xojo but that is not a big deal. For virtual buttons, that is built into xojo.

 

xojo uses the native OS display features, like windows, buttons, text, graphical shapes, lines, and a lot more. On RPi, I think its gtk.

 

Further, you can develop a xojo app on a Mac/PC (of course, not implementing unique RPi things, like physical IO for buttons and such)  then easily move it to RPi. This should make the display graphics and anything involving USB and such very fast.

 

This conversation is really departing from AVR. Please send me a PM and we can continue off-list.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sat. Apr 20, 2019 - 08:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

trixo wrote:
of course i'm gonna not use 90k leds :)

One of the many, many options for an output would be 300 LED strips wit 300x WS2812 or OPO102 color LED's.

Such a display would not be particularly cheap, but it is doable.

 

trixo wrote:
to supplement: i wand to display once in about 2-3 minuts a image. very very slow.

Ah, yes. It would probably take quite some time to update all the LED's with a lowly AVR.

 

Some time ago I experimented a bit with an AVR and a ILI9341 or comparable TFT display.

The libraries I found (both Adafruit and Rinkydink) worked, but an AVR is a bit slow to get a responsive update with such amounts of data.

I also saw some demo's from small ARM processors, and they can refresh such displays at around 10Hz or more, which is enough for responsive menu's and such.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
Xojo (effectively object-oriented BASIC) can do it in a snap and free if you don't need to compile it into an executable (on Win/Mac/linux).

HOw else would you use it for a computer if it's not compiled?  I just looked at it, and $99.00 is not bad for the basic version for one OS.  But how would you use your creation if it is not compiled?

 

Right Side Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It just does not create a file-based executable! It runs in dubug mode without creating the full executable. Certainly, it compiles; it just does not do that last step of creating the executable. Not really interpreted, but you can set breakpoints, single step, view objects, and such. In the display, it appears exactly as if you were running an executable. This  is the "free" mode. I often use it that way, even if I have paid, just because I want to "knock" something out quickly, then throw it away.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sat. Apr 20, 2019 - 08:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Something like an Rpi sounds like a good plan. Certainly a better choice than a 2K RAM AVR.

 

most likely i wanna us the rpi only for the xojo to display the bit matrix. 

to store the 90k bits i still wanna use a atmega.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, but lets say I want to create a GUI for my desktop, and have the GUI interact with an AVR through a USB/TTL converter, or even through TCP and a Wiznet on the AVR...Can I do this with the $99.00 package?

 

RIght Side Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, all that and a bunch more. Image display, list boxes, buttons, windows, all the standard native grapic UI stuff.

 

Plus tcp/ip, serial, text manipulation (not just ASCII, but full Unicode). And access to native things like address books, calendars.

 

You can try it for free. That mode simply skips the creation of the file-based executable.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have drawn a full color image on a tft, but with an arm

So did you use your elbow?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another free and portable option is to write a simple web page with a bit of javascript. If you want to access serial ports etc, then use node-js.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:

I have drawn a full color image on a tft, but with an arm

So did you use your elbow?

 

I'll think of an appropriate response someday.

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead.