Jump to content

Ian Harris

EstablishedMember
  • Content Count

    87
  • Joined

  • Last visited

Everything posted by Ian Harris

  1. Hey sdujolo, Nice discovery, I haven't seen that but I'll certainly give it a try. It would be nice for a logging application to be able to write directly to an SD card. Anyone else playing with this? cheers Ian.
  2. I've made available the first release candidate for the new version of the PicPack library for the SourceBoost compiler. It has native, non-Microchip stack support for USB pics, including examples of a mouse and a USB serial port. These are based on the 18f4550, and I've been using the TechToys prototype board. It needs some tidying up, documenting and no doubt, bug fixes, but I wanted to make it available to the adventurous to have a play with and give me some feedback - much appreciated guys. Final version will be out shortly, along with USB tutorials, etc. Enjoy. http://embeddedadventures.blogspot.com
  3. I've made available the first release candidate for the new version of the PicPack library for the SourceBoost compiler. It has native, non-Microchip stack support for USB pics, including examples of a mouse and a USB serial port. These are based on the 18f4550, and I've been using the TechToys prototype board. It needs some tidying up, documenting and no doubt, bug fixes, but I wanted to make it available to the adventurous to have a play with and give me some feedback - much appreciated guys. Final version will be out shortly, along with USB tutorials, etc. Enjoy. http://embeddedadventures.blogspot.com PS - Thanks RSABear, will get back to you today.
  4. if (test_bit(usb_sdp.bmRequestType, DATA_STAGE_DIR)) { // ***IF <1> *** //serial_print_str(" D:IN "); } else { //serial_print_str(" D:OUT/NO "); } if (!test_bit(usb_sdp.bmRequestType, REQUEST_TYPE1) && // std request ***IF <2>*** !test_bit(usb_sdp.bmRequestType, REQUEST_TYPE0)) { generates this assembly: BTFSS gbl_usb_sdp,7, 1 --- from IF 1 BTFSC gbl_usb_sdp,6, 1 --- from IF 2 BRA label71 BTFSC gbl_usb_sdp,5, 1 BRA label71 MOVLW 0x1F ANDWF gbl_usb_sdp, W, 1 Notice how the first BTFSS (could) result in the BTFSC never being called - so the "std request" if statement never executes correctly. So sometimes the statement will test correctly, sometimes it won't. This one turned up when I started to comment out serial port debug (as you can see above) so I started thinking it was some sort of USB timing problem. Turns out to be a bug in the compiler. :-) I'm using 6.87 kind regards Ian.
  5. Sweet! I'd love some help. I've just got the CDC class working - and seeing a character pop up on screamer that you've typed on another computer in a terminal connected via usb is very exciting. There's a few bits that need work, so if I can package it up for you later today, just drop me an email on imharris at gmail.com for where to send it to you. cheers Ian.
  6. Hi Danny, What you're seeing is the classic read-before-write problem. The only way reliably around it is to cache the writes before actually changing the port - and only the changing the port with a byte-wide write (no rhyming intended) Here are the routines that come from the pic_utils.h in the PicPack library (see Embedded Adventures) #define set_pin(port, pin) \ set_bit(port_shadow[port - PORTA], pin); \ port_array[port - PORTA] = port_shadow[port - PORTA]; #define clear_pin(port, pin) \ clear_bit(port_shadow[port - PORTA], pin); \ port_array[port - PORTA] = port_shadow[port - PORTA]; #define toggle_pin(port, pin) \ port_shadow[port - PORTA] ^= (1 << (pin)); \ port_array[port - PORTA] = port_shadow[port - PORTA]; #define test_pin(port, pin) \ ((port_array[port - PORTA] & (1 << pin)) != 0) #define change_pin(port, pin, value) \ if (value) { \ set_pin(port, pin); \ } else { \ clear_pin(port, pin); \ } Fundamentally, the way these devices work is that they can only write to a port a complete byte at a time. So what happens if you only want to change one bit (a single pin)? Well, the device reads the value on all the pins in the port, then changes the pin (bit) you care about, then writes it all back to the port. Fine, except when as previous posters have mentioned, the current value on the port doesn't reflect the value that you last wrote to it! The only way around this is to "shadow" all your writes, so that your code remembers what was previously written to the port. 18f devices have a LAT (latch) register for each port that does this in hardware, however, the shadow register method is safe on 18f devices as well, although it uses slightly more code than just writing to the LAT registers directly. The routines above allow you to do things like: set_pint(PORTA, 1); (note the PORTA is in captials due to the way the array is set up). This results in the fewest lines of assembler in order to use a shadow: 05A4 884A BSF gbl_port_shadow+D'1',4 05A6 504A MOVF gbl_port_shadow+D'1', W 05A8 6E81 MOVWF gbl_port_array+D'1' This is on a 18f device, but in either case, it's three instructions and saves you from the craziness of the chip seeming to do, well, crazy things. I've seen read-before-write issues on just led+resistor on the output, let along when the pins are tied to some other device. I use this method on everything and cringe when I see code that's simply porta.1 = 0; since who knows what other pins you've just changed at that point? lata.1 = 0; is however, perfectly safe on 18f devices. cheers Ian.
  7. How much does it cost or is it free ? Regards Raghunathan. Have a look at Embedded Adventures - it's freeer than your average free thing. cheers Ian.
  8. I'm working on such a thing for the SourceBoost PicPack library...coming very soon. :-) cheers Ian.
  9. Hi David, Yes, you're right about that bug, and I really appreciate your feedback. The next release will have that fixed along with a stack more serial port values for all different sorts of speeds. The main delay in getting the next release out has been adding a new library for native USB support, an easy to use framework built from the ground up. kind regards Ian.
  10. For a version of bloader / screamer (now BoostBloader and Screamer) that compiles under BoostC, handles moving the bootvector to high RAM (so works on 16f88 > 2k RAM) and works on a bunch of chips including 18f chips for when you get to them, have a look at Embedded Adventures along with a bunch of BoostC libraries. In fact, this project all started because I couldn't get the bloader code to work in > 2k flash. regards Ian.
  11. Hi Shrivardhan, BoostC is a great product, has a friendly community, and the authors respond right here on the forum - it doesn't get much better than that. For some fun tutorials on getting started in BoostC see Embedded Adventures. kind regards Ian.
  12. Hi learner, If you want to use software PWM, check out the PicPack library, which includes PWM support at EmbeddedAdventures. regards Ian.
  13. Hi, Have a look at EmbeddedAdventures where I've put some tutorials and code, including the use of LCD displays. BoostC also comes with an LCD library. If you're new to microcontrollers generally, you'll need to start from the beginning - learning how to program them and get a led flashing, then getting user input, then displaying things on an LCD. regards Ian.
  14. Hi all, Version 1.2 has now been released. Updated meshed RF network packet delivery code, support for DS1307 over I2C. Almost 9Mb of code, documentation and examples. BoostBloader/Screamer support for these pics: 16f88, 16f876a, 16f877a, 18f252, 18f452, 18f2620, and 18f4520. It should be quite easy to add other pics as well, I'll write a tutorial about doing that shortly. Many thanks to Peter Lawson in sunny South Australia who helped tirelessly getting the BoostBloader running on a new class of Pic chips. See embeddedadventures.blogspot.com regards Ian.
  15. Hey Richard, that's really neat. Well done and thanks for sharing. regards Ian.
  16. I'm not sure why you'd do (1) - if you're not using interrupts, why worry? As it happens I always use a dummy interrupt() routine in code (even if I'm not using interrupts) to force BoostC not to put actual code in the interrupt location and put a goto at 0x0000. This allows for easy bootloading. I don't have a problem with (2) - but I would prefer to be able to ORG each individual subroutine - that way a single ORG at the beginning would have the effect of pushing everything up if you wanted to, but you could "place" particular routines at different places in memory. Same result but less confusing. Making your own gotos is indeed a pain - but mostly because the BoostC compiler doesn't support using ASM goto 0x0000 address - you can only goto to labels for some reason. Means you have to end up hand assembling things into ASM DATA statements (not fun). For more bootloading magic, see embeddedadventures.blogspot.com regards Ian.
  17. I presume these are the "34"s that your talking about - keep in mind that these pics don't have an 8 bit wide (or 16 bit wide) flash memory - it's 14 bits. The '34' part is the opcode that makes up the return, the least significant 8 bits are the return value. So, you're actually only using 1 "word" of the flash memory for that value. The 12f683 has 2048 words of flash, each word being 14 bits wide. regards Ian.
  18. .obj file recompile When there's a .obj that exists for a given .c file, if the .obj is for the wrong target, just recomile the .c instead of aborting. Global variables It would be great for the Code panel to show where exactly the global variables are coming from - even just narrowing it down to a .c file would be a great help. Startup Compiler generates a goto _startup, which then does a goto main. All fine except when you compile with -Su so you don't initialise global variables, or there are no global variables, in which case the first goto should just be goto main. Hey, every byte counts :-) Routine locations It's really handy in other compilers to be able to do something like #pragma org 0x6500 void my_routine() { } To be able to place subroutines at particular locations in memory. Interrupt already does this implicitly. It would greatly simplify some problems and aleviate having to hand-code using #pragma data, which is the only other way to get code to sit at particular locations. asm goto doesn't seem to work. Had to use asm data. Compiling Sometimes the compiler exits with error code 1 when you build, says its successful, but then doesn't link. You have to do a proper "compile" then "link" and it works fine, no code changes. Must be some problem examining .obj files perhaps? Doesn't happen all the time, just some times. Compile then link always fixes it. Target directories You can use -d dir_name on the linker command line - previously this would actually create the directory if it's not there, and even dump everything in it. In 6.87, this crashes the linker. In either case, the problem is really that the ide says the build has failed because it can't find the .hex file in the project directory when it should really be looking in the -d directory. Access params from code It would be really, really handy if the command line parameters such as -rb were available in code, eg, #pragma PARAM_RB 32230 kind regards Ian.
  19. Hi guys, It would be great to be able to reference ROM subroutines. This would mean you could load a "bootloader" that could access LCD, etc, and programs you bootload into the chip could use those same routines without having to duplicate code. Something like this: #pragma EXPORT void lcd_print(char *string) { etc } This would result in an extra output file that contains information about the location of variables used within the routine, parameters etc. This file could then be included in a project instead of a .lib file. When the new "library" is included in a new program, the compiler/linker would reserve the used memory locations (if the program calls the routine) for params and local variables. regards Ian.
  20. Thanks Dave / Pavel, the new version fixes the problem. Thanks for the quick turnaround. regards Ian.
  21. Thanks Dave / Pavel, the new version fixes the problem. Thanks for the quick turnaround. regards Ian.
  22. Does your code use the following ?: #pragma DATA, 0x000, xxxx If so this is a known problem, and fix soon to be released. If not we need more information and some example code that fails. Regards Dave Sure does: #pragma DATA 0x000, 0x158A // BSF PCLATH, 3 #pragma DATA 0x001, 0x160A // BSF PCLATH, 4 #pragma DATA 0x002, 0x2ebc // Goto bloaderstart While I've got you, what's the magic to using the pre/post build scripts? I can't find any documenation on it... cheers Ian.
  23. Just installed 6.86. Reports popup box: Error: Access violation at 0x0044E79A (tried to read from 0x00000010), program terminated. Compiler reports: Building... BoostC Optimizing C Compiler Version 6.86 (for PIC18 architecture) http://www.sourceboost.com Copyright© 2004-2008 Pavel Baranov Copyright© 2004-2008 David Hobday Licensed to Ian Harris under Single user Pro License for 1 node(s) Limitations: PIC18 max code size:Unlimited, max RAM banks:Unlimited ..\BoostBloader.c C:\pic\boostbloader\chipdefs.h(124): WARNING: Compiling for PIC18F452 C:\pic\boostbloader\chipdefs.h(133): WARNING: Did you set -rb 32232 in Settings | Options | Linker? success BoostLink Optimizing Linker Version 6.86 http://www.sourceboost.com Copyright© 2004-2008 Pavel Baranov Copyright© 2004-2008 David Hobday "C:\Program Files\SourceBoost\boostc.pic18.exe" ..\BoostBloader.c -t PIC18F452 -Su -Oa -I "..\..\pic_pack_lib" "C:\Program Files\SourceBoost\boostlink.pic.exe" /ld "C:\Program Files\SourceBoost\lib" libc.pic18.lib BoostBloader.obj /t PIC18F452 /d C:\pic\boostbloader\18f452 /p boostbloader_18f452 -rb 32232 Exit code was -1073741819. Removing target: boostbloader_18f452.hex Failed to locate output file 'C:\pic\boostbloader\18f452\boostbloader_18f452.hex' Done Failed regards Ian.
  24. You absolutely have to write on the correct boundaries - the datasheet is quite specific about this, by saying that only the upper bits of the memory address are used. Note that on some Pics the erase chunks and write chunks are not necessarily the same - and this varies from Pic to Pic! Have a look at the PicPack library, which includes a bootloader, at embeddedadventures.blogspot.com Enjoy. Ian.
  25. Hi Jorgen, It's all updated now. The screamer chip selection is unimportant - the BoostBloader knows how to adjust things itself, so you don't have to get it right every time you select a new chip. The only thing that matters is the clock speed - but I might let the BoostBloader know about that too, meaning you just choose your serial port and away you go. Which chip are you trying it with? The updated library (version 1.1) with extra bonus documentation is available at embeddedadventures.blogspot.com All feedback very welcome. regards Ian.
×
×
  • Create New...