Sin duda CCS!!! :mrgreen:
Facilito de usar, muy buena informacion y uno se divierte mucho con los bugs :D
Sin duda CCS!!! :mrgreen:
Facilito de usar, muy buena informacion y uno se divierte mucho con los bugs :D
:shock: :?
No tanto, es que he exagerado. C30 es bueno, pero muy complicado.
Y las optimizaciones del código son nulas: cuando tengas un momento prueba a compilar un printf con CCS y con C30 y verás a qué me refiero.
Está claro que para gustos, los colores. Entiendo que os guste más C30, pero no que digáis eso de que con CCS no se controla.
Allí donde se puede llegar con una función de alto nivel, con CCS lo tienes fácil. Pero donde no se llegue, a bajo nivel se trabaja igual con CCS que con C30: escribiendo registros.
Pues yo juraría que los he usado sin problemas: #priority
The keywords HIGH and FAST may be used with the PCH compiler to mark an interrupt as high priority. A high-priority interrupt can interrupt another interrupt handler. An interrupt marked FAST is performed without saving or restoring any registers. You should do as little as possible and save any registers that need to be saved on your own. Interrupts marked HIGH can be used normally. See #DEVICE for information on building with high-priority interrupts.
Yo lo veo claro, CCS para aprender, o proyectos pequeños de poca precision lo veo bien. Sin embargo para proyectos grandes, donde la optimizacion es una prioridad, y donde se requiera mucha precision C30, para algo superior ASM30
Está claro que para gustos, los colores. Entiendo que os guste más C30, pero no que digáis eso de que con CCS no se controla.
Allí donde se puede llegar con una función de alto nivel, con CCS lo tienes fácil. Pero donde no se llegue, a bajo nivel se trabaja igual con CCS que con C30: escribiendo registros.
Vamooooos!!! Si en los PIC18 existen 2 vectores de interrupción, cosa que los que usan CCS muy pocos lo saben, y cuando quieres implementarlo solo te deja utilizar una única interrupción de alta prioridad :D :D Para poder controlarlo completamente en CCS hay que escribir los *.h completos a gusto de nuevo con la definición de cada registro/bits :D
Tener tiempo para poder hacer todo eso es un lujo, yo no puedo permitírmelo. Créeme, si algún compilador funcionara como has descrito, sería mi favorito, aunque el printf ocupara toda la ROM :D
Tener tiempo para poder hacer todo eso es un lujo, yo no puedo permitírmelo. Créeme, si algún compilador funcionara como has descrito, sería mi favorito, aunque el printf ocupara toda la ROM :D
ya llegara el momento en que saquen un compilador que le digas, quiero que se enciendan 5 leds, tenga 2pwm de 30khz y 10khz, y una entrada analogica y se haga solo jaja.pues el wizard del ccs supuestamente te configura todo, aunque no me gusta usarlo :mrgreen:
Tener tiempo para poder hacer todo eso es un lujo, yo no puedo permitírmelo. Créeme, si algún compilador funcionara como has descrito, sería mi favorito, aunque el printf ocupara toda la ROM :D
el caso es que son cosas que en un futuro te sirven para otros proyectos, incluso lo puedes migrar a dspic cambiando algunos registros, piensa por ejemplo que necesitas usar una libreria glcd, pero ahora tu proyecto requiere una pantalla de 192x64, la de ccs no la podras usar, ahora que haces?? Investigas la libreria de ccs y la adaptas para usar la lcd de 192?? Te tiraras mas tiempo viendo el funcionamiento de la libreria de ccs que hacer la tuya propia y modificarla, porque al hacerla tu, sabes por donde van los tiros.