Jump to content

MORA99

Members
  • Content Count

    42
  • Joined

  • Last visited


Reputation Activity

  1. Like
    MORA99 got a reaction from HarisAhmed in CC3200 bootloader   
    In order for this board to reach its full potential, it needs to be programmable in the field, very much preferably without a usb cable and a laptop at the location.
     
    From what I can gather the code for the chip is stored in the external SPI chip and when we flash new firmware, we are using the ftdi to send uart to the cc3200 which in turn writes the SPI.
     
    Is it possible to replace this bootloader with something that can load a new sketch/hex file over the network ?
    If not then the only remote programming possible would be a lesser language that is interpeted and any firmware upgrades would have to be done locally.
     
    I have a similar issue with the wired launchpad, it uses a seperate chip to do the programming, which does not have network access, but maybe one could store it somewhere and then reset the programming chip.
     
  2. Like
    MORA99 got a reaction from KittyHawk in [Energia Library] DHT11 / DHT22 Temperature and Humidity Sensors   
    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(temperature); Serial.print(" H: "); Serial.println(humidity); } 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.
    dht.zip
  3. Like
    MORA99 reacted to valerun in CC3200 bootloader   
    any indication of when that might happen?
     
    Thx!
  4. Like
    MORA99 got a reaction from bluehash in [Energia Library] WebSocketClient   
    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.
    WebSocketClient.zip

  5. Like
    MORA99 reacted to spirilis in CC3200 Wifi delay issue   
    almost forgot to add, too, the new .sslConnect() option for WiFiClient.
    It does not perform certificate validation (that is a whole 'nother can of worms.... still not sure what we're going to do for that), but it'll get you connected to an SSL link.  One big caveat is the TCP connection needs to be SSL from the get-go; I don't see any way the CC3100 stack will let you open an unencrypted connection and then convert it into an SSL link (STARTTLS style).
  6. Like
    MORA99 got a reaction from reaper7 in [Energia Library] WebSocketClient   
    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.
    WebSocketClient.zip

  7. Like
    MORA99 got a reaction from Automate in [Energia Library] WebSocketClient   
    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.
    WebSocketClient.zip

  8. Like
    MORA99 reacted to spirilis in CC3200 : Control pins without digitalWrite   
    Ok, so digital_pin_to_port gives you an index in another table of BASE registers...
     
    So it's more like:
     
    port = digital_pin_to_port[4];
    uint32_t portBase = (uint32_t) portBASEregister(port);
    HWREG(portBase + (GPIO_O_GPIO_DATA + (mask << 2))) ^= mask;
     
    (haven't tested this yet btw)
    Otoh, reading about how that register math works on page 115 of the CC3200 TRM was kind've interesting.  With the GPIO data register, bits [9:2] on the address bus form a mask of which bits are affected by the assigned value, hence the "+ (mask << 2)" part.  Neat.
  9. Like
    MORA99 got a reaction from bluehash in [Energia Library] DHT11 / DHT22 Temperature and Humidity Sensors   
    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(temperature); Serial.print(" H: "); Serial.println(humidity); } 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.
    dht.zip
  10. Like
    MORA99 got a reaction from chicken in [Energia Library] DHT11 / DHT22 Temperature and Humidity Sensors   
    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(temperature); Serial.print(" H: "); Serial.println(humidity); } 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.
    dht.zip
  11. Like
    MORA99 reacted to enl in A buffer?   
    buffers are used for protection even by the pro's to protect the expensive parts.
     
    Key words are: the expensive parts. Expensive in direct cost, or in down time and repair.
     
    If you are using the Gseries LP, the buffer costs almost as much as the microcontroller (between the IC, board space, etc), and limits you to only digital I/O, as well as requiring extra work to set up the buffer for input or output as needed, which costs time, complexity, and probably I/O pins.
     
    With most microcontrollers, most or all pins serve more than one potential purpose, such as digital I/O, A/D input, PWM output, and edge trigger digital input. In many designs, they same pin mightserve morethan one purpose at different times. For a system designed for beginners/prototyping, each pin must beable to serve all of its design purposes. This pretty much prohibits designing buffers/isolaters in. When I can buy a dozen 430s for under $1.50 each, the board space and extra component cost for buffers just isn't worth it in general.
     
    There is no way to protect a newbie from all mistakes. Or an experienced designer, for that matter. They occur. The best you can do is pick methods based on the applicaion to minimize the risk of damage due to abnormal events that you can anticipate, such as reversing a connector (back in the days of RS232 that was part of the spec), putting a connector on wrong (a concern with unkeyed headers), ground faults, and the like.
     
    In a design for motor control, Itend to use driver ICs where I can, and isolation resistors as well. With direct drive to a transistor, ALWAYS use resistors to limit current and diodes to shunt flyback/back EMF. For digital lines used only for a single purpose, buffers are a good idea, but you still need to be sure nofault will occur during startup or reset.
     
    Connector configuration is an art. Many comon specs are not very good, such as the spec for model servo connectors (keying is optional) where damage can occurif the connector is reversed. Power connectors and combined power/I/O connectors are even more critical. Back in the day, it was common to find discount cables for floppy drives and hard drives without the key plug, or connectors without the removed key pin. Put the cable on backwards, or one pin off, and damage was certain, due to the pin layout. Some connectors (the 20 pin HD data line used prior to IDE, for example) were not keyed at all, and very pricey damage was not unusual.
     
    General rules for connectors are to make best effort to use symmetry to prevent damage from reversal, and to try to prevent damage from one-pin-over if that is possible. I generally put groud at the outside, symmertically, and, if there is power, do the same, so reversal isn't an issue there. I try, when I can, to keep signal lines symmetric for reversal as well. Input to input, output to output.
     
    Better yet, use keyed connectors, like a D-type, or a keyed header. Not always possible. The launchpad, for example, is unkeyed. The most annoying feature of the Arduino (the half-space header) has the positive effect of keying the connector, IF all pins are present. Many boards don't include unused pins (like the analog ones if no analog inputs) and can be forced in the wrong way.
     
    What you are asking in your last line is, unfortunately, not something that can be generally done. Back in the day when low power was watts, a fuse or lightbulb, or other device was the answer. Today, when milli or microwats can cause damage, there isn't a lot to do. Fortunately, the MSP430 devices are pretty tolerant of many common failures. The outputs will drive a short to ground or power with little risk of damage. Sligh overvoltage on an input is generally ok. Many other devives (PIC, for example) are a lot less tolerant, and in an educational environment, tend to be replaced often due to student mistakes.
  12. Like
    MORA99 got a reaction from chicken in Measure short amounts of time with micros()   
    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(); do{ 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); delayMicroseconds(20); digitalWrite(3, LOW); delayMicroseconds(20); gives 22-24us ticks, so looks good.

  13. Like
    MORA99 got a reaction from chicken in Measure short amounts of time with micros()   
    So pulseIn in cc3200 uses micros, which was my problem to start with, so same issue. I made fresh sketch to try and isolate micros problem()   Test micro sleeps... for (uint16_t i=500; i<16000; i=i+500) { a = micros(); delayMicroseconds(16000); b = micros(); c=b-a; Serial.println(i); Serial.print("A: ");Serial.println(a); Serial.print("B: ");Serial.println(; Serial.print("C: ");Serial.println(c); }   All of those sleeps are between 1000 and 1800us acording to the cpu, but about 3ms acording to my logic analyser. At the very least they should be different, and getting longer for each loop.         Trying to find out where these timers come from ... unsigned long micros(void) { return (milliseconds * 1000) + (SysTickValueGet() / (F_CPU/1000000)); } So miliseconds times 1000, plus system tics, devided by cpu devided by 1million to get cycles per us   SysTickValueGet() - systick.c unsigned long SysTickValueGet(void) { // // Return the current value of the SysTick counter. // return(HWREG(NVIC_ST_CURRENT)); } ./cores/cc3200/inc/hw_nvic.h:#define NVIC_ST_CURRENT         0xE000E018  // SysTick Current Value Register   Page 58 in CC3200 datasheet: SysTick (see Section 3.2.1) Provides a simple, 24-bit clear-on-write, decrementing, wrap-on-zero counter with a flexible control mechanism.   'decrementing' hmm, flashback to my original time machine where the delay was roughly correct, but the timer values were odd.   void loop() { Serial.println(SysTickValueGet()); delay(100); } 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   unsigned long test[1000]; for (uint16_t i=0; i<1000; i++) test[i]=SysTickValueGet(); for (uint16_t i=0; i<1000; i++) { Serial.print(i);Serial.print(" > ");Serial.println(test[i]); } 170 > 27606 171 > 27554 172 > 27503 173 > 27452 174 > 27401 175 > 27349 176 > 27298 177 > 27247 178 > 27196 179 > 27144 180 > 27093 181 > 27042 182 > 26991 183 > 26939 184 > 26888 185 > 26837 186 > 26786 187 > 26734 188 > 26683   Aha, so there is the 24bit timer, if it ticks 80million times a second it overflows 4 times a second. But it counts down not up, so back to pulseIn.   hardware/cc3200/cores/cc3200/wiring_pulse.c // wait for the pulse to start while (MAP_GPIOPinRead(portBase, bit) != stateMask) if (numloops++ == maxloops) return 0; // wait for the pulse to stop unsigned long start = micros(); while (MAP_GPIOPinRead(portBase, bit) == stateMask) { if (numloops++ == maxloops) return 0; } unsigned long end = micros(); unsigned long result = end - start; That assumes that micros counts up, but with current code micros counts down untill it reaches milisecond boundary.
    So I made a copy of pulseIn and changed the line     unsigned long result = end - start; to      unsigned long result = start - end;   Then setup my logic analyser to make a simple 50% PWM signal with 20us pulses to the CC3200 and ran this test program for (uint16_t i=0; i<1000; i++) Serial.println(pulseinn(3,HIGH,100000)); 20
    19 21 20 4294965317 20 20 19 20 19 20 20 20 20 21 20 21   Most of the time timing is correct +/-1us, and then a huge wrong reading. 4 294 965 317 which is close to the max value of my unsigned long, which means end was higher than start, so the timer probaly overflowed there.    
×
×
  • Create New...