Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Steve_DeGroof

  • Rank

Contact Methods

  • AIM
  • ICQ
  1. I've seen this error before. Seems to be a problem with the ! operator having precedence over function calls. Strictly speaking, the "on_wake_up()" function call should have precedence over the ! operator but it doesn't seem to work in this case. You can work around it by enclosing the function call in parentheses. Try changing this: while ( !on_wake_up() ) ...to this: while ( !(on_wake_up()) )
  2. I've run into this problem before with a unary operator on a function call. This was over a year ago, so it may be that what you're getting is completely unrelated but here's what I found. I was trying to do a 'while' loop with a function call in the condition. I found that, if I put a '!' operator in front of the function name, I got an error. I eventually figured out that the unary operator was being given higher operator precedence than the function call. The easiest workaround I came up with was to put parentheses around the function call. For example: while (!txBufferIsReady()) //this gives "unexpected unar operation" while (!(txBufferIsReady())) //this compiles Like I said, though, this was over a year ago and the compiler has changed a lot since then. I haven't tried this with the latest version.
  3. Ya, I figured it was a scope issue. Easy enough to avoid by declaring your variables up front. Is it safe to assume that this sort of thing would happen with any conditional or loop (for/while) statement? If so, it might be handy if the compiler threw an error when it encounters something like this.
  4. I recently ran across an oddity in the compiler. It appears that, under certain conditions, a function call will move to the beginning of the function containing it. The following example is the simplest code I could find that produces the behavior. In this case, the call to function c() is moved to the beginning of function d() during compile. #include <system.h> int c() { return 2; } int d(int e) { if(e==1) { int b = c(); } } void main (void) { int a = d(4); } Here's the compiled d() function. The first line is "call _c". So, instead of c() being called only when e is 1, it's called unconditionally. ;;;;;;;;int d(int e) _d__code call _c bcf PCLATH, 3 bcf PCLATH, 4 movwf _code_tmp_0001 movf __ret__hibyte, W movwf _code_tmp_0000 movf _code_tmp_0001 , W movwf _b_d movf _code_tmp_0000 , W movwf _b_d+D'1' ;;;;;;;;{ ;;;;;;;; if(e==1) movlw D'0' subwf param00_d+1, W btfss STATUS, Z goto label_0000 movlw D'1' subwf param00_d, W btfss STATUS, Z goto label_0000 ;;;;;;;; { ;;;;;;;; int b = c(); ;;;;;;;; } ;;;;;;;;} label_0000 return _d__end The key to the problem seems to be declaring a variable within a conditional statement. If I declare b at the beginning of d(), though, the resulting assembly code is correct. int d(int e) { int b; if(e==1) { b = c(); } } Here's the new version of the compiled d() function. The "call _c" line is now where it should be. ;;;;;;;;int d(int e) _d__code ;;;;;;;;{ ;;;;;;;; int b; ;;;;;;;; if(e==1) movlw D'0' subwf param00_d+1, W btfss STATUS, Z goto label_0000 movlw D'1' subwf param00_d, W btfss STATUS, Z goto label_0000 ;;;;;;;; { ;;;;;;;; b = c(); call _c bcf PCLATH, 3 bcf PCLATH, 4 movwf _code_tmp_0001 movf __ret__hibyte, W movwf _code_tmp_0000 movf _code_tmp_0001 , W movwf _b_d movf _code_tmp_0000 , W movwf _b_d+D'1' ;;;;;;;; } ;;;;;;;;} label_0000 return _d__end So, there's a relatively easy workaround. I'm not really interested in submitting a bug report, since I'm using an older version (4.6.3e) of the compiler. I would be interested in knowing if this compiles differently with version 5, though.
  5. It's the cluster chaining. Each time you reach the end of a cluster, you have to find an empty cluster and chain the current one to the new one. In theory, that's just a matter of writing a couple of bytes to disk but, to do that, you need to read an entire sector into a buffer, modify the data and write it back out again. The way I'm doing it probably isn't very efficient, either.
  6. Another update. 1. Fixed write-to-file. Appears to be working for create and append. 2. You now have to define "cfWrite" in order to use the write functions. 3. Added cfWriteStringToFile and cfWriteHexToFile. 4. Added cfWriteTest.c - opens a file and writes a bunch of text. (later) Just uploaded more changes. Sped up the write-to-file code. Now averages about 3000 bytes per second. Still pretty slow but a lot better than it was.
  7. That's seriously cool. A tcp server built into an RJ45 connector. I see they also have a WiFi version. Looks like they've got some sort of promo going on at the moment where you can win a free development kit. I might have to enter. You need to submit a description of your project, though. I'll have to think up something that sounds plausible.
  8. Good point. If I buy v5 now, I'll just have to pay again for v6.
  9. Since the destination is an exact copy of the source, the serial number would be in the same location (byte X of sector Y) on each card. Assuming each serial number file would be exactly the same length, you could just overwrite the corresponding sector with the new serial number data. Say, for example, that you've determined that the data for the serial number file is located on sector 22B and the file always contains exactly 20 ascii characters. Then, for each destination card, you'd set sector 22B and send a write sector command. The command would be followed by the 20 character serial number, plus 492 nulls (to pad to 512 bytes). You don't need to change the FAT or directory since the file location, length and date stamp haven't changed. How about USB? There's info on that here. It's Hi-Tech PICC but it should translate fairly easily.
  10. Hey, I'm still on 4.6. Can't seem to convince myself to pay $70 for the upgrade. Is the version 5 compiler that much better than version 4?
  11. I should probably mention that the write-to-file stuff doesn't work yet. Still working on that. If and when it does work, it'll need an external sector cache. I'm currently trying to get it to work with an FM25640 FRAM (an 8Kx8 serial ferroelectric memory). I've gotten as far as creating a new file and setting up the FAT entries but, for some reason, the actual file data isn't being written. As far as copying one CF to another goes, though, that should be fairly easy. Don't need to mess around with all that FAT stuff. You'd just need to walk through the entire card, sector-by-sector, reading bytes from one and writing to the other. Just have to use separate write enable and ready lines for the destination card. Wouldn't hurt to have a separate card detect line too. If you're low on I/O pins, you could use the same write enable for all destination cards and "and" all the ready lines together. That way, the controller would wait until the slowest card was ready before moving on.
  12. Up until today, I've been using v4.6. I just downloaded v5.51 and installed it. When I tried to compile, it indicated that my temporary key had expired. I'm guessing that it's using the original temp key from the older version. Since this is an entirely new version and there's an additional $70 fee to upgrade, I had assumed that there'd be a trial period. Is that not the case?
  13. I don't have a problem with logins but I have been having difficulty posting messages. So far, I've either been told I don't have privileges to post a message or I've been allowed to post but the message hasn't shown up.
  14. A few updates to my CompactFlash files: 1. Fixed a problem with rst/rdy. 2. Posted a schematic for a demo board. 3. Posted ExpressPCB files. The ExpressPCB design uses a CompactFlash adapter board from Cimarron
  • Create New...