Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by MORA99

  1. Since this board has been out for longer than the cc3200, maybe there is better hope for a network bootloader ?


    I found a few discussions on it, but not much to go on, maybe the board is not popular enough, or the ones that figured out how to do it dont share :)


    I would like to make the board boot info a bootloader area, preferably a energia sketch, which checks if thers a new firmware available and if so flashes it to the main program area before jumping there.

    Preferably the boot area would be protected, but even if not theres still the rom bootloader that would allow to recover over usb as far as I understand.


    I am looking for a ethernet arm chip to replace my old 8bit network controller, but without network update its not of much use.


    Any help/hints/pointers very welcome.

  2. So, time has gone by bugs have been fixed and I was trying the DHT code with my CC3200 and DHT11. 

    Energia Version 0101E0014 and I'm not able to get the sensor to work.


    It seems to work ok with the DHT11 if you change true to false.

    static int8_t readFloatData(unsigned char pin, float *temperature, float *humidity, boolean dht22);


    The true/false is to set if the sensor is a dht11 or dht22, so thats intended.

    The main difference is precision and the dht11 requires a bit more delay.

  3. The jumper is used in out of box example to force it to run access point mode.

    The pin is 3v3 compatible, but only if its used as a digital input, if you change to adc mode with the jumper installed it may damage the chip, a bit dangerous.

  4. Wonderful the new files works, so it would be better to make a buffer locally before transmitting it to the CC3200 ?

    I guess most small packages is due to not being able to just string the output together on the fly, like "str"+val, but sprintf can do that.


    Also tested ssl connect against a rapidssl cert, it connects and sends/recieves data and it fails if I try to ssl connect to a non ssl server, so I think its encrypted, hard to prove though :)

  5. This is a Websocket client library written mostly in highlevel c(++) to make it easyier to take in.


    It was tested on a CC3200 and earlier on a TM4C1294 but I think it should work on anything that provides the WifiClient/EthernetClient interface, and has decent amounts of RAM.


    Current code is a bit rough, it contains debug prints and I have not made much optimization work with it, especially concerning long strings where it just allocates up to 64kbyte of ram, but hopefully the user has some control over what is returned and can keep it short(ish).


    It does not support frames over 65kbyte nor binary data at the moment, but its not too hard to implement if needed.


    At the moment there is only 1 callback, when data is recieved, more callbacks could be added for connect, disconnect, ping, pong, etc.


    Well work in progress :)

    Like my dht lib the source code is maintained on github and my part of the code is released to public domain.

    The zip includes sha1 and base64 code that I didnt write, links to their home is included in top of WebSocketClient files.



  6. I am trying to do some fast bit bang in C to see what is possible without going to asm.


    But I havent had much luck in doing a simple on/off or toggle using bit manipulation instead of calling digitalWrite.


    My noble attempt didnt really do much.

      uint16_t pin;
      uint8_t port;
      uint8_t mask;
    void setup()
      pinMode(4, OUTPUT);
      pin = digital_pin_to_pin_num[4]; //PIN_03 GPIO_12
      port = digital_pin_to_port[4]; //S1
      mask = digital_pin_to_bit_mask[4]; //BV(4),		/*  4  - GPIO_12 */
    void loop()
      port ^= mask;

    I found digitalWrite in the sourcecode, and it calls MAP_GPIOPinWrite

    When then calls GPIOPinWrite or ROM_GPIOPinWrite

    Which then calls ASSERT and HWREG.


    So maybe I need to call HWREG to get as close to bit bang as possible ?


    By the way, I tested the digitalWrite function just to have a baseline, in a while(1) loop turning on and off the same pin, it gets 400ns pulses at 80MHz, so 32cycles if I did the math correctly.

  7. Sorry for derailing this, I am not that familiar with TI to realise which family cc3200 belongs to.


    It is probaly possible with SPI, a lesser wifi enabled device uses that to control ws2811, but you would be taking up a hardware SPI port, which is a pretty limited resource, maybe an analog switch could multiplex it.

    One could use a secondary 8bit mcu to offload the timing as long as fast updates are not needed.


    I see the adafruit avr code is assembler too, ofcause being ~16mhz theres fewer cycles to waste than at 80-120mhz, but 80mhz is still nowhere near enough to do it in c, I tried 2 inline asm sleeps with digitalWrite and its way off, maybe a direct bit manipulation could work, acording to the datasheet the leds dont really require perfect timing, theres +/-150ns on both high and low pulse, so +/-12cycles at 80mhz.

    • A library for reading dht sensors (temperature and humidity).
    • Since dht sensors are pretty slow, I have used highlevel functions in the lib, there should be plenty of cycles even at 1MHz, but I have only tested it on the CC3200 sofar.

    Easy example, other functions are available for getting the raw values instead of float.

      if (dht::readFloatData(2, &temperature, &humidity, true) == 0)
        Serial.print("T: ");
        Serial.print(" H: ");

    Zip file included, source code lives at https://github.com/MORA99/Stokerbot/tree/master/Libraries/dht


    Note: This lib requires working micros, delayMicroseconds and pulseIn functions, if you are using it on CC3200 you may need to patch your Energia installation.


  8. Jep, using something along the lines of that bugreport removes the wildly off readings.

    unsigned long k = 0;  
    void setup()
      Serial.begin(115200);      // initialize serial communication
    void loop()
      unsigned long c;
      unsigned long x = 0;
      for (uint16_t i=1; i!=0; i++)
        c = pulseIn(3, HIGH, 1000);
        if (c<16||c>24) x++;
        if (c<10||c>30) Serial.println(c);
              Serial.print("Loop ");Serial.print(k++);Serial.print(" => ");Serial.println(x);

    Output,each of those loops are about 65500 tests, so <10 errors is not bad, and none of them were outside +/-10us of the signal being read

    Loop 0 => 9
    Loop 1 => 7
    Loop 2 => 8
    Loop 3 => 1
    Loop 4 => 8
    Loop 5 => 8
    Loop 6 => 9
    Loop 7 => 1
    Loop 8 => 9
    Loop 9 => 7
    Loop 10 => 9
    Loop 11 => 1
    Loop 12 => 9
    Loop 13 => 8
    Loop 14 => 9
    Loop 15 => 7
    Loop 16 => 2
    Loop 17 => 9
    Loop 18 => 8
    Loop 19 => 9
    Loop 20 => 1
    Loop 21 => 9
    Loop 22 => 8
    Loop 23 => 9
    Loop 24 => 1
    Loop 25 => 9
    Loop 26 => 7
    Loop 27 => 9
    Loop 28 => 1
    Loop 29 => 9
    Loop 30 => 8
    Loop 31 => 9
    Loop 32 => 1
    Loop 33 => 8
    Loop 34 => 7
    Loop 35 => 9
    Loop 36 => 1
    Loop 37 => 9
    Loop 38 => 8
    Loop 39 => 8
    Loop 40 => 1
    Loop 41 => 9
    Loop 42 => 8
    Loop 43 => 9
    Loop 44 => 9
    Loop 45 => 1
    Loop 46 => 9
    Loop 47 => 7
    Loop 48 => 8
    Loop 49 => 1
    Loop 50 => 9

    +/-4us is a bit much, but I cant say how precise my 20$ logic tool is either :)

    Whats odd is theres a pattern to the number of off readings, first 3 loops with 7-9errors, then 1 with 1error, and repeat, but without better equipment I cant say if that error is on the cc3200 end or my tool end.


    Now we just energia to implement a fix in an official release.

    This is what I am using atm.

    unsigned long micros(void)
    	unsigned long ms, cycles;
    		ms = milliseconds;
    		cycles = SysTickValueGet();	
    	} while(ms != milliseconds); //If miliseconds changes while we read, we retry
    	return (ms * 1000) + (((F_CPU/1000)-cycles) / (F_CPU/1000000));

    And for delayMicroseconds I use this (have not tested the ~70min rollover yet)

    void delayMicroseconds(unsigned int us)
      unsigned long now = micros();
      unsigned long endTime = now + us;
        if (endTime < now) //overflow
        	while (micros() > endTime); //Wait for micros to overflow before normal condition below
        while (micros() <= endTime);
  9. The micros() that gompf suggested in the Energia issue (same issue I mentioned above) might help prevent totally off reading.

    unsigned long micros()
    register uint32_t ms, cycle_cnt;
    do {
    ms = sysTickUptime;
    cycle_cnt = SysTickValueGet();
    } while (ms != sysTickUptime);
    return (ms * 1000) + (80000 - cycle_cnt) / 80;

    Not sure what the purpose of the do while is, to me it will always run just once, since ms is set to sysTickUptime inside it ? unless sysTickUptime counts fast in a interrupt outside of this code.


    I havent been able to confirm it yet, but I think there is a potential for conflict in both versions, since SysTickValue decrements with 1 per cycle, I think that the ms interrupt wont fire and complete before thats over, so for a few clocks SysTickValue will be near 16million before being reset to 80000.

    And if we then say 80000 - 24bit in a 32bit unsigned variable you get around

  10. For my original needs a few us is plenty precise, I have about 30us difference between the 2 signals I need to differenciate, the one way off reading will just get scrapped in CRC, but in general the big one should be avoided somehow.


    With the original delayMicroseconds it does not get stuck with values larger than 1000, but you always get about 1ms sleep if you ask for more than 1000us.

    for (uint16_t i=0; i<16000; i+=250)
      digitalWrite(3, HIGH);
      digitalWrite(3, LOW);

    Capture attached, except for some variation at the start where i is less than 1000, all of them are 1ms.


    Every ms the tick gets reset to 80k, so if I ask for 5000us sleep at say 70k

    Then when the tick gets reset, its (~0-70000) - 80000 placed in an unsigned long and compared to us * ticks_per_us which will obviously be true, since the long will be near its highest value.


    We could call micros in the loop, but not sure if its too much overhead, or we could replicate the micros function in the delay one to get the correct sleep.



    [update] Just tested my dht reader using original pulseIn but with changed micros and it worked :)


  11. void loop()
    24bits in dec = 16 777 215, every 100ms I get roughly the same number, not sure what that says.
    79461, 79465, 79475, 79480, 79452, 79453, 79453, 79461, 79465

    So it seems sysTick are being reset to 80000 when crossing a milisecond (number of cycles in a ms) and then decrements.

    So a rough fix to micros

    return (milliseconds * 1000) + (((F_CPU/1000)-SysTickValueGet()) / (F_CPU/1000000));

    The timings are not perfect, maybe due to interrupts, but out of 10000 tests, I only had 1 totally off reading, the rest was within +/-5us, with about 90% of them being +/- 1us.

    void delayMicroseconds(unsigned int us)
    	volatile unsigned long elapsedTime;
    	unsigned long startTime = SysTickValueGet();
    		elapsedTime = startTime - SysTickValueGet();
    	} while(elapsedTime <= us * (F_CPU/1000000));

    Oddly enough this function seems to take into account that the systick value is decrementing.

    Since SysTickValueGet is being reset to 80000 on each ms, if the current counter is less than the delay time requested it will be inacurate.

    Reference says to use delay if delaying more than a few 1000us, and max is 16k, so its edge case to have it being too low.

      digitalWrite(3, HIGH);
      digitalWrite(3, LOW);

    gives 22-24us ticks, so looks good.


  • Create New...