Jump to content

djl

EstablishedMember
  • Content count

    13
  • Joined

  • Last visited

Community Reputation

0 Neutral

About djl

  • Rank
    Newbrie
  1. Normal C language (turbo C or ANSI C ) for this if variable define as static then by default value that variable is zero.But if variable define other than "static" than & than this variable value is undefine. I'am not aware of such rule. Please refer where in the ANSI C standard it is specified that static variable that doesn't have an explicit initializer should be initialized with zero. Regards, Pavel <{POST_SNAPBACK}> And I quote, from ISO/IEC 9899:TC2, the latest ANSI committee draft C language standard, dated May 6, 2005, page 126, section 6.7.8, titled "Initialization":
  2. djl

    Lcd Plugin Enhancements

    I verified tonight that my code works correctly on the actual Truly 4x20 display, and incorrectly in the new 4x20 plugin. The bug is exactly as I described, and can be reproduced as I described using the code fragments provided. ***dan
  3. djl

    Lcd Plugin Enhancements

    I will check tonight if I have time - but I'm quite certain that it won't jump like the plugin does :-) If lcdgoto_xy(0,3); lprintf("T"); lcdgoto_xy(1,3); lprintf("e"); lcdgoto_xy(2,3); lprintf("s"); lcdgoto_xy(3,3); lprintf("t"); writes "Test" to the first four columns on the bottom row, then lcdgoto_xy(0,3); lprintf("Test"); should also write "Test" from locations 0,3 to 3,3 and it doesn't... BTW this works as expected (correctly) on the new plugin in 2x40 mode- which is logically identical to the 4x20 mode. ***dan
  4. djl

    Lcd Plugin Enhancements

    I should not that the easiest way to see this "bug" is to do lcdgoto_xy(0,3); lprintf("Print Anything"); The "Print" will be split between rows 3 and 0.
  5. djl

    Lcd Plugin Enhancements

    Not sure if you want feedback by email or here... In my testing, if I explicitly set the location that I want to write to, e.g. for (row = 0; row < 4; row++) for (col = 0; col < 20; col++) { lcdgoto_xy(col, row); lprintf("%1d", col); } Then the plugin works fine. However, if I rely on the auto-increment function of the LCD, e.g. for (row = 0; row < 4; row++) { lcdgoto_xy(0, row); for (col = 0; col < 20; col++) lprintf("%1d", col); } then it works fine for all of rows 1-3, and for the first column of row 4, but when I try to write to the second column of row 4 I write to row 1 column 0 instead, and then it autoincrements to 2,0 then 3,0 etc. So to be clear, the autoincrement jumps from 0,3 to 1,0 - when it should go from 0,3 to 1,3. ***dan
  6. djl

    Lcd Plugin Enhancements

    What is the memory map of the new 4x20 mode? In the display that I am using in my project (Truly MTC-C204DPLY-1N), line 1 is 0x0-0x13, line 3 is 0x14-0x27, line 2 is 0x40 - 0x53, and line four is 0x54-0x67. So logiclaly, lines 1 and 3 are the same line (0x0 - 0x27) and lines 2 and 4 are the same line (0x40 - 0x67). I have modified lcd_driver.h to support that map, but that doesn't appear to be the map that this plugin uses (based on my initial tests :-) ***dan
  7. It would be very nice if we could have better error messages from the compiler. Some examples: Main(){} Foo(bar){} Error is: test.c(3) missing right paren Should be something about the fact that the argument is missing a type declaration #include <system.h> Foo(int bar) { volatile bit b@TRISA.Bar; // <-- Note typo, B instead of b } Error is: test.c(3) missing semicolon Should be something about undefined variable or constant #include <system.h> Foo(int bar) { volatile bit b@TRISA.Bar; // <-- Note typo, B instead of b for (;;){} while(){} } Error is: test.c(5) missing semicolon No only is the message useless, but the reported line # is wrong (5 not 3) int Foo() { return(); } Error is: test.c (3) missing semicolon Contrast this to the excellent, clear, descriptive error message that you get if you try to return a value from a function that is declared void: void Foo() { return(1); } test.c(3:2) warning: function 'Foo' has return type 'void' and cannot return any value, expression ignored As I come across other examples, I will post them as replies here.
  8. 1) Support negative buttons (buttons that ground the input pin when depressed) 2) Document the fact that the current buttons are positive buttons (buttons that are logical high when depressed) 3) Support multiple single buttons active at the same time. Currently, you can only display one single button plugin at a time. The button plugin is either on, or off. I need to support multiple buttons, but they are on different ports, so I can't use the button block. For that matter, the button block should also support multiple instances. 4) For the button block, allow different physical organizations of the 8 buttons. This is hard (need a WSIWYG button layout tool), and probably not worth it right now, but would be great. 5) For the button block, allow the display of less than all 8 buttons. I only use 3, and don't want to take up screen space with the others.
  9. 1) Add support for 4x20 display. Logically, these are identical to the 2x40 display, so we just need to display the output in 4 lines, rather than in 2. 2) Allow for a physically smaller display of the LCD on the screen. Current size won't show all 40 columns of a 2x40 display on a 1280x1024 screen. Adding a mode that is 50-75% the size of the current one would allow that.
  10. I don't understand this, which probably isn't surprising since I just started using PIC's :-) I disassemble my .hex file generated with BoostC, and I see: org 0 goto Main At the very beginning. Good, this is what Tinybld wants. I assume from hollie's comment above that if my Main() wasn't in bank zero, then the compiler would insert the necessary bank change instructions (to set PCLATH e.g.). So if Tinybld executed the first four instructions that the compiler generated and Main() wasn't in bank zero, then the first four instructions would include the PCLATH mod and everything works fine. But, given that Tinybld is loaded high, and that it includes goto's in that high bank, I assume that PCLATH gets set to point at the high bank while Tinybld is running. So if the compiler doesn't fix this (e.g. the first instruction at ORG 0 is just Goto Main), why does Tinybld ever work? To put it differently, it seems to me that Tinybld should either always work (because it doesn't mess with PCLATH, and so as long as the compiler does the right thing in the first four instructions including bank instructions if necessary it works), or it should never work if Main() is in bank zero (because Tinybld always jumps within the high bank, which points PCLATH at the high bank, and the compiler can't know that and so doesn't zero out PCLATH but rather just short jumps assuming it is in bank zero). I hope this makes some sense, it is a bit late at night for me :-)
  11. I completely realize that what I am about to say may be annoying, flame proof suit on. I should say that I love BoostC, and am very impressed with it. In addition, I wrote my last C language parser in 1984 - so what the heck do I know? While BoostC appears to be an excellent compiler, I have to say that the error messages leave some room for improvement. In particular, the "missing semi-colon" error can be generated by several incorrect conditions, and is frequently reported at locations quite distant from the actual error. While it may well be that the BoostC parser doesn't handle syntax errors in a way that allows more precise messages - I'd love to see a bit more work go into helping those of us who make "stupid" mistakes like this one find and correct our errors quickly.
  12. Right. Excellent. Got it. Now, both of the proposed solutions require that all the chip select pins be on the same port. For bonus points, is there a solution that doesn't require that?
  13. I apologize for the beginner's question, but the doc isn't at all clear on this. I have a set of SPI routines that must manipulate a chip select pin. The distributed set of SPI routines assume a single chip select pin, called spi_cs, which is hard mapped to a single pin by being declared as a global bit@PORTC.2 . I need to pass to my spi_write routine some indication of which chip select pin to manipulate from the several possibilities. How do I do this? The only way that I can see to do it is extremely clunky - define all the various chip select pins as globals mapped to the correct PORT.PIN, then pass an enum into the various routines that use CS and use case statements inside those routines that duplicate the code for each possible CS pin. Yuck - there must be a better way... I tried passing in two uchars (one for port, one for pin) and then declaring a local volatile bit @port.pin, but that doesn't work. I assume that you can only declare a local mapped to a constant PORT and a constant PIN. I also tried declaring an argument as a volatile bit and passing in the mapped bit directly, but that also failed. Thanks in advance for the help!
×