› Foros › PlayStation 3 › Modchips y Softmods
Dentro del SDK de Symbian
Para desarrollar una aplicación para teléfonos móviles, además de necesitar conocer medianamente bien un lenguaje de programación, ahora mas que nunca debido al imparable avance de las nuevas tecnologías, se necesita conocer también casi a la perfección la estructura de los emuladores usados en los SDKs.
En este tutorial se intenta explicar la estructura básica de los SDK para EPOC&Symbian, q deberían ser la base para cualquier futuro SDK ya sea de Nokia o SonyEricsson.
Lenguajes de programación y SDKs
Lenguajes
* C++ Visual Studio, Borlan, GCC
* Java
* OPL de Psion
* VB por appforge
EPOC versión 5
* C++ SDK EIKON
* C++ SDK Psion Revo
* Connectivity SDK (C++ & VB)
* Java SDK
* OPL SDK
Symbian 6.0
* Nokia C++ y java SDK
* Quartz C++ y java SDK
Symbian 6.1 y 7.0
* Nokia, Ericsson, Motorota SDKs
C++ SDKs permite desarrollar aplicaciones que se compilan en el lenguaje nativo del aparato o para ejecutarse en el emulador. Estos programas son los más rápidos y optimizados.
Java SDKs realiza aplicaciones que son interpretadas en VM (Virtual Machina) de cada plataforma. En estos momentos se usa principalmente para desarrollar juegos, ya que por motivos de seguridad no puede acceder a todas las opciones del sistema.
OPL SDK no funciona para DFRD Quartz. OPL es un lenguaje interpretado (interpreted language) utilizado para las primeras versiones de EPOC y desarrollado por Psion.
Connectivity SDKs permiten al teléfono compartir datos con el PC, sincronización y conversión de archivos.
SDKs para las versiones 6.0 en adelante se pueden encontrar fácilmente en internet facilitado por los fabricantes de cada teléfono. Para SDK de ER5 (EPOC versión 5) se debe buscar en algunas paginas web, como la pagina oficial de Symbian, o conseguirlos por algún otro medio, por ejemplo en el libro “Professional Symbian Programming” vienen 4 SDKs para ER5.
Estructura del árbol de directorios
Todos los SDKs pueden ser instalados donde se quieran, e incluso pueden estar en la misma unidad de disco, pero no en el directorio raíz. Durante el proceso de instalación se le pregunta al usuario donde quiere tener el directorio raíz. La estructura del directorio se distribuye entonces de tal manera que se pueden agrupar distintos SDKs juntos en ese directorio raíz, por ejemplo Series 9200 C++, Series 9200 Java y Series 60 C++. También se puede tener en el mismo sitio distintos SDKs de DFRD (Nokia, SonyEricsson…). Algunos de los archivos son comunes para todos los SDKs, como documentación y herramientas y el directorio “shared”.
El entorno “runtime” de cada SDK y sus respectivas librerías y ficheros de cabecera son distintos. De hecho hay un directorio por casa DFRD/SDK. Es a este directorio a donde la variable de entorno EPOCROOT tiene que indicar. La variable EPOCROOT se crea al instalar cada SDK y se tiene que modificar cuando se quiere cambiar de SDK.
El directorio epoc32include tiene todos los archivos de cabecera que pueden ser incluidos en las aplicaciones. Resulta importante poder buscar rápidamente en ellos, por ejemplo con el IDE Microsoft´s Developer Studio usando la opción “Find in files” o pulsando con el botón derecho sobre una clase o función en la ventana del código y usar “Go to Definition”.
Las familias de DFRDs pueden ser:
* Cristal
* Quartz
* Pearl
Directorios de %EPOCROOT%
Los directorios del SDK a “runtime” son todos relativos al directorio especificado en la variable de entorno %EPOCROOT%.
* epoc32 - contiene todos los archivos “runtime” del SDK
* epoc32data - epoc.ini (parámetros de inicialización del emulador) y epoc.bmp (imagen del teléfono emulado por el SDK)
* epoc32 elease - separa los ficheros de las aplicaciones generadas por el SDK de la documentación, ficheros temporales, ficheros de configuración, etc.
* epoc32 eleasewinsudeb - separa las versiones debug de la aplicación de las otras versiones (epoc32 eleasewinsurel)
* epoc32 eleasewinsudebz - contiene todo que la unidad z: del Symbian OS debería contener con la excepción de las DLLs compartidas, que se encuentran en el directorio zsystemlibs
* epoc32winsc - información. Cualquier dato escrito por el emulador en la unidad C esta incluido aquí
Directorios Compartidos
* DeveloperLibrary - contiene la ayuda HTMLHelp precompilada que proporcional una excepcional fuente de ayuda al desarrollador. Los subdirectorios contienen los archivos HTML de la ayuda compatibles con un navegador.
* TechicalPaper - documentos técnicos y descripción de algunos ejemplos.
* epoc32 - acapara todas las herramientas compartidas
* epoc32gccin - contiene el compilador gcc (GNU Cross Compiler)
* epoc32 ools - herramientas de ayuda del SDK descritas en la documentación del mismo
Durante la instalación el PATH es modificado añadiéndole los directorios epoc32gccin y epoc32 ools . Además, se tiene que incluir en él el PATH de los archivos binarios del PERL (scripting tool binary directory) que por defecto es c:perlin. Y por ultimo, el Visual Studio tiene que incluir sus PATH para poder construir las aplicaciones (C++) en la línea de comando. Si esto no se realiza durante la instalación, se puede realizar manualmente ejecutando el archivo c:appsMicrosoft Visual Studiovc98invcvars32
Recordar que en tutórales previos hemos mencionado la importancia de dejar las opciones por defecto en cuanto a nombres de directorios y si se cambiaran, no incluir ningún espacio en blanco, ya que no seria detectado por el script de Perl.
Unidades de disco
La correspondencia con las letras de unidad en el aparato emulado en el SDK es la siguiente:
* Z: - contiene la ROM con el sistema operativo y las aplicaciones estándar proporcionado con el teléfono.
* C: - es parte de la RAM. La RAM es compartida dinámicamente proporcionando espacio para instalar nuevas aplicaciones, datos creados por el usuario y espacio para los procesos ejecutándose en el teléfono. Generalmente el usuario solo podrá ver los archivos generados por el, lo demás debería estar oculto
* D: - memoria removible
En el teléfono, Z: normalmente no es visible (en Quartz todos los archivos del sistema están ocultos). En el emulador, se puede acceder a el pulsando CTRL+ALT+SHIFT+T
En el SDK, las unidades son reasignadas para evitar conflictos entre debug y release versiones:
* C: - epocwinsc
* Z: - epoc32 eleasewinsudebz o epoc32 eleasewinsudebz
Directorios en las unidades (Z: C:)
* System - contiene todos los archivos de sistema
* SystemApps - contiene todas las aplicaciones
* SystemAppsapnombreapnombre.app – para reconocer las aplicaciones instaladas
* SystemLibs - contiene las DLLs compartidas
Autor:
Juan de Miguel Hernández
chili_fi
devBlue escribió:Gracias por las primeras respuestas, gran velocidad, muy buenos aportes, en especial los de snakexn y pioner.
Estoy empezando a descartar la opcion del Python (PyS60) y optar por el Nokia Qt SDK.
Pero antes de tomar ese camino voy a revisar http://www.forum.nokia.com/piazza/wiki/images/b/b4/Python_final.pdf .
Einy escribió:Pero vamos a ver señores como hay que explicar que mientras no se modifique el driver del usb para hacerse pasar por un hub, enviar cabeceras modificadas, etc no se puede hacer nada, ni en python, ni en java, ni con nada parecido.
Ahora diréis que si critico y no aporto, pero es que esto clama al cielo...
Un saludo.
DiGiCharatFan escribió:Einy escribió:Pero vamos a ver señores como hay que explicar que mientras no se modifique el driver del usb para hacerse pasar por un hub, enviar cabeceras modificadas, etc no se puede hacer nada, ni en python, ni en java, ni con nada parecido.
Ahora diréis que si critico y no aporto, pero es que esto clama al cielo...
Un saludo.
Esta claro que con los que somos estamos dando palos de ciego, tanteando el terreno para ver si es viable o no, tenemos que saber si se puede programar a tan bajo nivel cómo para lograr controlar el USB, si python no es la solución, tendremos que hacerlo con el SDK de symbian que supongo será C pero por algún sitio se empieza aunque estos tampoco nos da la total certeza de lograr lo principal, que es lo de simular un HUB.
En la nueva versión de Symbian^3 y ^4 (creo que no hay ningún dispositivo en el mercado) creo que ya se incorpora una capa para trabajar extendidamente con el USB .
Creo que en estos momentos no se puede dar la total certeza de que el proyecto pueda ir a buen puerto, no por el hecho de que una calculadora (TI-84) pueda usarse, quiere decir que nuestro dispositivo Symbian pueda
Saludos, y muchos ánimos, va a ser un duro camino para conseguir este proyecto...
PD: Aunque desconozco a que versión de simbian se implementa esto (creo que va atado a la ^3 y ^4) pero aqui dejo un link interesante: http://developer.symbian.org/wiki/index ... tivity/USB este proyecto esta pensado para trabajar en la última capa del USB con la que posiblemente sea nuestra última salida a conseguir el proyecto, pero al precio de no usar python ni que sea compatible con la gran mayoria de dispositibos symbian!
/** @file
*
* Resource file for usbman configuration.
*
* Copyright (c) 2005-2007 Symbian Software Ltd. All rights reserved.
*/
//NAME USBM
#include <badef.rh>
#include "usbman.rh"
RESOURCE BA_RSS_SIGNATURE
{
signature = 1;
}
//RESOURCE usb_configuration usb_config
// {
// }
RESOURCE PERSONALITY_ARRAY device_personalities
{
personalities =
{
PERSONALITY
{
bDeviceClass = 02;
bDeviceSubClass = 0;
protocol = 0;
numConfigurations = 1;
vendorId = 0x0e22;
productId = 0x000b;
bcdDevice = 0x0200;
manufacturer = "ACME";
product = "Widget";
id = 1;
class_uids = "101FBF22";
description = "Modem personality";
}
};
}
snakexn escribió:creo que esta muerto este Hilo en serio es tan dificil programar en SYMBIAN=
f5inet escribió:a ver, puntualicemos: el port a Symbian no tiene mucho futuro por varias razones:
1) no vale programar en python, hay que programar a mas bajo nivel, como lenguaje C, puesto que realmente tienes que escribir un Driver que mande cadenas puras (o raw) por el puerto USB para emular un Hub USB y varios dispositivos de almacenamiento masivo conectandose/desconectandose en una determinada secuencia
2) aunque podamos desarrollar drivers en C en plataforma symbian (que no se como andara eso para el usuario final), no es garantizado que cada telefono symbian tenga exactamente el mismo chipset USB. por ejemplo, con la familia Android, existen mas de 8 famlias de chipsets USB, y solo han desarrollado drivers para 2 o 3 de ellos, el resto de android estan en dique seco.
3) Sony ha capado el exploit en la version 3.42, luego se desarrollaria algo que ahora mismo NO SIRVE, y como comprenderas, nadie se va a tomar el tremendo esfuerzo que hace falta para desarrollar y depurar algo asi para desarrollar algo que ni va funcionar en el 100% de telefonos symbian ni va a funcionar en el 100% de consolas PS3.
4) es posible que el exploit de PSGroove sea actualizado, eso significa que puede ser que todo el trabajo que haya que realizar para emular USBs y tal, no sea necesario de ahora en adelante porque descubren un bug mas sencillo ahora que se tiene acceso total
5) actualmente es mucho mas sencillo, barato y rapido agenciarse un PIC 18f2550 y un par de componentes mas y montarse un PSGrooPIC, que en esta misma pagina tienes los esquemas. el precio total del invento serian menos de 20€, y aprenderias mucho mas soldando un par de PICs y componentes y programandolos que intentando desarrollar un port para Symbian.
f5inet escribió:5) ... y aprenderias mucho mas soldando un par de PICs y componentes y programandolos que intentando desarrollar un port para Symbian.
DjEloY escribió:haber amigos no agamos con el de psp todos tenemos algun symbian , vamos a ayudarle un poco y dejemos de ofrecer los: [/b][/size]
f5inet escribió:5) actualmente es mucho mas sencillo, barato y rapido agenciarse un PIC 18f2550 y un par de componentes mas y montarse un PSGrooPIC, que en esta misma pagina tienes los esquemas. el precio total del invento serian menos de 20€, y aprenderias mucho mas soldando un par de PICs y componentes y programandolos que intentando desarrollar un port para Symbian.
Plata escribió:f5inet escribió:5) actualmente es mucho mas sencillo, barato y rapido agenciarse un PIC 18f2550 y un par de componentes mas y montarse un PSGrooPIC, que en esta misma pagina tienes los esquemas. el precio total del invento serian menos de 20€, y aprenderias mucho mas soldando un par de PICs y componentes y programandolos que intentando desarrollar un port para Symbian.
Tengo un movil symbian, asi que me viene bastante bien. Lo segundo, de pics se bastante mas de lo que voy a aprender haciendo eso, e cacharreao mucho con pics. Y lo tercero nunca e tocado symbian y me parece buena forma de aprender xDD Y si actualizan el psgroove ya se actualizará su version symbian. Me parece que esas mismas razones se las puedes poner a los que lo portearon a android...
salu2!
f5inet escribió:Plata escribió:f5inet escribió:5) actualmente es mucho mas sencillo, barato y rapido agenciarse un PIC 18f2550 y un par de componentes mas y montarse un PSGrooPIC, que en esta misma pagina tienes los esquemas. el precio total del invento serian menos de 20€, y aprenderias mucho mas soldando un par de PICs y componentes y programandolos que intentando desarrollar un port para Symbian.
Tengo un movil symbian, asi que me viene bastante bien. Lo segundo, de pics se bastante mas de lo que voy a aprender haciendo eso, e cacharreao mucho con pics. Y lo tercero nunca e tocado symbian y me parece buena forma de aprender xDD Y si actualizan el psgroove ya se actualizará su version symbian. Me parece que esas mismas razones se las puedes poner a los que lo portearon a android...
salu2!
con todo el respeto del mundo: si quieres aprender, metete en android. Symbian a dia de hoy esta muerto y enterrado. el accionista mayoritario (y por ende, propietario) de Symbian esta abandonando esa plataforma para centrarse en Maemo, basado en Linux (Estoy hablando de Nokia).
por supuesto, tu puedes hacer con tu tiempo lo que estimes oportuno.