• State
  • Locked Locked
  • Replies 36 replies
  • Subscribers 34 subscribers
  • Views 3524 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Need Guideline for display Image on KENTEC from SD card.

priya jain
Prodigy 230 points

Hello All,

   I am Using TM-4C129X Development kit . I am confused for Display image from Sd card. I have tried lots but not get proper solution for that .

Please if you any one have solution or document regarding to display image from sd card ,please provide me or guide me.

I have confusion for format of data which passes to GrImageDraw() , I know that we have to pass hex value but proper format name or algorithm of that format because i know i need to convert .Pmm file to hex but using which algorithm?

please give appropriate solution.

Thanks in advance.

  • 0
    TI__Guru**** 244400 points
    Hello Priya,

    There are a number of online tools that convert bmp/jpg/png, etc or PNM format which can be processed by the pnmtoc.exe in the TivaWare tools to generate the header file.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 230 points

    Hi Amit ,

    I have successfully generated and tested file using pnmtoc.exe . But I want to Read image from memory card . I have put .h file to memory card but when I read from SD card and pass it to GrImageDraw() function but it is not display anything .

    it's only show blank white display.

    iFResult = f_open(&g_sFileObject, "newn.hex", FA_READ);
    iFResult = f_read(&g_sFileObject, g_pcTmpBuf, sizeof(g_pcTmpBuf) - 1,
    (UINT *)&ui32BytesRead);
    GrImageDraw(&g_sContext, (const unsigned char*)g_pcTmpBuf, 0, 0);

    Please guide me for image reading and display from memory card.

    Thanks & Regards

  • 0 in reply to priya jain
    TI__Guru**** 244400 points
    Hello Priya,

    Where is the hex file being relocated and does the main application link to the same?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 230 points
    Hi,

    Hex file is in memory card . I am reading data from memory card using buffer g_pcTmpBuf .
    iFResult = f_open(&g_sFileObject, "newn.hex", FA_READ);
    iFResult = f_read(&g_sFileObject, g_pcTmpBuf, sizeof(g_pcTmpBuf) - 1,
    (UINT *)&ui32BytesRead);
    GrImageDraw(&g_sContext, (const unsigned char*)g_pcTmpBuf, 0, 0);

    Thanks
  • 0 in reply to priya jain
    TI__Guru**** 244400 points
    Hello Priya,

    And did you check that the g_pcTmpBuf contains the same bytes as the original hex file?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 230 points
    Hello

    Yes I have check the f_pcTnpBuf buffer it's contain same hex file data but in form of char array means one hex value is converted in four byte of array.



    Thanks & Regards
  • 0 in reply to priya jain
    Guru 117855 points
    You should gain insight by placing, "known, well-recognizable data" w/in, "g_pcTmpBuf" and seeing how that appears on your screen. That data's appearance - or lack of arrival - will prove most revealing.

    This is "KISS" in action - currently you have the SD card, data movement, data unpacking and finally transmission of data to the display. Thus any/all "error conditions" are "masked" by complexity. Divide & conquer works best in such cases...
  • 0 in reply to priya jain
    TI__Guru**** 244400 points
    Hello Priya,

    And did you check what the driver gets the value when drawing the image, by putting a breakpoint at the PixelDraw function call?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points
    Hi Amit,

    That's good advice - and does fit under the "KISS" umbrella. I believe it would be strengthened by simplifying - by "forcing" a recognizable value into "Pixel_Draw" (other than 0x00 - which would not be visible) and seeing if that known data, "Makes it" to the screen...

    My point (actually KISS's point) is that difficulty may arise prior to "Pixel_Draw" - thus the "forced seed" of known data into Pixel_Draw eliminates a major unknown...
  • 0 in reply to cb1
    TI__Guru**** 244400 points
    Hello cb1

    Yes, it does. Since the user has verified that g_pcTmpBuf matches the sd card data, it would be obvious to see to how the values goes down to the driver. Passing a predefined array would be the intermediate step, before checking g_pcTmpBuf....

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points
    Hi Amit,

    KISS would suggest the simplicity of a few (known/recognizable bytes) prior to, "Unrolling an array." Sequence of small, well measured steps - building systematically towards the end goal...
  • 0 in reply to priya jain
    Guru 27665 points

    I agree it is wise to ensure you can display an image at all before moving to storage but this process ....

    Amit said:
    There are a number of online tools that convert bmp/jpg/png, etc or PNM format which can be processed by the pnmtoc.exe in the TivaWare tools to generate the header file.

    priya jain said:
    I have put .h file to memory card but when I read from SD card and pass it to GrImageDraw() function but it is not display anything .

    strikes me as highly unlikely to work. Generated code is generally meant to be compiled into the application not read from disk. You could write a parser for the header file but you are probably further ahead to write one for a simple image format instead.

    Robert

  • 0 in reply to Robert Adsett
    Guru 47900 points

    May I agree w/poster Robert? C'est tres bien mon ami.

    And - loitering the image data w/in MCU memory is wasteful - is it not?    Image data "belongs" in separate, OFF-MCU space - was (always) handled in that manner prior to this (unique) Graphic Lib's arrival!

  • 0 in reply to Robert Adsett
    Prodigy 230 points
    hi Robert ,

    I have already used pnmtoc .exc application for generate .h file and I have used in code it's working file . but I need to read all image from sd card. so I need guide line for that.

    thanks
  • 0 in reply to Robert Adsett
    Prodigy 230 points
    Hi ,

    Can Any one tell me which format that is recognized by the graphics library ? I want to know that because GrImageDraw() function definition is not accessible in c.


    Thanks
  • 0 in reply to priya jain
    Guru 117855 points
    It was twice suggested that you "seed" your pixel_draw function with known value - and test to see if that function (then) succeeds.

    Multiple issues lurk in your design - and if the "back-end" (draw to the screen) fails or is in error - a perfect "front-end" (recovery & massage of data from SD card) will be, "held hostage."
  • 0 in reply to cb1_mobile
    Prodigy 230 points
    hi,

    Thank you very much but in your suggestion what is meaning of known value? I don't know which format I have to read from sd card and pass direct to pixel_draw.


    Thanks
  • 0 in reply to priya jain
    Guru 117855 points

    Would not that answer lie w/in the source code w/in "Pixel_Draw()?" At any rate - I'd sense that a simple "byte value of 0XAA" (alternating display bits)  Such known  values - passed to Pixel_Draw - can quickly/easily be noted upon your screen - IF the "back end" is working.  

    Once that's conquered - you may note the correlation between data fetched from the SD card - and that which succeeds - as it gains entry to Pixel_Draw.

    Divide & conquer is your signpost.   Too many unknowns are in play (now) - my suggestion is that you break your project into far smaller pieces - and devise means to test/troubleshoot and verify each.

    That's KISS - and surely will yield best results for you - both now and LONG into the FUTURE!   (90% + of failed projects here ALL result from "hodge-podge" of functions - none ever properly test/verified - all tossed into "witches brew" - and posters are (inevitably) reduced to, "Does NOT Work!"

  • 0 in reply to priya jain
    Guru 27665 points

    TivaWare™ Graphics Library USER’S GUIDE said:
    GrImageDraw

    Draws a bitmap image.

    Prototype:

    void

    GrImageDraw(const tContext *pContext,

    const uint8_t *pui8Image,

    int32_t i32X,

    int32_t i32Y)

    60 May 07, 2015

    Graphics Primitives

    Parameters:

    pContext is a pointer to the drawing context to use.

    pui8Image is a pointer to the image to draw.

    i32X is the X coordinate of the upper left corner of the image.

    i32Y is the Y coordinate of the upper left corner of the image.

    Description:

    This function draws a bitmap image. The image may be 1 bit per pixel (using the foreground

    and background color from the drawing context), 4 bits per pixel (using a palette supplied in

    the image data), or 8 bits per pixel (using a palette supplied in the image data). It can be uncompressed

    data, or it can be compressed using the Lempel-Ziv-Storer-Szymanski algorithm

    (as published in the Journal of the ACM, 29(4):928-951, October 1982).

    Robert

  • 0 in reply to priya jain
    TI__Guru**** 244400 points
    Hello Priya

    If you want to debug the grlib, then recompile the grlib on your machine and use the new precompiled library in your project instead of the default grlib.lib from TivaWare. You can then step debug in the GrImageDraw

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 230 points

    Hi Amit,

    how we can recompile grlib ? I have not get this point . please give suggestion.


    Thanks & Regards

  • 0 in reply to priya jain
    TI__Guru**** 244400 points
    Hello Priya,

    In CCS import the grlib as a project.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 10570 points
    Amit,

    I think you may be headed down a blind alley. If I read this correctly Priya is trying to feed the image file contents directly to the draw function.

    Robert
  • 0 in reply to Robert Adsett72
    TI__Guru**** 244400 points
    Hello Robert

    Good point. I believe that the hex file being read out from the sd card is the converted pnm file.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points

    Does not poster's lack of clear & detailed "guidance/specification" vastly complicate our efforts?

    Multiple (unexplained) scenarios (I would think) exist - and may require different methods to achieve design objectives.  

    Some fundamental questions:

    • When is the image acquired?  
    • When must the image be processed and then viewed?

    Should the image be acquired "live" - this MCU & methods appear over-matched.   (A JPG-engine capable MCU rises to top dog)

    In this (somewhat "up in the air") case it appears that the images "pre-exist" yet (at least to me) their format remains unclear.   This then allows the "raw images" to be processed - and then I believe they may be stored to the SD card.   (provided that the unpacking of such image proves acceptable to this vendor's MCU)

    Far earlier KISS arrived here - argued for the load of a "recognizable byte (or bytes)" which would then be passed to "Pixel_Draw" (or similar - we don't use vendor's Gra lib)   This then would confirm the working of the "Back-End" (Processed image data sent to the screen.)

    Remaining then is the "Front End" (mainipulating the image into the format most acceptable to the "Back-End" & then stored w/in SD card.)

    This method complies w/KISS - and has been bypassed - and (as usual) hunt/peck/twist/turn extends forever...   (as witnessed here - far too often)

  • 0 in reply to Amit Ashara
    Prodigy 230 points
    hi amit ,

    you are right. I am reading converted hex file from sd card. But is it possible to pass pnm file value directly to GrImageDraw() function.?

    Thanks
  • 0 in reply to priya jain
    Guru 117855 points
    Perhaps poster's Subject line, "Guidelines" should (properly) change to, "Lifelines!"

    At "30" ineffectual "back-forths" might the "Slaughter Rule" be employed? (just say'in)
  • 0 in reply to priya jain
    Guru 27665 points

    No, as should be obvious from the manual section I posted earlier.

    Robert

  • 0 in reply to priya jain
    TI__Guru**** 244400 points
    Hello Priya,

    Yes it is possible to pass the values to GrImageDraw. Also as Robert mentioned, the value being read from the hex file is the same content as the C file code that is used for the image.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 27665 points
    No they cannot Amit,

    To quote from en.wikipedia.org/.../Netpbm_format

    "Each file starts with a two-byte magic number (in ASCII)..."
    "The ASCII formats allow for human readability and easy transfer to other platforms; the binary formats are more efficient in file size but may have native byte-order issues.

    In the binary formats, PBM uses 1 bit per pixel, PGM uses 8 bits per pixel, and PPM uses 24 bits per pixel: 8 for red, 8 for green, 8 for blue."

    These cannot be passed directly to GrImageDraw

    Robert
  • 0 in reply to Robert Adsett
    TI__Guru**** 244400 points
    Hello Robert,

    And that is what I want to ascertain. The format of the file being read out.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 27665 points
    It doesn't matter. You cannot feed it directly to the draw function

    Robert
  • 0 in reply to Robert Adsett
    Guru 27665 points
    To quote directly from Priya

    "But is it possible to pass pnm file value directly to GrImageDraw() function.?"

    The answer is clearly and unequivocally no.

    Robert
  • 0 in reply to Robert Adsett
    TI__Guru**** 244400 points
    Hello Robert,

    If the file is in binary format then it can be. I use the scheme to read wav, bmp and jpg files from a sd card.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 27665 points
    No, only a custom file format would allow that , all others have at least a header and jpg has compression. You cannot feed either bmp or jpg file directly to the draw function. There must be a layer of decoding.

    Priya is not creating a file format but trying to feed the file image to the draw function via an fread/fwrite pair

    Robert
  • 0 in reply to Robert Adsett
    TI__Guru**** 244400 points
    Hello Robert,

    I agree. That is what I do. I strip out the header and use the information in the header to pass to the decoder functions. In this case the same has to be done for the pnm file. The pnm file output can be stored as a text file and the content of the text file read out to assemble the image.

    Regards
    Amit