Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About jsobell

  • Rank

Contact Methods

  • MSN
  • Website URL
  • ICQ

Profile Information

  • Location
    Melbourne, Australia
  1. That's almost correct On the PIC18 we can't use the latch to read the data (such as status bits), as it always reflects the last written value, so we still need to use the data register. All in all, we need to specify three ports in the setup, which is what the code I'm emailing you does. It's annoying to have to change the configuration options and add a parameter, creating a minor break in backwards compatability, but there has to be a way to specify separate data read port and data write ports. Cheers, Jason
  2. On which PIC chip? As I've already shown several times, this is PIC16 only, and does not work on the PIC18 with it's latch register, hence why I emailed you version that worked on both. I get this strange feeling of deja-vu... Please see my posting from "Jul 5 2005, 02:42 PM" Cheers, Jason
  3. Not sure if you're still looking for a solution, but I did quite a lot of this stuff long ago... Optical encoders use slots with offset optical sensors so that the pulses to two pins are in different sequences depending on direction. e.g. Clockwise might be: A B 0 0 1 0 1 1 0 1 : Anticlockwise: A B 0 0 0 1 1 1 1 0 : The most obvious method of using one optical output (e.g. 'A') to trigger an interrupt and the other ('B') to detect direction does not work well in practice because if the sensor is at any speed then the direction can't be read in time and 'B' will already h
  4. There's still nothing changed in the provided source to address this issue, and given that it's fairly standard to use a single 8-bit port for LCD display control, perhaps it should be rectified in the SourceBoost supplied version? At the moment I have to replace the installed lcd_driver.h after every upgrade with my own to fix the bug. Cheers, Jason
  5. Hmm, I think this is a mute point, as the latter problems you describe are unsolvable on the PIC16, and is the reason the latch was introduced on the PIC18. Yes, I understand that, but Dave's response was to suggest simply replacing 'PortA' with 'LatA', but this does not work in the common scenario where the port is shared. I posted a very simple solution for this situation that works with PIC16s with separate control/data ports, and with PIC18s with either separate or combined. Hence we have a solution that is still target independant, but works in more situations than before. If
  6. I have a few suggestions with regards to usability: - Implement a keypress for switching between debug and edit mode without having to click a button on the toolbar. - Ability to have more than one instance of each plugin displayed at the same time. - Configuration options on plugins for high/low state. e.g. simulating a button that is normally high is not supported. - Provide a 'plugin' window into which the plugins are placed. Having them dock in the main editor window is messy, and the ability to minimise the plugin window when it's not is use would be nice. - Develop a plugin that
  7. Obviously, but this does not work if Data and Control are on the same port. The problem is in modifying the Data port in nibbles, where 'OR'ing in a new value will cause an internal Read/Write to set the new bits. When the Read is performed, it reads the control bits as being zero, despite the fact they are actually high. Therefore, you *must* use the latch or you must OR in the saved state of the control pins, otherwise they will be forced back to low. Target independence is only possible if you allow for the fact that PIC18s and PIC16s handle their ports differently. Check the Microchi
  8. It's been posted to the 'Bug Reports' section here, and seems to me to be a fundamental and serious bug (which is why an acknowledgement/confirmation/"no Jason, you're an idiot" response would be nice ) *Edit* Ah, the bug in the LCD code is that if you try and display an unsigned integer using %u then it is always displayed as signed (only without the '-' symbol). I wanted to display numbers >32768, so had to fix it. I'll email you the fixes instead of posting in here. */Edit* Cheers, Jason
  9. Also, the code shown is optimised out to say i = 0xFFFE If you code it in separate statements: unsigned int x1 = 0xffff; unsigned int x2 = 0xffff; unsigned int x3 = x1 + x2; then the carry flag will in fact be set correctly, but I certainly wouldn't put any dependency on it staying that way. Out of interest, how would you normally code to catch this? In most C implementations you could use a check against the result because you have Long datatypes, but what would you do in BoostC? Cheers, Jason
  10. You could set the new bit immediately after the shift if the carry is set, effectively doing a byte rotate. e.g. (and I've not tested this) RLF myreg,1 BNC noset BSF myreg,0 noset: Alternatively, check the bottom bit first, and set the carry flag so it gets shifted in correctly. Both would use a similar number of cycles. Alternatively, (and better still), use a PIC18 instead and you have the RRNCF and RLNCF functions that don't go via the carry flag. You must use two bytes. If the carry is set, you have an extra bit to set in the lowest bit of the next byte. The resul
  11. From what I can see in the spec sheet, the latch register gets around the 'high load' issue. When I run the ICD2 emulator, it does indeed read the pins as being low, even when they are actually high (and that's with a 1.5K resistor to the base of a transistor!), so the latch register is the only one with the current state shown correctly on the PIC18. I do remember the old 'store a copy of the register in RAM' issue on the PIC17 series, and I assume that's one reason the latch was introduced on the PIC18. Most posts regarding this from MicroChip state that the latch should be used instead
  12. When a char is cast to an integer, too many bytes are being copied, as shown in this example: char x=1; 05A8 0E01 MOVLW 0x01 05AA 6E0E MOVWF main_1_x int y; y = (int)x; 05AC 6E0F MOVWF main_1_y 05AE 500F MOVF main_1_x+D'1', W 05B0 6E10 MOVWF main_1_y+D'1' Location main_1_x+D'1' should obviously be set to zero when casting from and unsigned char, or 0xFF if from a signed char with the topmost bit set. This is quite a serious problem, as the current implementation may appear fine as long as mem+1 is empty (for unsigne
  13. Sorry, I should have marked them. Search for ReadDataPort, which is the variable/template option I added throughout. I also changed the suggested configuration options: //#define LCD_ARGS 2, /* Interface type: mode 0 = 8bit, 1 = 4bit(low nibble), 2 = 4bit(upper nibble) */ \ // 1, /* Use busy signal: 1 = use busy, 0 = use time delays */\ // LATD, PORTD, TRISD, /* Write Data port, Read Data port, and data port tris register */ \ // LATD, TRISD, /* Control port and control port tris register */ \ // 3,
  14. Well, after struggling for two days with bizzare issues with a simple LCD display, I finally found the problem. I'm not sure if this is common to all PICs, and it's been many years since I did any amount of PIC programming, but I had extreme problems interfacing to the display due to the way the template is coded for reading data back in 4bit mode. If you choose to use a single port to write to a display, it makes sense to set all of the ports to one port, in my case PortD. The problem arises that if you use a function such as: data |= d & 0xF0; then the existing value is read fro
  15. Hi, I'm struggling to work out how I can program my in-circuit PIC18 from the command line via the Olimex ICD2 compatible board. It works fine with MPLAB, but is there any info around on integration with SourceBoost IDE? Am I missing something in the RTFM department? Cheers, Jason
  • Create New...