Jump to content
43oh

Peabody

Members
  • Content Count

    42
  • Joined

  • Last visited

  • Days Won

    11

Peabody last won the day on March 22 2019

Peabody had the most liked content!

About Peabody

  • Rank
    Advanced Member

Recent Profile Visitors

1,170 profile views
  1. Thanks very much for your replies. I'll go back and study what you've said, but it kinda looks like it just needs to stay in Naken assembler. That produces a .hex file which I flash to the chip with TI's MSP Flasher. There is no "environment". And I think any attempt to convert it to C is just bound to make it larger and less efficient.
  2. I just posted a Github repo on a 1K SD card bootloader for the G2553 and G2452: https://github.com/gbhug5a/SD-Card-Bootloader-for-MSP430 It's written in assembler, but that's not really accessible to most people who use Energia. So I wondered if it would be possible to rewrite it in C++. But I don't understand much about how C++ does things, and don't know if it's possible to do the same things in the same space, or anywhere near the same space. My code uses all 12 general purpose registers, mainly because operations on registers are smaller instructions than operations on me
  3. Thanks. I finally found a tutorial that may help: http://codeandlife.com/2012/04/02/simple-fat-and-sd-tutorial-part-1/ By the way, when I first compiled the example code from the PFatFs library, I got a strange warning that appears to be related to the IDE. Should I report it somewhere? C:\energia-1.8.7E21\hardware\energia\msp430\cores\msp430\atof.c: In function 'atof': C:\energia-1.8.7E21\hardware\energia\msp430\cores\msp430\atof.c:71:9: warning: floating constant exceeds range of 'double' [-Woverflow] Sketch uses 8236 bytes (50%) of program storage space. Maximum i
  4. I've been working on alternatives to updating firmware in the field, and wondered if a good alternative might be to embed a microSD card socket in a project, and use that to update firmware. It would require no cables or interface devices. Just copy the update file to the card, insert it into the slot, and power up the device, which would then detect the card, and use the file contents to flash new firmware, then (possibly) erase the file. I've downloaded the PFatFs.zip library from about 2016: https://forum.43oh.com/applications/core/interface/file/attachment.php?id=9251 Is t
  5. This continues on a new thread I started announcing the new modified BSL-Scripter. https://forum.43oh.com/topic/13429-modified-bsl-scripter-for-windows-now-works-with-ftdi-and-other-usb-to-uart-adapters/ Profound thanks to nagaokanchi for making this possible.
  6. A new WIN32 version of BSL-Scripter.exe has been compiled which allows BSL flashing using generic USB-to-UART adapters such as the FT232, CP2102 and CH430 as the hardware interface. It can be used with MSP430 F5xx F6xx, and FRxx parts with UART BSL. This version has a new MODE line option "INVOKE", which causes Scripter to directly generate the BSL hardware invocation sequence on the adapter's DTR and RTS outputs, which in turn are connected to the /Reset and Test pins on the target device. It produces the pattern shown in Figure 2 of slau319w.pdf and slau550s.pdf, which is normally gen
  7. I haven't looked at your latest version, but I tested the release build version 2, and it works!!! The 15ms sleeps don't seem to matter. Pics below. So at this point we have several variations open related to sleep times and methods used to change DTR and RTS. I would suggest that you just pick what options seem best to you and let me confirm one last time that they works, and we can publish. 🙂 One issue that comes to mind concerning which choices to make is that if one option might be usable in any future Linux or Mac version, that might be the best one. The other consideration is
  8. Thanks very much. Your Set and Clr work quite well. I've attached a scope picture showing what happens to the DTR and RTS lines. There are two problems: 1. Each sleep is supposd to be 10ms. The first sleep is significantly less than that. It may be necessary to add another 10ms sleep line right after that first one. All the other sleeps are actually about 15ms. I think that results from the default Windows tick time. I think it's likely that the difference won't matter. 2. The big problem is that after the last sleep ends, something is bringing DTR low - equivalent to rst.S
  9. I agree that the code I used in my CP2102 repo is not right for this. That was plain C, with no Boost involved. But I don't understand what is wrong with TI's original TestReset.h code for Scripter. It appears they DO use boost:asio to set DTR and RTS, and their code matches other examples I found online. My changes to UartComm.cpp contain my new calls to the TestReset.h functions for switching DTR and RTS. They have no connection to the CP2102 code. What is still puzzling is why TI #included the functions in TestReset.h, but never used them. Perhaps they used them in an older v
  10. At the risk of making you regret you did this, I need to ask if you can point me to anything that would explain what's going on in TestReset.h. I know nothing about Boost, or really C++, and the code there just doesn't make any sense. I don't see where "initState" comes from. It doesn't appear anywhere else in the source code, the libraries you included, or the Boost download I did. Also, it appears to be circular logic, and writes before it reads - it all seems upside down. But I've found that exact code elsewhere online as a standard way to do serial ports, but unfortunately without ex
  11. Thank you very much for posting this. I really appreciate it. I'm surprised you remembered the original post. I have downloaded the repo ZIP file, and will study it carefully. But I suspect it will still be way over my head. I've never actually used a "real" compiler before. But I will do my best to figure it out. Can you say what you needed to change to get Scripter to work with the MSP432?
  12. OK, so you don't use a timer-based PWM output, but vary the ON time in your code (NOPs or whatever) based on the number of segments being lit. And I assume the "worst case" is displaying an 8. Well that's pretty cool. And assembler is good for this kind of thing. I did all of my version in MSP430 assembler first, then moved it to Energia/Arduino to make it more accessible. What LVC part did you use?
  13. That's very interesting. Do you vary the PWM rate depending on the number of segments being lit up? And no resistors on the common cathodes?
  14. In case it might be of use to someone, I've posted a Youtube video and created a Github repo dealing with an alternate way of multiplexing 7-segment displays that has a greatly reduced parts count. It's multiplexing by segment instead of by digit. The video shows this method implemented with an MSP430G2553. The Github repo has demonstration Arduino Nano sketches, but they should work as-is with Energia except for the pin assignments. The video is on my local OSH group's channel, and I can't respond to comments there, but will answer questions here if there are any. https://www.youtube
  15. I just wanted to say that I think I found the answer to the non-regular millis, at least in the Arduino IDE, and I suspect it's the same in Energia. The interrupt that updates millis is actually a bit slower than 1ms. So periodically, the millis value is incremented by 2 so as to keep the average rate at exactly 1ms. Since my IF statement executes every other milli, it will execute after only 1ms when the millis count increments by 2. And that's why the scope showed the irregular trigger.
×
×
  • Create New...