Jump to content

Thorvard

Members
  • Content Count

    71
  • Joined

  • Last visited


Reputation Activity

  1. Like
    Thorvard got a reaction from OzGrant in [Energia Library] Petit FatFS SD Card Library   
    Hi, i just wanted to report that the library won't compile with Energia release 0101E0011 and the F5529 Launchpad because "DIR" is already defined in \energia-0101E0011\hardware\tools\msp430\msp430\include\msp430f5529.h line 3900: 
    /* USBCTL Control Bits */ #define DIR (0x0001) /* USB - Data Response Bit */ renaming all "DIR" references in the Petit-FATFS library and examples to "_DIR" works as a workaround.
     
    regards, Nick
  2. Like
    Thorvard reacted to Rei Vilo in CC3200 LaunchPad Pins Map   
    Please find the pins map of the CC3200 LaunchPad.
     
    Edit Sept. 08, 2014

  3. Like
    Thorvard reacted to energia in New Energia release 0101E0013 - 09/05/2014   
    I am happy to announce that release 0101E0013 just went up on http://energia.nu. This release adds support for the awesome CC3200 WiFi LaunchPad and CC3100 BoosterPack for MSP430 and TivaC.
     
    I want to thank everybody for their support and contributions. Energia would not have been possible without such an awesome community!
     
    Details of the release can be found on http://energia.nu
  4. Like
    Thorvard got a reaction from mateolasic14 in Nokia 5510   
    This thread could be a good start: http://forum.43oh.com/topic/1312-nokia-5110-display/
  5. Like
    Thorvard reacted to spirilis in Energia for CC3200 LaunchXL   
    I think Robert had an estimated time that he's blown through already, but it's coming. Sounds like it's been a tricky one for him so far.
  6. Like
    Thorvard got a reaction from bluehash in CC3200 LaunchPad Discussion   
    Good news everyone, its working again
     
    After running the 'getting_started_with_ap' example from the cc3200 SDK i was able to put the device into smartconfig mode and connected it to my router, i had to use the iOS App because the Java Webbrowser code that Ti supplied wasnt working.
    But the problem with flashing still existed, so after wasting another few hours i came to the conclusion to format the flash using the Uniflash Tool, despite the fact that the Uniflash manual does not recommend it. But hey, the Launchpad wasnt flashing correctly, i had nothing to lose
     
    After formatting it to 1MB flash, NO checkmark at security or alert option, i was able to flash the OOB Demo successfully without error.
     
    Why is the TI stuff (CCS, Uniflash) always so complicated?
     
    I can't wait for Energia supporting this Launchpad, i love   Energia for being so uncomplicated, because im still a beginner   to embedded stuff
  7. Like
    Thorvard got a reaction from lilyhack in [Energia Library] Adafruit MDNS Library ported for Energia + CC3000   
    I ported the Adafruit MDNS Library for Energia + CC3000, tested on Tiva-C LP, should also work for F5529 LP after changing the Boosterpackpins.
     
    Using this library you can access the CC3000 by "energia.local" or whatever you name it when calling mdns.begin(<servername>) in the setup.
    You have to call mdns.update() in the main loop to handle incoming name queries.
     
    I modified Robert's simpleWebServer example to use the library.
     
    Be aware that some access points and wifi routers do not forward multicast packets from the LAN to the WiFi Interface.
    (My Router has this bug and it took me over a week to find out...  )
     
    This library is Copyright © 2013 by Tony DiCola published under MIT license (see CC3000_MDNS.h for details).
    I just changed a few things to make it work with Energia.
     
    Have fun, Nick 
    CC3000_MDNS.zip
  8. Like
    Thorvard got a reaction from PTB in CC3200 LaunchPad Discussion   
    Good news everyone, its working again
     
    After running the 'getting_started_with_ap' example from the cc3200 SDK i was able to put the device into smartconfig mode and connected it to my router, i had to use the iOS App because the Java Webbrowser code that Ti supplied wasnt working.
    But the problem with flashing still existed, so after wasting another few hours i came to the conclusion to format the flash using the Uniflash Tool, despite the fact that the Uniflash manual does not recommend it. But hey, the Launchpad wasnt flashing correctly, i had nothing to lose
     
    After formatting it to 1MB flash, NO checkmark at security or alert option, i was able to flash the OOB Demo successfully without error.
     
    Why is the TI stuff (CCS, Uniflash) always so complicated?
     
    I can't wait for Energia supporting this Launchpad, i love   Energia for being so uncomplicated, because im still a beginner   to embedded stuff
  9. Like
    Thorvard got a reaction from spirilis in CC3200 LaunchPad Discussion   
    Good news everyone, its working again
     
    After running the 'getting_started_with_ap' example from the cc3200 SDK i was able to put the device into smartconfig mode and connected it to my router, i had to use the iOS App because the Java Webbrowser code that Ti supplied wasnt working.
    But the problem with flashing still existed, so after wasting another few hours i came to the conclusion to format the flash using the Uniflash Tool, despite the fact that the Uniflash manual does not recommend it. But hey, the Launchpad wasnt flashing correctly, i had nothing to lose
     
    After formatting it to 1MB flash, NO checkmark at security or alert option, i was able to flash the OOB Demo successfully without error.
     
    Why is the TI stuff (CCS, Uniflash) always so complicated?
     
    I can't wait for Energia supporting this Launchpad, i love   Energia for being so uncomplicated, because im still a beginner   to embedded stuff
  10. Like
    Thorvard reacted to energia in CC3200 LaunchPad Discussion   
    I should have an Energia beta release for this LaunchPad in about 2 weeks or so. Will update this thread once it is.
  11. Like
    Thorvard reacted to energia in New Launchpad and Boosterpack released   
    It's an awesome board, and yes we are hard at work to get it into Energia
    I should have a beta release in a couple weeks.
  12. Like
    Thorvard reacted to chicken in New Launchpad and Boosterpack released   
    Also see this thread: http://forum.43oh.com/topic/5541-new-boosterpacks-cc3100-cc3200/
  13. Like
    Thorvard reacted to Rei Vilo in [Energia Library] Stellaris Launchpad FatFs Energia library   
    Best solution is to use modern collaborative tools and share a repository.
     
    I've created the SD_TM4C repository for SD Library for LaunchPad LM4F / TM4C and pushed my code.
     
    Feel free to contribute and add support for other LaunchPad boards  . 
     
    EDIT Correct link
  14. Like
    Thorvard reacted to Rei Vilo in [Energia Library] Stellaris Launchpad FatFs Energia library   
    The MSP430G2 MCUs don't have enough RAM to handle the SD-card. SD-card in SPI more requires 512 bytes of RAM as buffer for cluster. So the library only works on a LM4F / TM4C.
     
    Here's the ZIP file. Changes from the original library are minimal. However, the library seems to suffer from memory leakage. I don't have the tools to check and fix this.
     
    Please note that, contrary to the other libraries I've released, I'm not providing any support for this FatFS library. You use it at your own risk.
     
    Enjoy 
    FatFs.zip
  15. Like
    Thorvard reacted to madias in [Energia Library] Stellaris Launchpad FatFs Energia library   
    @@Rei Vilo:
    Maybe you can really post your SD library (is it really for stellaris/tiva?), I see a lot of things to do with the original one, so you can save much work for  Thorvard and me
     
    Thank you 
    Regards 
    Matthias
  16. Like
    Thorvard reacted to spirilis in Energia and Wolverine - Tips   
    I wrote this up the other week but forgot to post it.  Just a little power-user help for folks interested in really exploring the "potential" behind FRAM memory in Energia.
     
    Tips & Advanced Tricks for using Wolverine with Energia 12   I've brainstormed a few things folks might want to play with if they're interested in getting the most out of their Wolverine LaunchPad and its built-in FRAM memory.  The FRAM memory, being modifiable yet persistent, is quite different from Flash and our C compilers aren't necessarily laid out to make it super-simple to use.  That said, it's not really that hard to use.   There are a few "tricks" you can employ with Energia 12 to get more out of your Wolverine-   1. Declare global variables as being part of the ".text" linker section, so they live in FRAM and are not copied to/fro RAM on bootup. (this is the "quick hack" way to do it, the long & canonical way to do this is to define a new section in the Linker Script assigned to the ROM segment and declare your arrays or variables as being a part of that section instead).   2. Write/read to the "High" memory segment -- the Wolverine happens to have a 16KB segment of its FRAM living from 0x10000 to 0x13FFF (that's above address 65536 decimal, outside the realm of what a 16-bit pointer can reference) which is unknown to the MSPGCC compiler that ships with Energia 12, since it doesn't support large-memory model.   3. Move your RAM to FRAM, giving you more RAM (stack & heap) if it's what you want.  This isn't always necessary since you can declare large arrays as a global in the ".text" section per #1 above.   Without further adieu, let me show you:   1. In your sketch, up top you can do something like this:   #define PERSIST __attribute__((section(".text")))   and then declare global variables with this new "PERSIST" keyword like such:   uint8_t DisplayBuffer[LCD_MAXIMUM_Y][LCD_MAXIMUM_X] PERSIST;   Your "DisplayBuffer" array will live in FRAM and won't hog up any of your RAM.  It will co-exist with program code, so be VERY VERY SURE not to make any "buffer overflow" mistakes and write before or past the end of its memory boundaries or you will corrupt your sketch's binary application code.  Take this doubly serious when the application in question involves Internet connectivity of any kind; I can imagine the spectacular headline on the blogs "IoT application sports buffer-overflow exploit where attacker can write any binary MSP430 code they want!"   Alternately, you can use the InfoMem segments:   uint8_t DisplayBuffer[512] __attribute__((section(".infomem")));   which has 512 bytes (maximum) available for your use; it lives outside the main code FRAM area and if you try writing beyond it, you attempt to write to the calibration data (TLV) FRAM segment which should throw an internal violation (not sure what happens, whether the chip halts or resets or does nothing, but the calibration info will remain safe).  Unlike other MSP430 chips, Info segment "A" can be written on these as the calibration data is stored in another "special" FRAM segment at 0x1A00.     2. I wrote some functions employing assembly language; which the current stable release of MSPGCC does understand (the extended-memory 20-bit instructions) that gives you a way to copy data to or from the higher memory segments. See here: HighMem.zip   The functions are called highmem_write() and highmem_read().  You can import the HighMem library into your sketch, and it should add: #include "highmem.h" to your sketch.   The functions are:   void highmem_write(uint32_t dstaddr, void *srcaddr, uint16_t len) You give it the FRAM destination address as a 32-bit integer (0x10000 or above), followed by a pointer to a buffer in your SRAM or lower FRAM, followed by the # of bytes you want to write.   The reciprocal of this is highmem_read(): void highmem_read(uint32_t srcaddr, void *dstaddr, uint16_t len)   Give it the FRAM source address as a 32-bit integer (0x10000 or above), followed by a pointer to a buffer in your SRAM or lower FRAM where you want the data to be copied into, followed by the # of bytes.  The # of bytes can be an odd or even number, as it uses byte-at-once transfers rather than word-at-once.  It uses DMA channel#2 to do the transfers.   For those using the FRAM to store a display buffer of some sort, this may be useful as a "bonus" loft or swap area for storing multiple versions of your display framebuffer.  The memory up there is not allocated by the linker, so you need to manage it yourself (keep track of which addresses you've used and how much data is stored there).  It's also not possible to reference the data directly by variables, because the MSPGCC compiler used in Energia 12 doesn't support the large-memory model (doesn't produce the 20-bit pointers and appropriate instructions for accessing it directly).  There is a later revision of MSPGCC (developmental) that does support this, but Energia isn't using it.  At some point in the future Energia will use the RedHat msp430-elf-gcc which does support large-memory model, but that'll be a while out I think.   Example sketch using these (writes a stock string to the highmem, then changes 2 bytes before reading it back into an SRAM buffer to be printed over the serial port)- #include <highmem.h> #include <string.h> const char *teststr = "What is this???"; void setup() { // put your setup code here, to run once: pinMode(P4_5, INPUT_PULLUP); delay(10); while (digitalRead(P4_5)) ; // Wait for S1 to be pressed so the user has time to open serial monitor Serial.begin(115200); Serial.println("HighMem test:"); highmem_write(0x10000, teststr, strlen(teststr)+1); // Write stock string to highmem } void loop() { char buf[128]; // put your main code here, to run repeatedly: buf[0] = 'a'; buf[1] = 't'; highmem_write(0x10000+10, buf, 2); // Write 2-byte modification to highmem highmem_read(0x10000, buf, strlen(teststr)+1); // Pull entire string from highmem to 'buf' Serial.print("HighMem string says: "); Serial.println(buf); while(1) delay(1000); } It prints "What is that???" instead of "What is this???", thanks to the modification performed in loop().     3. Edit MSPGCC's linker script for the msp430fr5969 to move "ram" into the FRAM address space.  Note you'll have to move the "rom" linker segment up appropriately to give room for the RAM.   From your Energia install, e.g. C:\energia-0101E0012, the MSPGCC compiler is stored under "hardware\tools\msp430".  The linker scripts live in: C:\energia-0101E0012\hardware\tools\msp430\msp430\lib\ldscripts with a separate directory for each chip.   Go into C:\energia-0101E0012\hardware\tools\msp430\msp430\lib\ldscripts\msp430fr5969 and locate a file called "memory.x". Open this in a text editor, you should see the default contents which look like this:   MEMORY { sfr : ORIGIN = 0x0000, LENGTH = 0x0010 /* END=0x0010, size 16 */ peripheral_8bit : ORIGIN = 0x0010, LENGTH = 0x00f0 /* END=0x0100, size 240 */ peripheral_16bit : ORIGIN = 0x0100, LENGTH = 0x0100 /* END=0x0200, size 256 */ bsl : ORIGIN = 0x1000, LENGTH = 0x0800 /* END=0x1800, size 2K as 4 512-byte segments */ infomem : ORIGIN = 0x1800, LENGTH = 0x0200 /* END=0x1a00, size 512 as 4 128-byte segments */ infod : ORIGIN = 0x1800, LENGTH = 0x0080 /* END=0x1880, size 128 */ infoc : ORIGIN = 0x1880, LENGTH = 0x0080 /* END=0x1900, size 128 */ infob : ORIGIN = 0x1900, LENGTH = 0x0080 /* END=0x1980, size 128 */ infoa : ORIGIN = 0x1980, LENGTH = 0x0080 /* END=0x1a00, size 128 */ ram (wx) : ORIGIN = 0x1c00, LENGTH = 0x0800 /* END=0x2400, size 2K */ rom (rx) : ORIGIN = 0x4400, LENGTH = 0xbb80 /* END=0xff80, size 48000 */ vectors : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x10000, size 128 as 64 2-byte segments */ far_rom : ORIGIN = 0x00010000, LENGTH = 0x00004000 /* END=0x00014000, size 16K */ /* Remaining banks are absent */ ram2 (wx) : ORIGIN = 0x0000, LENGTH = 0x0000 ram_mirror (wx) : ORIGIN = 0x0000, LENGTH = 0x0000 usbram (wx) : ORIGIN = 0x0000, LENGTH = 0x0000 } REGION_ALIAS("REGION_TEXT", rom); REGION_ALIAS("REGION_DATA", ram); REGION_ALIAS("REGION_FAR_ROM", far_rom); PROVIDE (__info_segment_size = 0x80); PROVIDE (__infod = 0x1800); PROVIDE (__infoc = 0x1880); PROVIDE (__infob = 0x1900); PROVIDE (__infoa = 0x1980); What we're interested in here is the "ram (wx)" and "rom (rx)" definitions in the MEMORY { } declaration. The default setup puts RAM where it should be; at the Wolverine's 2KB SRAM segment starting at 0x1C00.  The "rom" is actually FRAM, but called "rom" since the main linker scripts are common to all the msp430 targets supported and expect to see the main program memory called "rom".   So for fun, let's move our 2KB RAM segment into FRAM.   It'll look like this:   ram (wx) : ORIGIN = 0x4400, LENGTH = 2048 /* END=0x4C00, size 2K */ rom (rx) : ORIGIN = 0x4C00, LENGTH = 45952 /* END=0xff80, size 48000-2048 = 45952 */ Note I used decimal for the LENGTH part so it's easier to think through.  We're putting our "ram" segment at the start of FRAM, and moving the start of the "rom" segment 2KB higher to compensate, but also telling the linker that its segment is now 2048 bytes (2K) smaller.  This last piece is very important; you'll see errors in compiling if you get it wrong.   Now one of TI's big marketing push is you can partition your FRAM to give more space to RAM vs. code.  Let's say you have a sketch that runs beautifully on the MSP430F5529 LaunchPad with its 8KB available SRAM, but bombs on the Wolverine.  You want to give the Wolverine 8KB RAM too so it'll work right.   It'll look like this:   ram (wx) : ORIGIN = 0x4400, LENGTH = 8192 /* END=0x6400, size 8K */ rom (rx) : ORIGIN = 0x6400, LENGTH = 39808 /* END=0xff80, size 48000-8192 = 39808 */ We put "ram" at the start of FRAM, gave it 8192 bytes (8KB), moved the "rom" segment up by 8KB and shrunk its total length by 8KB.   Note that unfortunately you can't just combine your existing SRAM and FRAM together since they are not contiguous in address space.  SRAM starts at 0x1C00 and ends at 0x2400, where FRAM starts at 0x4400; there is a 0x2000 (8KB) gap between those two.   It's always a good idea to keep the original ram & rom specifiers in that memory.x file but commented out so you can quickly go back to the original configuration.  Here's what it looks like: /* ram (wx) : ORIGIN = 0x1c00, LENGTH = 0x0800 */ /* END=0x2400, size 2K */ /* rom (rx) : ORIGIN = 0x4400, LENGTH = 0xbb80 */ /* END=0xff80, size 48000 */ ram (wx) : ORIGIN = 0x4400, LENGTH = 8192 /* END=0x6400, size 8K */ rom (rx) : ORIGIN = 0x6400, LENGTH = 39808 /* END=0xff80, size 48000-8192 = 39808 */   You can then comment out the 2nd ram/rom definitions and uncomment the first one (notice the "*/" after "LENGTH = " in the first 2 lines) to revert back to the default memory setup.   That said, unless you are just trying to run a sketch that works beautifully on the MSP430F5529 or Tiva-C due to its expansive RAM and won't on the Wolverine, there's probably no reason to hack your linker script when you can just declare big buffers as part of the ".text" section per #1 explained above.
  17. Like
    Thorvard reacted to Rei Vilo in [Energia Library] Stellaris Launchpad FatFs Energia library   
    I've added the _t suffix to all types, so you need to edit line 82 and add the _t suffix to FILINFO to get FILINFO_t.
    void dir_list (void) { FILINFO_t file_info; // information on file size and type Now, I'm no longer using the FatFs library but the SD library from Adafruit. It provides a higher level interface.
  18. Like
    Thorvard got a reaction from StefanWxx in How to wake up on keypad press ? [IR-Remote Project]   
    I think when you go to sleep mode all outputs go tri-state, therefore there is no ground connected to the switches and when you push a button nothing happens. Try connecting an external pulldown resistor to the output-pins, 10k should work.
  19. Like
    Thorvard reacted to bluehash in [Energia Library] Adafruit MDNS Library ported for Energia + CC3000   
    @@Thorvard Thank you for sharing!
  20. Like
    Thorvard got a reaction from bluehash in [Energia Library] Adafruit MDNS Library ported for Energia + CC3000   
    I ported the Adafruit MDNS Library for Energia + CC3000, tested on Tiva-C LP, should also work for F5529 LP after changing the Boosterpackpins.
     
    Using this library you can access the CC3000 by "energia.local" or whatever you name it when calling mdns.begin(<servername>) in the setup.
    You have to call mdns.update() in the main loop to handle incoming name queries.
     
    I modified Robert's simpleWebServer example to use the library.
     
    Be aware that some access points and wifi routers do not forward multicast packets from the LAN to the WiFi Interface.
    (My Router has this bug and it took me over a week to find out...  )
     
    This library is Copyright © 2013 by Tony DiCola published under MIT license (see CC3000_MDNS.h for details).
    I just changed a few things to make it work with Energia.
     
    Have fun, Nick 
    CC3000_MDNS.zip
  21. Like
    Thorvard reacted to energia in Energia Tiva USB support   
    I have brought this up within TI and the good thing is that all whom I talked to are open to converting the stack to the TI modified BSD license just as DriverLib. Give it a bit more time as these things can be a bit tedious legal wise. Once it is BSD I can definitely use some help from the USB experts here to mold this into an Energia library. 
     
    With that said, I would definitely welcome an open source alternative!
     
    Robert
  22. Like
    Thorvard reacted to energia in A question for the community.   
    I would love to see the code! I am sure that it will help a lot of people. Please feel free to attached them to the thread or if you have them checked in on github or somewhere else then a link would be great as well!
  23. Like
    Thorvard reacted to MisterUnix in A question for the community.   
    Before I go hog wild and start posting; I have a question for the members.
     
    Does anyone want to see the code examples?
     
    I have four main projects for the Tiva boards.
     
    Multi-functional timing trigger for my strobes. Midi sequencer. Synth A bit of DSP just to see what I can do.  
    As this is a new processor for me there is going to be the excitement of discovery when I get something working. I started out as a forth programmer in the embedded world so I have a tendency to write very small test routines to test ideas and feasibility.  Maybe this could help out other noobs like me and keep them from cracking their skulls open against the workbench.
     
    I await and will abide by the communities decision.
     
    Bill
     
  24. Like
    Thorvard got a reaction from dubnet in mDNS or similiar with cc3000?   
    Tadaaa, not bricked
    IP Address Information: IP Address: 192.168.0.17 Version: 1.26 NetMask: 255.255.255.0 Gateway: 192.168.0.1 mdnsAdvertiser(1, "energia", 7);
    shows up correctly as energia.local in wireshark
    >ping energia.local -> resolves to 192.168.0.17 
     
    I'll post the updated fw_patch.h for energia later.
     
    regards, Nick
  25. Like
    Thorvard reacted to spirilis in Simple IRC example   
    Ok this is just silly, but I had to do it.
     
    Simple IRC client that pops into #energia, says hi and runs.
    /* IRC Example * Simple IRC client which connects gracefully, joins #energia and says a simple Hello before quitting and indefinitely sleeping. */ #include <Ethernet.h> #include <IPAddress.h> #include <string.h> byte ourMac[] = { 0x52, 0x54, 0xFF, 0xFF, 0xFF, 0x01 }; EthernetClient client; const char *ircserver_name = "chat.freenode.net"; //#define IRC_USE_IP_NOT_DNS //IPAddress ircserver(62,231,75,133); // ^ Required for connecting through an SSH tunnel for getting around a firewall // Comment out #define IRC_USE_IP_NOT_DNS to use the ircserver_name DNS to connect. #define IRCSERVER_PORT 6667 const char *irc_nick = "SpirTivaLP"; const char *irc_user = "tm4c129"; const char *irc_user_description = "Energia Warrior"; const char *irc_channel = "#energia"; void dispatch_composite_message(uint8_t, int); void process_inbound_message(uint8_t, int); void setup() { IPAddress ip; Serial.setBufferSize(2048, 64); Serial.begin(115200); // Wait for USR_SW1 to be pressed before continuing (10ms resolution polling the button)... // This just gives me time to open the Serial Monitor before proceeding. pinMode(USR_SW1, INPUT_PULLUP); uint32_t lastmillis = millis(); while (digitalRead(USR_SW1)) { if ( (millis() - lastmillis) > 1000 ) { Serial.println("Waiting for USR_SW1 press to begin..."); lastmillis = millis(); } delay(10); } // Initialize network. Serial.println("\n\nDHCP IRC Client Example"); Serial.print("DHCP init: "); if (!Ethernet.begin(ourMac)) { Serial.println("Failed to configure Ethernet using DHCP. Halting."); while(1) delay(1000); } Serial.print("done; IP="); ip = Ethernet.localIP(); ip.printTo(Serial); Serial.println("\n"); } volatile boolean is_connected = false; volatile int prot_stage = 0; volatile boolean prot_stage_latched = false; /* ^ Determines if the current event stage has been carried out, in which * case we're waiting for some reply or some other event to proceed to * the next event stage. */ // IRC protocol event stages #define PROT_STAGE_WAITINIT 0 #define PROT_STAGE_NICK 1 #define PROT_STAGE_USER 2 #define PROT_STAGE_JOIN 3 #define PROT_STAGE_SAYHELLO 4 #define PROT_STAGE_QUIT 5 #define PROT_STAGE_DONE 6 void loop() { uint8_t buf[2049]; int len; // Main loop if (!is_connected || !client.connected()) { Serial.print("Connecting to: "); Serial.println(ircserver_name); #ifdef IRC_USE_IP_NOT_DNS if (client.connect(ircserver, IRCSERVER_PORT)) { #else if (client.connect(ircserver_name, IRCSERVER_PORT)) { #endif Serial.println("connected\n"); is_connected = true; prot_stage = PROT_STAGE_WAITINIT; } else { is_connected = false; Serial.println("Failed; pausing 5 seconds before retrying"); delay(5000); } } else { // Process incoming data first if (client.available()) { if ((len = client.read(buf, 2048)) > 0) { buf[len] = '\0'; Serial.print("Inbound msg: "); Serial.write(buf, len); Serial.println(); dispatch_composite_message(buf, len); // TODO: Use a ring-buffer with this code as the producer and dispatch_composite_message as the consumer. } } // Check protocol event stage and perform outbound messages switch (prot_stage) { case PROT_STAGE_NICK: if (!prot_stage_latched) { Serial.println("Registering NICK-\n"); // Compose NICK command buf[0] = 0; strcat((char *)buf, "NICK "); strcat((char *)buf, (char *)irc_nick); strcat((char *)buf, "\r\n"); client.print((char *)buf); prot_stage++; // No reply needed to advance to next step } break; case PROT_STAGE_USER: if (!prot_stage_latched) { Serial.println("Registering USER-\n"); client.print("USER "); client.print(irc_nick); client.print(" "); client.print(irc_user); client.print(" "); client.print(ircserver_name); client.print(" :"); client.print(irc_user_description); client.print("\r\n"); prot_stage_latched = true; // Must wait for RPY_ENDOFMOTD before proceeding } break; case PROT_STAGE_JOIN: if (!prot_stage_latched) { Serial.print("Joining "); Serial.print(irc_channel); Serial.println("-"); client.print("JOIN "); client.print(irc_channel); client.print("\r\n"); prot_stage_latched = true; // Must wait for RPY_TOPIC before proceeding } break; case PROT_STAGE_SAYHELLO: if (!prot_stage_latched) { Serial.print("Writing to "); Serial.print(irc_channel); Serial.println("-"); client.print("PRIVMSG "); client.print(irc_channel); client.print(" :"); client.print("Hi everyone! I am a TI TM4C129 LaunchPad connecting to IRC and sending you a brief message."); client.print(" Currently using Energia release "); client.print(12, DEC); client.println(".\r\n"); prot_stage++; // No reply needed to proceed with the next step } break; case PROT_STAGE_QUIT: if (!prot_stage_latched) { Serial.println("Issuing QUIT-\n"); client.print("QUIT :Bye for now!\r\n"); prot_stage++; } break; case PROT_STAGE_DONE: Serial.println("Done."); while (1) delay(1000); break; } /* switch(prot_stage) */ } /* if (is_connected) */ } /* loop() */ /* Process a packet into a sequence of \r\n-terminated lines; Note this should be replaced * with a ring-buffer design, as data which flows across multiple packets will not be * processed correctly; the last request will be truncated and the beginning of the next * request will be handled improperly. */ void dispatch_composite_message(uint8_t *buf, int len) { uint8_t *bufptr = buf; uint8_t *nl = (uint8_t *)strstr((char *)bufptr, "\r\n"); int sublen = 0; while (nl != NULL) { sublen = (int) (nl - bufptr); process_inbound_message(bufptr, sublen); bufptr += sublen + 2; if ( (bufptr - buf) >= len ) return; nl = (uint8_t *)strstr((char *)bufptr, "\r\n"); } } /* Process individual line. */ void process_inbound_message(uint8_t *buf, int sublen) { uint8_t *arg1, *arg2; int len; // Process inbound message buf[sublen] = '\0'; arg1 = (uint8_t *)strstr((char *)buf, " "); if (arg1 == NULL) return; *arg1 = '\0'; arg1++; int i=0; while (arg1[i] != ' ' && arg1[i] != '\0') i++; arg1[i] = '\0'; if ( (arg1 + i - buf) >= sublen ) arg2 = NULL; else arg2 = arg1 + i + 1; Serial.print("Reply ARG: "); Serial.println((char *)arg1); // WAITINIT waits for any sort of reply from the IRC server indicating it has connected if (prot_stage == PROT_STAGE_WAITINIT) { prot_stage++; prot_stage_latched = false; return; } // Perform PING reply if (!strcmp((char *)buf, "PING")) { Serial.print("Received PING "); Serial.print((char *)arg1); Serial.println("; sending PONG"); client.print("PONG "); if (arg1[0] == ':') client.print((char *)(arg1+1)); else client.print((char *)arg1); client.print("\r\n"); } // RPY_ENDOFMOTD to advance past USER if (prot_stage == PROT_STAGE_USER && !strcmp((char *)arg1, "376")) { prot_stage++; prot_stage_latched = false; } // RPY_TOPIC to advance past JOIN if (prot_stage == PROT_STAGE_JOIN && !strcmp((char *)arg1, "332")) { prot_stage++; prot_stage_latched = false; } } Probably a lot of things I can improve on, not the least of which is a proper ring-buffer for the inbound data and a better parser.  But it works:
    14:17 -!- SpirTivaLP [~SpirTivaL@<hostname_redacted>] has joined #energia 14:17 < SpirTivaLP> Hi everyone! I am a TI TM4C129 LaunchPad connecting to IRC and sending you a brief message. Currently using Energia release 12. 14:17 -!- SpirTivaLP [~SpirTivaL@<hostname_redacted>] has quit [Client Quit] We'll call it the beginnings of a Tiva-C IRC bot...
×
×
  • Create New...