Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have a Galaxy S II with a wrecked screen. I was wondering if the internals could be salvaged as a tool to teach myself embedded programming. I know C and enough x86_64 ASM that I would be comfortable taking on ARM assembly.
What would the development environment / set up be like?
Would I use the USB connection or is there a more direct way to connect the phone to the computer?
Would I need to prepare the phone in some way?
Let's say I wanted to write a boot loader for it, are there any good resources of where to start?
Is the phone too much of a black box, should I get a board with more documentation than that?
Or alternatively, why this is a terrible idea. Would all the drivers be too difficult to deal with if I wanted to use things like the camera?
Thanks for the help. I have no idea where to start a project like this.
If ADB ("USB debugging") was turned on, you should be able to do some development by (mis-)using adb and the android ndk to write stand alone executables. You can also install a more complete arm linux (debian etc) runtime in a chroot. You could in theory write android apps, and there are ways to trigger them from the adb command line rather than the gui, but so much of android is gui-centric that your interaction with them would be limited. Still, an app could open a network socket and give you telnet/ssh interaction.
If you don't have ADB enabled you might be able to fastboot (or whatever samsung uses) the device into a customized system image where it is enabled, or even a non-android linux build, but that would depend on having an unlocked bootloader.
Depending on how the screen is broken, you might be able to see enough to turn on ADB, for example backlight problems might be solved by lighting at just the right angle, partial cracking by rotating the device to get the needed menu options in a visible area or even deducing what is on the invisible part of the screen from what is on the visible part and a knowledge of what the menus should look like.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Is it possible to create an iOS build in CodenameOne without Apple certificates? Can I install the .ipa file onto my iPad. I am a beginner and $99/y is just too much for merely getting my feet wet! Any workarounds?
Because of the way Codename One works you can just test on Android and then purchase the $99 subscription when you are ready to move to iOS. You will need to buy it anyway regardless of whether you use xcode or not.
Apple didn't allow building on xcode without a certificate until version 7+ (we launched Codename One when version 4 was new). As a workaround we let people use our certificate but this meant they needed to jailbreak their iphone. This also created a lot of issues in our build process due to the complex set of scripts.
With version 7 Apple introduced the ability to build without the certificate but that only works if you have the device physically connected with a cable and have xcode & a Mac. Both of these aren't required for Codename One.
Yes you can, just install Xcode 7 from the Mac App store:
https://itunes.apple.com/us/app/xcode/id497799835?mt=12
Once it downloads, run the app and go to the settings:
click Accounts
click the + in the lower left and add an Apple ID
enter a personal Apple ID, the one you use for the App Store is fine to reuse
When you build an app for iOS, connect the iOS device and choose that AppleID to sign the app when asked.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
If I wanted to write a C program to talk to an X server on Linux and produce the simplest possible visual result, e.g. setting a single pixel on the display, how would I do it?
I want to use as few libraries as possible, to understand it from the ground up, no matter how inefficient/messy the code is.
Update - by "without a library", I mean basically without any of the helper libraries that are available for X, and without a graphics toolkit.
Update - the answer is "through a unix socket", specifically /tmp/.X11-unix/X0 (on this machine at least, presumably for display 0). Actually drawing a pixel is too complicated to get into in an answer here I think.
If you want to use no library at all, you need to do these steps:
Learn assembly for the platform you target
Learn how to make a binary without using the libc on your target. This likely involves writing assembly for setting up the initial stack frame
Learn how to do system calls without using the libc on your target. This likely involves assembly.
Learn and understand network programming and how the POSIX socket API works
Learn how to open network connections without using the libc on your target
Learn and understand the X11 protocol
Implement the subset of the X11 protocol you need
Open a network connection to the X server
Tell the X server to make a window
Negotiate a colour space with the X server
Tell the X server to colour a single pixel in the window
If you want to use the libc and the libsocket, then only the following steps (roughly) remain:
Learn and understand network programming and how the POSIX socket API works
Learn and understand the X11 protocol
Implement the subset of the X11 protocol you need
Open a network connection to the X server
Tell the X server to make a window
Negotiate a colour space with the X server
Tell the X server to colour a single pixel in the window
X11 is getting old. Consider Wayland and read its FAQ. And there are several X related protocols, read about X11 Core protocol, and also conventions like EWMH.
You'll need to read several thousands of pages. Just understanding the protocols would require several months. OReilly published (in the previous century) a serie of 8 to 10 books related to X11.
You might use a low level X11 library, like XCB -or the older Xlib -, it is used by graphical toolkits like Qt or GTK (or FOX, etc..), which are both free software toolkits so you could study their source code (and Xlib & XCB are also free software).
Notice that today's GUI are usually not displaying fonts using X11 text display requests. They often use Xft (and the font is on the client side, not in the Xorg server). Actually, I heard that most of the graphics rendering practically happens on the client side, and that today most X11 requests are just sending pixmaps to the server (so X11 core protocol requests for drawing lines or circles are barely used today). More generally, the trend in major X11 based toolkits like Qt or GTK is to avoid using
the server-side drawing abilities of X11 (e.g. Xlib's XDrawLine or XDrawText), because the toolkit is drawing a pixmap image client side and sending it to the server.
You could consider using a low-level library like libSDL
The important thing to understand is that X11 applications are event driven and based upon an event loop (generally provided by the toolkit) above some multiplexing syscall like poll(2). They are asked by X11 expose or damage events to redraw some screen area (and, of course, keyboard, mouse, and the Xorg server itself are sending events).
See also this answer to a similar question.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I wanted to try my hand at making an OS however I don't really want to do all the hardware interfaces so I was thinking if it was possible to get the core from ubuntu or another linux distro with all the hardware driver interfaces and to build it from there. I really want to start where I can simply printf to the screen in c to create a console like interface or open a grapical interface with openGl or simple pixel buffer for systems without hardware acceleration without regard to hardware.
Sounds kinda cheaty but I think it could work with a little bit of work. It there anywhere I can look for a core like this, I don't need the UNIX part just the interface to the drivers and a kernal to start my code.
Thank you for any information you can shed onto the situation.
Drivers make out the biggest part of an operating system, so what you want to write probably is not an OS.
From what you say it rather sounds like you'd like to have an OS without any predefined graphical interface. This can be easily archieved by using Linux alone.
Note: linux is an operating system which the "distros" extend by adding lots of programs and configurations. The colorful login screens and desktop environments like Unity, Gnome or KDE are only a bunch of programs, configured to autostart as soon as the system is booted. Take those away and you have one single black'n'white terminal with a shell in it and no windows, icons, menus or pointer.
That said you could try two things: Arch Linux (https://www.archlinux.org/) which is a full fledged linux distribution that comes with no desktop environment by default. If you install Arch and start your computer you'll be presented a text login and a shell, no desktop at all. The good thing about this is that you can install any programs (e.g. desktop) any time if you wanted to since Arch comes with a really nice command line package manager and repositories. Without installing any extras this is a good way to learn how to write low-level code that runs on the command line and you'll learn a whole bunch of how to set up Linux too. The Arch Linux wiki is full of very well written guides from geeks for geeks. If you want a full-fledged system that runs just fine with no desktop, this is the way. This might be too easy for you, though.
The second thing is Linux From Scratch (http://www.linuxfromscratch.org/). This is an extensive guide on how to build your own minimal Linux from scratch (who would've guessed…). Here you're way more low-level and you have full control over everything. But since you want to make your own OS the short way this might be the way to go. There's no package managing system and only vanilla code here. The funny thing about LSF is that you can change the Linux source, recompile it and tinker around with everything without having to care about any side effects like common linux services or certain programs not working anymore.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm starting to do programming with CUDA C. Are there any IDE that are especially good for programming with it?
I'm using a windows machine and a personal macbook :D (But I want to know what people use in linux and mac also)
Definitely the better way to code CUDA in Windows right now is Nsight Visual Studio Edition environment. With the release of CUDA 5, comes also the Nvidia Nsight Eclipse Edition, with the same programming capabilities but with the IDE of Eclipse. Nsight Eclipse Edition is available on Linux and MacOS (but not Windows). You can try it already with the CUDA 5 release candidate : http://developer.nvidia.com/cuda/cuda-toolkit
I've used CUDA 2.1, and VS2008, and haven't had any problems. Just make sure after you install the toolkit and the SDK, that you do the following:
Open "My Computer" (or explorer, or whatever) and navigate to C:\ProgramData\NVIDIA Corporation\NVIDIA CUDA SDK\common
Double-click on cutil_vc90.sln (assuming you're using CUDA 2.1 and VS2008); when the solution loads up, you will see a drop-down menu for the build configuration. If you are on a 64-bit platform, you need to change this from Win32 to x64.
Build the solution.
Look up top again -- you should see the build configuration menu that says "Debug". Change it to "Release" and build the solution again.
Close Visual Studio.
Back in the explorer window, find the file "paramgl_vc90.sln". Double-click it to open that solution.
Repeat the same configuration setup and build process as described above, then close Visual Studio.
At this point, you should be able to compile the SDK projects; if you are using VS2008, make sure you open the solutions ending in _vc90.sln. Again, if you're on x64, you need to also make sure to set the build platform to "x64" in that drop-down menu.
If you get this far, and you're ready to write your own projects, check out the "template" project that comes with the SDK. You should be able to make a copy of that and use it for your own stuff, with the compiler settings (for CUDA, that is) already set up.
there is a thread on nvidia for this as well http://forums.nvidia.com/index.php?showtopic=91057
In windows you can use NVIDIA Parallel Nsight Visual Studio solution. I think there is no better alternative for GPU development on windows. And Linux + GPU development == SUX.
There are some attempts to make some Linux distro which would be GPU-development friendly, but given that these are first steps to this goal - I don't expect too much from this product. (Also they have broken links)
Under my Win7 I use MSVS 10 with NVidia debugger and Parallel Nsight integrated. I have cross-platform build with cmake. It's so easy with cmake. Under Linux (I use Fedora 16) I work in QT creator because it integrates well with cmake and debugger (and looks better than other IMXO). Inder Linux you can attach NVidia debugger, too.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I know this question has been brought up before but it was mostly in respect to gdb for a program running on the local machine.
I've had some success with eclipse-cdt but it only seems to work occasionally. Supposedly Insight was previously used to debug (this embedded x86 board) but it seems to be dead.
I only need C debugging not C++. If possible I would prefer to connect through gdbserver (as that is on the advice and I connect to it through the command line all the time) but if you think putting gdb or ssh on the device and using it through those is better please mention those solutions also.
P.S. The version of gdbserver on the device is 7.1 it would be nice if the solution can work with a compatible version of gdb but I might be able to install a different gdbserver version.
I'd recommend eclipse Indigo it has built-in support for remote debugging applications via gdbserver. I just don't know where the source code has to be located for it to work.
Sinec it uses the MI interface of gdb it should work as any other interface that interacts with gdb.
I recommend trying out Qt Creator. It's cross-platform, has pretty good "code insight" features, and is a hell of a lot lighter-weight than Eclipse. It is a full IDE, not just a debugger front-end. It does require a gdb built with python support (client only, I think), but does come with it in its cross-platform installer. It is definitely more geared to developing C++/Qt applications, but does support generic Makefile and CMake projects, and I use it as my everyday C IDE and debugger.
Depending on exactly what kind of remote target you're debugging, the answer to this question could vary a lot. If you're cross-debugging to a deeply embedded microcontroller target running an RTOS, your options are going to be more limited.
For Makefile-based projects, you want to use the "Generic Project" creation wizard, which by default adds all the source files under the specified directory to your project. It may take some manual work to maintain your project, if you want Qt Creator to "understand" things that you've specified in your Makefile like command-line include directories (go in your .includes file), command-line included headers (go in your .config file), and command-line symbol definitions (go in your .config file). The project file list and compile, deploy, and run commands can all be maintained from the GUI though.
How about using DDD? I haven't used it much to be honest, and there seems to be a way to do remote debugging using DDD http://www.gnu.org/s/ddd/manual/html_mono/ddd.html#Remote%20Program
Gdb itself has already built-in curses based pseudo gui. By default, it splits main screen on 2 windows. Upper window contains source code, lower window is command line interface. Also there are other modes allowing to show you register values and assembly. It works well over ssh, so if you can, copy gdb on your device and debug it over ssh. If not, everything above can be applied for debugging over gdbserver.
You can use NetBeans. NetBeans support remote debugging with gdb. Gdbserver support plug-in also exist. I don't test plug-in but remote debugging using ssh working well.
Try Affinic Debugger GUI. It has newer design.
DDD is too old, Affinic Debugger supports all major platforms and is more powerful than DDD.