Storing of image in on-chip memory of MCB1700 evaluation board - embedded

I work with MCB1700 evaluation board.
It has (320 x 240) TF LCD Display.
IDE: Keil uvision4 4.03q.
My task is to download picture from PC to MCB1700, display it on LCD
and download on USB-stick (that connects to the board).
I need 320*240*2 = 153600 bytes of memory.
MCB1700 has only 64kB SRAM, and 512kB of on-chip Flash memory.
Obviously, I must store picture in Flash memory.
As I understand, I should bind pointer directly to memory address.
/* Base addresses */
#define LPC_FLASH_BASE (0x00000000UL) //beginning address of on-chip Flash
#define LPC_IMAGE_ADDR (LPC_FLASH_BASE + 0x10000)
#define ImagePtr ((unsigned short *) LPC_IMAGE_ADDR )
//read-write operations
ImagePtr[0] = 0x0124; //First pixel
…
ImagePtr[320*240] = 0xFA37; //Last pixel
unsigned short A = ImagePtr[0];
Is it correct?
I have a doubts because of Target’s options.
Flash memory’s area is defined like Read/Only IROM1.
Does it mean that we can only read data from Flash and must change Memory area in IROM and IRAM fields to perform writing operation? For example in such way:

You might do better to let the compiler/linker decide where to place the image in Flash:
static const unsigned short Image[320*240] = { <image data> } ;
will place Image as an array in ROM1 memory.
You cannot write directly to flash memory, it is normally read-only, and while write operations are word oriented, a word cannot be written unless it is previously erased and erasure is page or sector oriented - so it is somewhat more complex to manage that your example code.
In my suggestion above I have included an initialiser. Now it is obviously impractical to manually initialise 320*240 elements, but it is simple enough to write a PC based tool that will generate the necessary initialiser code directly from an image file.
Alternatively, if the image cannot be static, you might reserve part of your Flash for the image and then write code to write the flash memory and where necessary erase pages from data downloaded from a serial port or USB for example. In this case the Flash memory must be page aligned and comprise of an integer multiple of Flash pages.
For flexibility you should not rely on the target dialog settings and instead create a custom scatter file, where you can then create a custom section and allocate your image memory to it using armcc extension __attribute__ variable qualifiers.

Related

Do I need to memory map/unmap a buffer every time the content of the buffer changes?

I'm doing a Vulkan project that renders into an outgoing stream instead of presenting it (no swapchain et al): the rendered image is copied to another image (vkCmdCopyImage) then that later image is memory mapped (vkMapMemory), data is copied somewhere else then it is unmapped (vkUnmapMemory). This is happing at every frame. Is there a way to map the (second) image once, enter the main loop (render a frame at each cycle) then unmap it as part of the application clean-up ?
I tried this but it looks like whenever something is copied to the image, the earlier mapping doesn't work and it has to be unmapped and mapped again.
It is never necessary in Vulkan to unmap memory you have mapped. Even deleting the memory implicitly unmaps it.
However, it is necessary to synchronize access to that memory properly. For modifying an image on the GPU, using execution&memory dependencies to ensure the availability and visibility of the GPU modifications to the host, events that the CPU can wait on/test to ensure that the modification is visible, and if the memory is not host-coherent you will need to invoke vkInvalidateMappedMemoryRanges to ensure visibility of such changes to the host.

Set windows size of QuickLook Plugin

