Diseño/normas del software
Moderadores: Kravenbcn, largeroliker, fidelcastro, cerealkiller, pspCaracas, dark_sasuke, m0skit0, LnD, ka69, zacky06
Re: Diseño/normas del software
Pues no te digo yo. C++ permite herencia multiple. Cierto que es para java donde sólo se puede heredar de 1 e implementar otras.
Te refieres a como se comunican, por ejemplo por medio de un Objeto.
Entonces, decimos, bien, pero que tipo de objeto:
- Clase?
- Estructura
- ....
Te refieres a como se comunican, por ejemplo por medio de un Objeto.
Entonces, decimos, bien, pero que tipo de objeto:
- Clase?
- Estructura
- ....
- pspCaracas
- Moderador Global
- Mensajes: 3080
- Registrado: 03 Sep 2009, 03:29
- Ubicación: Buenos Aire - Argentina
- Contactar:
Re: Diseño/normas del software
Ahora pregunto yo, qué se van a comunicar entre sí?
http://farm3.static.flickr.com/2497/3983880148_f5ae0aaab2_o.png
Re: Diseño/normas del software
arisma escribió:Entonces, decimos, bien, pero que tipo de objeto
Los objetos sólo son instancaciones de clases, no hay varios tipos. Y no C++ no tiene interfaces (aunque se pueden simular con clases virtuales).
pspCaracas escribió:qué se van a comunicar entre sí?
A ver si leemos un poco... viewtopic.php?p=64731#p64731
Re: Diseño/normas del software
Sí, clases abstractas con metodos virtuales.
Al ser cada clase distinta, cada objeto lo es.
Quizás si especificas un poco podemos participar más.
EDITO: Si no luego pienso un poco que estoy en el trabajo(y hasta las cejas de trabajo, y hasta otro sitio también)
Al ser cada clase distinta, cada objeto lo es.
Quizás si especificas un poco podemos participar más.
EDITO: Si no luego pienso un poco que estoy en el trabajo(y hasta las cejas de trabajo, y hasta otro sitio también)
Re: Diseño/normas del software
Doble posteo porque puedo.
Pongo un ejemplo de comunicación: la clase cAllegrex, ¿cómo accedería a la memoria? Tendría que pasar a través de la clase "placa base" y ésta acceder a la memoria. A esto me refiero con comunicación. La idea que se me ocurre es presentar un tipo/clase tBus/cBus que interconecte placa base y componente y pueda hacer que la placa base traslade datos de un sitio a otro. De hecho la placa base es prácticamente lo único que haría: trasladar mensajes de un componente a otro.
Otra cuestión es cómo queremos que funcionen los componentes: cada uno en su hilo de ejecución y corriendo todo el rato (que sería lo más parecido al hardware real y lo más veloz, aunque implica concurrencia), o que sea la placa base la que les vaya dando pie en un determinado orden (que no se parece al hardware real y es más lento, pero bastante más sencillo).
Personalmente creo que la segunda opción es la mejor por ahora.
EDITO: ¿Qué quieres que especifique arisma? Y ya no es doble posteo
Pongo un ejemplo de comunicación: la clase cAllegrex, ¿cómo accedería a la memoria? Tendría que pasar a través de la clase "placa base" y ésta acceder a la memoria. A esto me refiero con comunicación. La idea que se me ocurre es presentar un tipo/clase tBus/cBus que interconecte placa base y componente y pueda hacer que la placa base traslade datos de un sitio a otro. De hecho la placa base es prácticamente lo único que haría: trasladar mensajes de un componente a otro.
Otra cuestión es cómo queremos que funcionen los componentes: cada uno en su hilo de ejecución y corriendo todo el rato (que sería lo más parecido al hardware real y lo más veloz, aunque implica concurrencia), o que sea la placa base la que les vaya dando pie en un determinado orden (que no se parece al hardware real y es más lento, pero bastante más sencillo).
Personalmente creo que la segunda opción es la mejor por ahora.
EDITO: ¿Qué quieres que especifique arisma? Y ya no es doble posteo
- pspCaracas
- Moderador Global
- Mensajes: 3080
- Registrado: 03 Sep 2009, 03:29
- Ubicación: Buenos Aire - Argentina
- Contactar:
Re: Diseño/normas del software
Quizás me equivoque, pero es necesario emular el comportamiento del hardware? Yo hace un tiempo hice un emulador de 8085 para la HP y me bastó con emular los registros y las instrucciones que afectaban dichos registros.
http://farm3.static.flickr.com/2497/3983880148_f5ae0aaab2_o.png
Re: Diseño/normas del software
pspCaracas escribió:Yo hace un tiempo hice un emulador de 8085 para la HP y me bastó con emular los registros y las instrucciones que afectaban dichos registros.
¿No tuviste que emular la pantalla? ¿Ni las teclas? ¿Y el sonido? ¿El cifrado? Una PSP no es un procesador suelto sin más... Hay un montón de componentes que emular (lector UMD, lector MS, NAND, tarjeta de sonido, Wifi y suma y sigue) Y ten en cuenta que vamos a correr software hecho por terceros (no por nosotros, aunque obviamente antes de probar software de terceros probaremos nosotros ) para la PSP.
También está claro que en un principio no vamos a emular todo eso. Primero vamos a centrarnos en los componentes fundamentales: procesador y memoria (lo que viene a ser un emulador de Allegrex, un emulador de MIPS). Una vez podamos correr instrucciones sobre este par empieza la verdadera emulación de PSP.
Re: Diseño/normas del software
No sé, sigo sin ver algo claro de esa estructura.
Efectivamente podría haber una clase PSP que será la que se va a emular, que constará además del resto de componentes, de una placa base que será distinta según el modelo.
Podría ser una normal para FAT, otra para el resto(con sus 64MB), o efectivamente podemos no meter la clase modelo y efectivamente queda sustituida por la de placa base.
Lo digo porque según lo que has comentado de los componentes quedan "unidos" por la placa base no me gusta o no lo he sabido entender.
Yo lo veo más como que el emulador creará un objeto psp o placa base(a convenir), y esta clase es la que está compuesta por todo lo demás.
¿O podemos reducir todo a un modelo genérico?, y que un atributo establezca por ejemplo si tiene 64mb y ver si se puede aprovechar o no.Sí, más que decir algo creo que estoy pensando mientras escribo.
Una clase con el bus, ok. O una por cada bus, en caso de haber más de uno. OK. Pero sigo sin ver que pinta la placa, ya que no lo hace a través de ella, ya que todo forma parte de la placa.
Efectivamente podría haber una clase PSP que será la que se va a emular, que constará además del resto de componentes, de una placa base que será distinta según el modelo.
Podría ser una normal para FAT, otra para el resto(con sus 64MB), o efectivamente podemos no meter la clase modelo y efectivamente queda sustituida por la de placa base.
Lo digo porque según lo que has comentado de los componentes quedan "unidos" por la placa base no me gusta o no lo he sabido entender.
Yo lo veo más como que el emulador creará un objeto psp o placa base(a convenir), y esta clase es la que está compuesta por todo lo demás.
¿O podemos reducir todo a un modelo genérico?, y que un atributo establezca por ejemplo si tiene 64mb y ver si se puede aprovechar o no.Sí, más que decir algo creo que estoy pensando mientras escribo.
Una clase con el bus, ok. O una por cada bus, en caso de haber más de uno. OK. Pero sigo sin ver que pinta la placa, ya que no lo hace a través de ella, ya que todo forma parte de la placa.
Re: Diseño/normas del software
A ver, no confundamos. Lo de "placa base" lo pongo entrecomillado por algo. No va a modelar realmente una placa base, sino que simplemente va a ser una clase que controla y coordina a las demás que son las que hacen todo el meollo. Básicamente es lo que dices tú mismo con
Lo que quiero recalcar es que no vamos a modelar una placa base tal cual. Que quede claro
La función de la "placa base" sería controlar y comunicar los componentes entre sí. En una de las opciones que había comentado, sería la placa base la que crearía los objetos componentes y llamaría a los métodos que correspondan de forma secuencial.
Buses hay varios por cada componente, pero el truco de la placa base es para evitar interconectar un componente con TODOS los demás. Con que cada componente se conecte a la "placa base" es suficiente. Además el bus puede ser genérico, pues realmente da igual lo que pueda hacer ya que su mera función es trasladar datos de un componente a otro, y lanzar los métodos que correspondan para cada componente cuando se requieran. Realmente no implementa ninguna funcionalidad.
En cuanto a los modelos concretos, yo me centraría en una PSP 1000, ya que es la más sencilla y mejor documentada de todas. Una vez funcione bien ésta, ya vemos. En todo caso, aún nos queda camino para llegar a algo de esto.
arisma escribió:Yo lo veo más como que el emulador creará un objeto psp o placa base(a convenir), y esta clase es la que está compuesta por todo lo demás.
Lo que quiero recalcar es que no vamos a modelar una placa base tal cual. Que quede claro
La función de la "placa base" sería controlar y comunicar los componentes entre sí. En una de las opciones que había comentado, sería la placa base la que crearía los objetos componentes y llamaría a los métodos que correspondan de forma secuencial.
arisma escribió:Una clase con el bus, ok. O una por cada bus, en caso de haber más de uno
Buses hay varios por cada componente, pero el truco de la placa base es para evitar interconectar un componente con TODOS los demás. Con que cada componente se conecte a la "placa base" es suficiente. Además el bus puede ser genérico, pues realmente da igual lo que pueda hacer ya que su mera función es trasladar datos de un componente a otro, y lanzar los métodos que correspondan para cada componente cuando se requieran. Realmente no implementa ninguna funcionalidad.
En cuanto a los modelos concretos, yo me centraría en una PSP 1000, ya que es la más sencilla y mejor documentada de todas. Una vez funcione bien ésta, ya vemos. En todo caso, aún nos queda camino para llegar a algo de esto.
-
- Enteradillo
- Mensajes: 43
- Registrado: 12 Ene 2011, 16:55
Re: Diseño/normas del software
Segun entendi, la idea es simple, que la clase Placa Base haga las veces de bus y que todas las peticiones entre los diferentes componentes tengan que pasar a traves de ella, probablemente seria mas comodo a la hora de hacer pruebas ya que si por ejemplo, la parte de memoria no esta terminada y se recibe una solicitud por parte del procesador, podemos emular una respuesta (para probar) de parte de la placa base. Despues no le veo mucha mas utilidad que permitir la interconexion (mensajes) entre las diferentes clases, tal vez para hacerlo mas organizado.
ya me corregiran seguramente
ya me corregiran seguramente