Jump to content

Ian Harris

  • Posts

  • Joined

  • Last visited

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Location
    London, UK

Recent Profile Visitors

1,246 profile views

Ian Harris's Achievements


Regular (2/6)



  1. How about multiplying by 100, rounding that result, then dividing by 100?
  2. Very happy to play with a beta stack. - Ian.
  3. Jorge, Good find. I removed the files one by one until I found which one made it crash. I was fooled since I didn't think SourceBoost looked in the source files as it started, but it must do to read the "todo" list. volatile unsigned long ulSmartConfigFinished, ulCC3000Connected,ulCC3000DHCP, OkToDoShutDown, ulCC3000DHCP_configured; and OkToDoShutDown = 1; were the lines in the source files to cause the IDE to crash on startup. Changing them to "OkToShutDown" allows the IDE to startup okay. cheers Ian.
  4. Hi all, Running 7.11 and it has an annoying habit of crashing on loading certain project files - even one I have just created. Once it does this, of course, then next time it starts up it tries to reload the project and crash again. Here's a project file that crashes every time. Tried uploading but the forum says I'm not allowed to upload that sort of file. [settings] Target=PIC18F26K22 Active Compiler=BoostC Active Directory=D:\TI\CC3000BasicWiFiApplication\Basic WiFi App Sourceboost Source\ Active Config=Debug Last Ext=h Type=0 Warnings=2 Model=0 [Files] Count=24 File0=CC3000HostDriver\cc3000_common.c File1=CC3000HostDriver\cc3000_common.h File2=CC3000HostDriver\evnt_handler.c File3=CC3000HostDriver\evnt_handler.h File4=CC3000HostDriver\hci.c File5=CC3000HostDriver\hci.h File6=CC3000HostDriver\host_driver_version.h File7=CC3000HostDriver\netapp.c File8=CC3000HostDriver\netapp.h File9=CC3000HostDriver\nvmem.c File10=CC3000HostDriver\nvmem.h File11=CC3000HostDriver\security.c File12=CC3000HostDriver\security.h File13=CC3000HostDriver\socket.c File14=CC3000HostDriver\socket.h File15=CC3000HostDriver\wlan.c File16=CC3000HostDriver\wlan.h File17=application_version.h File18=basic_wifi_application.c File19=board.c File20=board.h File21=spi\spi.c File22=spi\spi.h File23=spi\spi_version.h [Tools] BoostDir=C:\Program Files (x86)\SourceBoost\ Programmer= PrefixWithBuildThreadNum=1 BuildThreadNum=1 [Debugger] DebugFromMain=1
  5. Hi Jorge, The PIC18F8X20 range of devices do have an external memory interface - but they only run at 10MIPS, which is not quite enough for our applications.</p> It's the RAM that's really the problem, I would swap half the flash for more than 4k of RAM. Still, getting more than 16MIPS of performance would certainly help too. cheers Ian
  6. So having finally got to the point now where we need to do projects with the PIC32 (actually, the problem is RAM, not processing power, but you might as well make the step to 32 bits) and start the process of porting things to the Microchip compilers. It reminds me what a joy it is to work in the clean, straightforward world of Sourceboost. Let's ignore the fact that MPLAB is extremely unfriendly and confusing, or the fact that you can easily (accidentally) spend ages reading help files only to realise that the help is for the HITECH C compiler and not the C18 compiler (or the XC8 compiler, which appears to be HITECH, full of bugs, and also an incompatible syntax with C18!) Try and find out how much memory (flash and ram) a given function uses in MPLAB. Go on. I dare you. It does appear to use less flash - a sample program I tried used considerably less flash but three times as much ram,. but then I'm just beginning on this journey. My first guess from looking at why is that C18 clumps all the ram constant assignments such as strings into flash, and then zaps them all into ram using table reads at the start of the program - meaning that it uses all that ram from the start, but uses less flash since this is a more efficient way of storing data than SourceBoost's equivalent: serial_print_str("x: print my_var=0x"); 03B8 0E20 MOVLW 0x20 03BA 6E37 MOVWF CompTempVar728+D'2' 03BC 6E3D MOVWF CompTempVar728+D'8' 03BE 0E30 MOVLW 0x30 03C0 6E45 MOVWF CompTempVar728+D'16' 03C2 0E3A MOVLW 0x3A 03C4 6E36 MOVWF CompTempVar728+D'1' 03C6 0E3D MOVLW 0x3D 03C8 6E44 MOVWF CompTempVar728+D'15' 03CA 0E5F MOVLW 0x5F 03CC 6E40 MOVWF CompTempVar728+D'11' 03CE 0E61 MOVLW 0x61 03D0 6E42 MOVWF CompTempVar728+D'13' ...which happens at run time, when it's needed. Uses more flash, but saves on ram. Still. It would be so nice if we had a PIC32 version of Sourceboost.
  7. Prompted by a comment made by Dave Jones on the EEVBlog we are looking at producing an "Arduino" compatible hardware platform based on a PIC microcontroller (and sourceboost, naturally). I confess to not knowing a great deal about this platform other than the fact that it's everywhere, and it is based on AVRs. This would allow BoostC / Microchip users to play with the same "shields" (daughter boards) that are prevalent in the Arduino community while maintaining your existing code base and development environment. There may even be some interest in porting the "sketch" platform as well. At first glance it looks like BoostC would be ideal for this environment due to the sketch's C/C++ ambiguity. I'm not sure about the value of being able to use Arduino-style Wiring sketches that are already out there - is there a lot of code floating around? What would be the point of merely substituting one chip for another, along with a reasonable software effort, if all you get is what Arduino provides right now? At the very least, having a PIC based board that takes shields, and you can plug into USB and start programming quickly has got to be a good thing. I'm in the middle of updating and moving tutorials on the PicPack library across to the new web site at Embedded Adventures and the next one is getting stuff working on real hardware. And I'm thinking, what hardware do I recommend? There's a gazillion PIC platforms of course, or even breadboarding. There's even a gazillion different models of PIC. Where Arduino really ads value, I feel, is in its "one-ness". That is, there's one Arduino (give or take). You get the hardware, you plug it in, you load up a sketch, and within about 30 seconds you're writing programs that flash leds. Then you start adding shields, building on your platform. It's a good story. Presuming there's some interest, I'm happy to develop the hardware platform. The PicPack library gives you a lot of stuff to get going and some simple additions to be more like Arduino/Wiring would be straightforward - the nice thing about the Arduino software is it hides a lot of the stuff you need to sort out with the hardware to get going with (notice the "pin 13" in the example below). This has got to be a good thing for beginners until they decide they need the control of doing everything by hand. Any thoughts? Any key aspects of the Arduino platform I'm missing here? Of course, we could take this in a completely different direction from Wiring etc, but I think the emphasis should be on making it easy for beginners to get started, with an easy slope to add more complexity when users are ready for it. The classic Arduino/Wiring example: /* Blink Turns on an LED on for one second, then off for one second, repeatedly. The circuit: * LED connected from digital pin 13 to ground. * Note: On most Arduino boards, there is already an LED on the board connected to pin 13, so you don't need any extra components for this example. Created 1 June 2005 By David Cuartielles http://arduino.cc/en/Tutorial/Blink based on an orginal by H. Barragan for the Wiring i/o board This example code is in the public domain. */ int ledPin = 13; // LED connected to digital pin 13 // The setup() method runs once, when the sketch starts void setup() { // initialize the digital pin as an output: pinMode(ledPin, OUTPUT); } // the loop() method runs over and over again, // as long as the Arduino has power void loop() { digitalWrite(ledPin, HIGH); // set the LED on delay(1000); // wait for a second digitalWrite(ledPin, LOW); // set the LED off delay(1000); // wait for a second }
  • Create New...