I'm building a QuickLook plugin. I want to change the width of the windows that pops up when user hits the spacebar.
I've read there are two keys in the info.plist file of the project where height and width are customisable. Even if I change those values I can't get the size of the preview windows to my desired one.
I don't know what else to try. Any idea?
Thanks!
Thought I'd dig a little on this. I have not tried any of the following suggestions, so nobody get their hopes up. I'll assume you're using the generator callback:
OSStatus (*GeneratePreviewForURL)(
void *thisInterface,
QLPreviewRequestRef preview,
CFURLRef url,
CFStringRef contentTypeUTI,
CFDictionaryRef options
);
Before anything else, you might manually check the options dictionary argument and verify that the kQLPreviewPropertyWidthKey and kQLPreviewPropertyHeightKey keys are indeed mapped to the desired CFNumber values.
Referring to each of these properties, the Apple QuickLook programming guide says:
Note that this property is a hint; Quick Look might set the width
automatically for some types of previews. The value must be
encapsulated in a CFNumber object.
(Edit: If your preview representation is flexible, you might try finding a preview type for which QuickLook honors your size hints, as per the statement above. Just a thought.)
Running nm on the QuickLook framework binary revealed some undocumented kQLPreviewProperty-- constants as well as the aforementioned width and height keys. One that caught my attention was kQLPreviewPropertyAutoSizeKey. Recalling Apple's statement about ignoring the hints to set the size automatically, this might be significant? Following the convention in QuickLook.framework/Headers/QLBase.h, you might try declaring
extern const CFStringRef kQLPreviewPropertyAutoSizeKey;
Then you could try associating a CFNumber 0 with that property key in the options dictionary. There are other undocumented keys of note, such as kQLPreviewPropertyAttributesKey.
Back to the Info.plist you mentioned, Apple says about those keys QLPreviewWidth and QLPreviewHeight:
This number gives Quick Look a hint for the width (in points) of
previews. It uses these values if the generator takes too long to
produce the preview. (emphasis added)
This is where someone makes the terrible suggestion of calling sleep() in your generator. But I'm perplexed as to why Apple would make following the size hints dependent on the generator latency. (?)
Edit: Also note the above statement says the Info.plist hints must be expressed in points (not pixels), a unit dependent on the user's screen resolution.
Recently I was developing a Quick Look Plugin myself which uses HTML+CSS and faced the same problem.
The solution for my was to test the plugin not within Xcode and qlmanage as the executable but instead to try the real .qlgenerator from my user library.
When invoking the generator from my user library, the Quick Look window was resized exactly the way I specified in the *-Info.plist.
I've run into the same problem, and may offer some clues: In my case I'm generating an image quick look preview for my custom file format. I initiate the preview context to draw my preview into using
CGContextRef QLPreviewRequestCreateContext(QLPreviewRequestRef preview, CGSize size, Boolean isBitmap, CFDictionaryRef properties);
The curious thing is that if I set isBitmap to true, quick look adjusts the preview panel size to the size specified for the context (up to a certain size at least). But if you set isBitmap to false, it seems to disregard the context size and instead always shows a full size preview panel with the vector graphics image scaled to cover the entire panel.
So, if you use a bitmap graphical preview context, it seems the preview panel will be set to the size of the context you specify. However, I haven't found any way to set the size of the panel when using a vector graphic preview context (which is what I want).

How can I change the Dock preferences programmatically?

