I am new to C; I have an image file translated by means of online tools into a .h and .c file. The C file contains an array of 1024 16 bit hexadecimal numbers, used to denote on/off of bits. I want to read this file and draw the image onscreen using DMA...but I'm very much at a loss as to how to do this. Can anybody out there help? Does anyone even know what I'm talking about?
To draw an image onscreen, use DMA[3]. This is channel 3 of DMA for images.
This is how you set up DMA in a .h file:
http://nocash.emubase.de/gbatek.htm#gbadmatransfers
And then to draw an image using DMA:
#######include image.h
DMA[3].src = (specify your image source here, where you're drawing from)
DMA[3].dst = (where you're drawing pixels to)
In your scenario, I think you indicate the name of the file in your source.
Keep in mind you're using POINTERS to images for src and dst.
DMA[3].cnt = (how many times you want to do it) | flag1 | flag2...
Here are some flags:
DMA_SOURCE_FIXED means you draw from the same pixel over and over again. If this is what you want, then turn this bit on in cnt.
DMA_DESTINATION_FIXED applies that you're drawing TO the same pixel over and over again. If this is what you want, then turn on this bit in cnt.
Otherwise, DMA_SOURCE_INCREMENT and DMA_DESTINATION_INCREMENT are on by default (if not, you can turn them on in cnt anyway).
This is what I used for VBA, so I'm sorry if this does not answer your question (I'm kind of inexperienced with C as well...).
#Michael Yes, I mean the Visual Boy Advance
Related
I'm having some issues getting a 16-bit (ARGB, 1-bit alpha, 5-bit colour channel) bitmap image which I converted using GRIT to display.
I have the following image, smpte_colour_bars.png. I converted it with GRIT using the following command line: grit smpte_colour_bars.png -gb -gB16 -fts -osmpte_colour_bars which gives me an *.s file for assembling into an object and a *.h header file for including in my project so I can reference the data.
However, when I use it in my project's code, all I get is a black screen: here.
I've looked through the relevant examples & documentation and I cannot track down the issue. Using DeSmuME's memory view, I can see that the data is being correctly written to memory & the tile view reflects that.
I have tested my code on two different emulators and real hardware and the problem is the same across all of them. Any insight into what might be going wrong would be much appreciated :)
It was a simple fix in the end after working out what was wrong. It turns out you must specify -gT! to explicitly disable transparency in the resulting bitmap otherwise the background is essentially see-through.
I'm trying to implement Asian symbols with my max7219 and using the 8x8 led displays.
I've had a look online and I've found libraries for the max7219 but it is only in ASCII. I was wondering if there was an easy way of implementing using a UNICODE library - assuming there is one.
I'd like to easily copy and paste say " な " this character into my code and print it onto the LED displays. So far, all attempts have not been working. My other option is to use binary/hex to manually draw up the symbols but I would really prefer to make it easy for the user to copy and paste any character and it prints onto the LEDs. Or will I have to create my own Arduino Library?
Any help is greatly appreciated!
Many thanks.
The problem with Unicode is that it's just so damn big (the first kana is U+3041), and most Arduinos have not nearly enough flash to store all the characters required.
My recommendation is to use an 8-bit encoding that maps to all the characters you need. I suggest starting with the character set used by the HD44780UA00 and replacing the characters where they make sense. Since some other libraries already use this set it won't be a huge leap to use them with your display.
You can't copy and paste a CHARACTER in a 8x8 matrix.
You have to find an 8x8 matrix of your font (katakana, kanji, etc.), and build an array that contains all the characters in a bit-by-bit format.
To all who have commented that MAX7219 is a 7-segment display, I want to say that MAX7219 is an IC which contains a buffer of 8x8 bit. You can use it to drive an 8x8 LED matrix, or an 8-in-line 7-segments (plus a decimal point) display, or anything else.
I have to calculate the flight path of a projectile and draw the result in a bitmap file. So far I'm pretty clueless how to do that.
Would it be a good idea to safe the values of the flight path in a struct and transfer it to the bitmap file?
Do you have any other suggestions how it could be done in a better way?
The simplest way to produce an image file without much hassle with only standard C library tools is most likely writing a bmp file. For start, check the Wikipedia article on this file format, it gives a quite complete description of it.
If you don't want to go too deep in that, save for example a 640x480 or so empty 24 bit ("truecolor") .bmp image, and rip out it's header for your use. Depending on the program you use to save your image, you might end up with varying header size, however since the data is not compressed, it is fairly easy isolate the header. For a 640x480 image the data will be exactly 921600 bytes long, anything preceding it is the header.
From here the colors are (usually) in RGB order, bottom to top row, left to right. Experimenting a little should give you the proper results.
If you only have the standard C libraries to work with, it is unlikely there is anything much simpler to implement. Of course this case you will have to write a pixel matrix (so no much assistance for solving the actual problem you want to image), but that's true for any image format (maybe except if you rather aim for creating an SVG for a twist, it is neither too hard, just XML).
I'm trying to write a JPEG/JFIF encoder and decoder from scratch using C. I experimented writing a sample JPEG file, but it seems that I cannot open it using MS paint, Firefox. But I can decode it using JPEGsnoop ( http://www.impulseadventure.com/photo/jpeg-snoop.html?ver=1.5.2) and http://nothings.org/stb_image.c . I think the sample JPEG file complies the JPEG/JFIF standard, I don't know why applications like MS paint and Firefox cannot open it.
Here is how the sample JPEG looks like:
SOI
APP0 segment
DQT segment (contains two quantization tables)
COM segment
SOF0 segment
DHT segment (contains four Huffman tables)
SOS segment
huffman encoded data
EOI
The sample JPEG file has three component Y Cb Cr. No subsampling for Cb Cr component.
The two quantization tables are all filled with ones.
The Four huffman tables in DHT segment are all identical, it looks like this
[0 0 0 0 0 0 0 255 0 0 0 0 0 0 0 0]
[0,1,2, ... , 254]
That means all the codes are 8bits, so huffman encoding does not really compress data.
The huffman encoded data look like this:
[0x0000(DC) 0x0000(AC)](Y)
[0x0000(DC) 0x0000(AC)](Cb)
[0x0000(DC) 0x0000(AC)](Cr) for all (i, j) MCUs except (10, 10)
the data in (10, 10) MCU:
[0x0008(DC) 0x0000(DC), 0x0000(AC)](Y)
[0x0000(DC) 0x0000(AC)](Cb)
[0x0000(DC) 0x0000(AC)](Cr)
Can anyone tell me what is wrong with this sample JPEG file? thanks.
Here is a link to the sample JPEG file (ha.jpg) http://www.guoxiaoyong.net/ha.jpg
I had a similar problem years ago with some PNG code (though I didn't write it from scratch). It turns out my code was more standards compliant than the libraries by Windows, some browsers, etc. They did fine on typical cases, but choked on unusual and contrived images, even if they were completely in line with the standard. A common way to trip them up was to use an odd pixel width for the image. Almost half of my test suite was not viewable with Windows. (This was many versions ago, like Windows 95. The Windows codecs have improved substantially.)
I ended up building the open source PNG library and using it as my reference implementation. As long as the images that my code produced could be parsed by the reference implementation and vice versa, I called it good. I also checked that my code could display any image that Windows could display. Every time I found a bug, I added the image to my test suite before I fixed it. That was good enough for my project.
You could do the same. I believe there's an open source JPEG library that's widely used as a reference implementation.
If you really want to figure out why Firefox (or whatever) cannot open your image, you could try starting with an image that does open in Firefox. Incrementally make small changes (e.g, with a hex editor) to make it more like the image that fails. That might help you narrow down what aspect of your image is tripping up the application. Admittedly, some of those steps may be hard to try.
Firefox, (and many other apps AFAIK) is based on the open-source JPEG library from the Independent JPEG group.
You could download the source for this, and then see exactly why and when it doesn't like your file.
Also, this would save you reinventing the wheel :-)
I think your file is very unconventionally coded. I would suggest that you find a reference file and try to mimic that structure. Also, I would use the sample tables from the standard. Your Huffman data is full of zeros making every DC-value zero, followed by and End-of-block.
If you look in jpegsnoop your image is in two shades but it should be homogeneous. My guess is that you haven't got enough data to code the image at the resolution you've specified. I believe a lot of decoders would assume that it means your file is corrupt.
I have a situation where there is a corrupt WAV file from which I'm trying to recover data.
My colleagues have sliced up the large WAV file into smaller WAV files with proper headers. This has produced some interesting results.
Sliced into 1MB segments we get these results:
The first wave file segment is all noise.
The second wave file segment is distorted.
The third wave file segment is clear.
This pattern is repeated for the entire length of the file (after it's been broken into smaller files).
For 20MB slices:
The first wave file segment is all noise.
The second wave file segment is clear.
The third wave file segment is distorted.
Again, this pattern is repeated for the entire length of the file (after it's been broken into smaller files).
Would anyone know why this is occurring?
Assuming the WAV contains uncompressed (raw) samples, recovery should be easy. You need to know the sample format. For example: 16 bits, two channels, 44100 Hz (which is cd quality). Because one of the segments is okay, then you can look at this to figure out what the right values are.
Then just open the WAV using these values in, e.g., Adobe Audition (formerly Cool Edit), or any other wave editor that supports import of raw data.
Edit: Okay, now to answer your question. Some segments are clear, because then the alignment is right. Take the cd quality again, as I described before. The bytes of one sample look like this:
left_channel_high | left_channel_low | right_channel_high | right_channel_low
(I'm not sure about the ordering here! But it's just an example.) So the first data byte had better be the most significant byte of the left channel, or else you'll end up with fragments of two samples being interpreted as one whole sample:
left_channel_low | right_channel_high | right_channel_low || left_channel_high
-------------------part of first sample------------------ || --second sample--
You can see that everything "shifted" here, which happens because the size of your file slices is not a multiple of the sample size in bytes.
If you're lucky, this just causes the channels to be swapped. If you're unlucky, high and low bytes get swapped. Interestingly, this does lead to kind-of recognizable, but severely distorted audio.
What puzzles me is that the pattern you report repeats in blocks of three. From the above, I'd expect either two or four. Perhaps you are using an unusual sample format, such as 24-bits (3 bytes)?