Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About twomers

  • Rank
  • Birthday 04/15/1986

Profile Information

  • Gender
  • Location
  • Interests
    Learning new things. <br />Doing things that interest me.
  1. I don't think my suggestion deserves a thread by itself so I'll throw it in here, but there's a feature in CrimsonEditor (a text editor) that would be very convenient for SourceBoost. It enables typing the same text in multiple lines at once, so in a few words it's a long cursor. It would be very handy if you are defining variables with similar base names but different suffixes. See screen shot for what I mean... I'm defining integers called PortAInput# but all seven variables are being typed at the same time. Snapshots A, B, C and D are taken at different times during the typing. Sure you hav
  2. What does "write accelerometer" mean? Do you want to write code which will record the output of the accelerometer? The datasheet ( http://www.memsic.com/data/products/MXD2020E/MXD2020E.pdf ) says that it has two PWM (pulse width modulation) outputs, so what you've gotta lean to do is monitor these outputs. Simplest thing to do is first write code to monitor just one of the outputs and then get it to convert to g's via A(g)= (T1/T2 - 0.5)/0.2, where T1 is the length of the pulse, and T2 is the period of the pulse. Try to work something out and if you have problems post the problematic code.
  3. Yes. A way to overcome this would be to make a global flag and on the TMR0 interrupt event set that flag true. Within the infinite loop in main check the status of this flag. If it's 1, first set it to zero and then call the display function, i.e.: //... bool trm_0_overflowed = false; // ... void interrupt() { if ( intcon & T0IF ) { trm_0_overflowed = true; clear_bit( intcon, T0IF ); } } // ... void main() { //... while( true ) { if ( trm_0_overflowed ) { trm_0_overflowed = false; display(); } // ... } }
  4. Hmm. Just looking at your source now. Is the init function commented out in your final version? It probably shouldn't be - you're relying on the default IO configurations if you don't call that function. Also, the purpose of the interrupt shouldn't be to set variables and outputs but to flag to main that outputs can be set. And you almost certainly shouldn't have delay functions called within it, you should also check that the interrupt that's called was the one you're handling too, i.e. put something like // Create global timer0 if variable bool do_toif = false; void interrupt(void) { i
  5. I had a big long reply to the same effect, but FF crashed on me and I didn't have the heart to rewrite it. A simple way to flip the value on the pin is simply to XOR the value with 1. (0 XOR 1 = 1, 1 XOR 1 = 0). That should work, methinks. Also, I think you're inadvertently messing up your interrupt call frequency. When the interrupt function is called (when the timer overflows), the PIC must store in memory everything that it's playing with along with its position in code. Then it performs the interrupt function. Then recalls stuff to memory and returns to the code. A finite amount
  6. Also, another bug report, for the editor only, though: // packet.15 ^= packet.0; \ packet.15 ^= packet.1; \ packet.15 ^= packet.3; \ packet.15 ^= packet.7; \ That's all highlighted in green. The \ that one might use for #define preprocessor stuff has the same effect in comments. However errors are flagged when compiling.
  7. IDE stands for Integrated Development Environment. Which means it is a compiler, builder, AND editor. Not only the latter. twomers
  8. Hi there, I believe I've found a bug in SourceBoost. I am generating parity bits and obviously began debugging before downloading to a PIC. However, the parity bits that I calculated by hand did not compare with the ones that SourceBoost showed in the debugger. I am using preprocessor functions to do the parity generation but just for debugging these I made a regular function to monitor whether it was my calculations which were wrong. Anyway, here is a snap-shot of the dubugging process. On the right is the watch window where you can see the packet that I'm transmitting and the individual
  9. You setting the PEIE bit in the intcon register? (it's PEIE on the 876, the "Peripheral Interrupt Enable bit" in the interrupt register). That might have something to do with why it can overflow and not call the interrupt. The interrupt call may be as a result of other interrupts.
  10. Ah. I see. But remember pointers are always friendly: typedef struct _thing { unsigned char ch; } thing; void main( void ) { unsigned char *ptr; thing i_thing1, i_thing2; while( true ) { ptr = &i_thing1.ch; if ( ptr.0 ^ ptr.4 ) portb = 0; ptr = &i_thing2.ch; if ( ptr.0 ^ ptr.4 ) portb = 0; } } If feasible. The pointer assignment takes 5 or 6 clock cycles while the xoring takes a few. So it is probably feasible to do this, especially if pointing to the same variable for more than one comparison.
  11. Heh. I was just about to post solution! For me this now operates at 12 cycles (while the @ing is now 9 for some reason), so it reduces it by a deascent amount! Assuming the B value is greater than the A value is fine. That's not a restriction or anything. In fact this: if ( porta.PORTA_BIT_A ^ porta.PORTA_BIT_B ) { portb = 1; } Performs as well as the @ operator... I must have mis-read my code when I analysed it before: if ( ra1 ^ ra3 ) { 0018 3000 MOVLW 0x00 0019 1985 BTFSC main_1_ra3,3 001A 3001 MOVLW 0x01 001B 1885 BTFSC main_1_ra1,1 001C 3A01 XORLW 0x01 001D 3
  12. Thanks for your reply, Orin. I'll try that out later on and report back during the weekend. When you say "You might be better off doing" does that mean that what I proposed can be done? Or that your alternative should be as efficient? I know you probably don't believe me but really anything that can be saved is best! Actually, I'll test it now. Hmm. This is the code that I used. #define PORTA_BIT_A 1 #define PORTA_BIT_B 3 void main( void ) { // Config timer in option reg clear_bit( option_reg, T0CS ); clear_bit( option_reg, T0SE ); // Set up interrupt control set_bit( int
  13. Yeah... Out of curiosity I was just checking the overhead in my interrupt function. It takes 16 ticks of my tmr0 and 13 ticks respectively to go in to and out from my interrupt function. Ideally this should be as small as possible, of course. Altogether my interrupt function takes 45 ticks, leaving about 200 until it's called again. There any tricks to reduce this overhead? inline it (kidding, of course!)
  14. Hi, Just a quick question there. I know you can map variables to registers like this: volatile bit RA1 @ PORTA.1; But what I was wondering is if there's a way to do this for general variables: unsigned char shift_reg; volatile bit shift_reg0 @ shift_reg.0; volatile bit shift_reg1 @ shift_reg.3; I suppose what I'm really asking is if this (if it worked): something = shift_reg0^shift_reg1; is more efficient than doing something like: something = test_bit(shift_reg,0)^test_bit(shift_reg,1); or something = shift_reg.0^shift_reg.1;
  15. >> could someone please explain in a bit of detail about what each of these are and what the values represent? The detail is in the datasheet so I'll refer you to specific pages of it (I'm going to go on the PIC16F876 cause I've used that with RS232, datasheet), and have the PIC16F876.h header file in Source Boost's include directory open. //#define TX_PORT 0x07 //#define RX_PORT 0x07 TX: This is the port out of which serial data will be transmitted. Look in the header file for PORTC. It's #defined as 0x07. If you wanted the output to be on a different port you can set it here b
  • Create New...