I'm new to Cocoa/macOS programming. I just found out that NSUserDefaults can be used to change application/system settings, like the way the defaults command does.
But I don't know how to cause these settings to update.
e.g., I use NSUserDefaults to set the dock size to 32, and synchronize the setting. But the dock retains the old setting.
Even when I use defaults write com.apple.dock tilesize 32 to change its size, it won't be updated until I logout and login.
Is there any other technology to notify the dock to get the update? I know that System Preferences can do that.
Thank you!
The Mac OS X dock doesn't reload its settings until it is killed and restarted. In the same way that you'd have to change its settings manually via the terminal (defaults write com.apple.dock tilesize 32; killall Dock), you have to do that in code. So, while you've written the defaults portion of the code, you have to write the kill portion:
NSRunningApplication *dock = [NSRunningApplication runningApplicationWithBundleIdentifier:#"com.apple.dock"];
[dock terminate];
If you want to do this without killing the dock, sorry, but you're out of luck. While there might be a hidden API to force the dock to reload its settings on the fly, in all my searching I have never found any hints of how one can do this (there are no notifications posted on the hidden distributed notification center that most applications to interact with one another).
With the magic of the Xcode debugger and some formatted disassembly, I've created this short header file you can paste into your code (GitHub gist is here). Function names are hopefully self-explanatory.
// TO USE THESE INTERFACES, you MUST link against ApplicationServices.framework.
#pragma once
#ifdef __cplusplus
extern "C" {
#endif
// Boolean preferences
extern void CoreDockSetLaunchAnimationsEnabled(bool enable);
extern void CoreDockSetMagnificationEnabled(bool enable);
extern void CoreDockSetAutoHideEnabled(bool enable);
extern void CoreDockSetMinimizeInPlace(bool enable);
// Sets other preferences such as whether the indicators below the app icons are shown
// 'preferenceDict' is a CFDictionary containing a magic key value
// Will require further inspection of Dock.prefpane to find all the keys
// (I haven't noted them down)
extern void CoreDockSetPreferences(CFDictionaryRef preferenceDict);
#ifdef __cplusplus
} // extern "C"
#endif
Preferences updated in this way are reflected instantaneously, because these functions actually messagethe "com.apple.dock" mach service internally.
Have fun!
PLEASE NOTE: These are private system APIs. Any apps submitted to the Mac App Store that use these APIs will be rejected. On another note, if you have no App Store intentions, there's no harm in using these interfaces. They appear to have existed since the very dawn of Mac OS X, and it's highly improbable they'll be disappearing in the near future, if ever.
You can use AppleScript to set some of the properties of the dock by scripting System Preferences, you may want to take a look at seeing if you can take that approach instead? Maybe call some AppleScript from your app?

Setting sound output/input

I've been looking all over the web, but I don't know if it is possible: can a Cocoa Mac OS X app change the sound input/output device? If so, how come?
can a Cocoa Mac OS X app change the sound input/output device?
Yes, by setting the relevant Audio System Object property.
If so, how come?
Probably because the user might want to change the default input or output device from within an application, rather than having to jump over to the Sound prefpane before and after or use the Sound menu extra.
I know this is an old post but I've been struggling these days trying to find a way of changing the sound input/output device using code and I finally found how to do it. In case someone else runs into the same problem, here's the answer!
There's a command line utility called SwitchAudio-OSX (https://code.google.com/p/switchaudio-osx/) that allows you to switch the audio source from the terminal. It is open-source and you can find the latest version here: https://github.com/deweller/switchaudio-osx.
Anyway, you can use these lines to change the sound input/output device:
UInt32 propertySize = sizeof(UInt32);
AudioHardwareSetProperty(kAudioHardwarePropertyDefaultInputDevice, propertySize, &newDeviceID); // To change the input device
AudioHardwareSetProperty(kAudioHardwarePropertyDefaultOutputDevice, propertySize, &newDeviceID); // To change the output device
AudioHardwareSetProperty(kAudioHardwarePropertyDefaultSystemOutputDevice, propertySize, &newDeviceID); // To change the system output device
Where newDeviceID is an instance of AudioDeviceID and represents the id of the device you want to select. Also, a list of all available devices can be obtained using this code:
AudioDeviceID dev_array[64];
AudioHardwareGetProperty(kAudioHardwarePropertyDevices, &propertySize, dev_array);
int numberOfDevices = (propertySize / sizeof(AudioDeviceID));

Printing without an NSView

Currently I'm writing an app for OSX which will eventually need to be ported to iOS.
The data that needs to be printed is being drawn via CoreGraphics into a PDF context - that is working perfectly.
I've been reading the Apple dev documentation on printing in both iOS and OSX, and, ironically, it actually seems printing from iOS will be easier.
On iOS, UIPrintInteractionController's printingItem property can take an NSData object containing PDF data and print that. Looks like it should be fairly straight-forward.
OSX on the other hand, (looks like it) requires using the NSPrintOperation class - but it seems the only way to get data into an instance is via an NSView. (+printOperationWithView: or +printOperationWithView:printInfo:).
Seeing as the content is formatted and paginated already it seems rather pointless to have to re-draw the PDF data to something like an NSView.
Could there possibly be another way of achieving this that I've missed?
This code is by no means complete, but for anyone who comes across this later, this is basically how you can print directly from an NSData stream:
#define kMimeType #"application/pdf"
#define kPaperType #"A4"
- (void)printData:(NSData *)incomingPrintData {
CFArrayRef printerList; //will soon be an array of PMPrinter objects
PMServerCreatePrinterList(kPMServerLocal, &printerList);
PMPrinter myPrinter;
//iterate over printerList and determine which one you want, assign to myPrinter
PMPrintSession printSession;
PMPrintSettings printSettings;
PMCreateSession(&printSession);
PMCreatePrintSettings(&printSettings);
PMSessionDefaultPrintSettings(printSession, printSettings);
CFArrayRef paperList;
PMPrinterGetPaperList(myPrinter, &paperList);
PMPaper usingPaper;
//iterate over paperList and to set usingPaper to the paper desired
PMPageFormat pageFormat;
PMCreatePageFormatWithPMPaper(&pageFormat, usingPaper);
CGDataProviderRef dataProvider = CGDataProviderCreateWithCFData((CFDataRef)incomingPrintData);
PMPrinterPrintWithProvider(myPrinter, printSettings, pageFormat, (CFStringRef)kMimeType, dataProvider);
}
(via Core Printing Reference)
Beware this code lacks memory management so you will need to use the PMRetain() and PMRelease() functions as well as the CoreFoundation memory-management functions as well.
If anyone can tell me how I can get data from the OSX print dialogue into data I can use in this method I'll accept their answer instead of this. That is, without using Carbon functions.