Reply by Jon Kirwan December 24, 20122012-12-24
On Mon, 24 Dec 2012 15:45:45 +0000 (UTC), Waldek Hebisch
<hebisch@math.uni.wroc.pl> wrote:

>Waldek Hebisch <hebisch@math.uni.wroc.pl> wrote: >> Jon Kirwan <jonk@infinitefactors.org> wrote: >> > >> > Doesn't sound like where I'd like to be. I am thinking, say, >> > about hooking up a standard, cheap, PC keyboard to a ... >> > well, let's say an MSP430 with ... let's give it 16k flash >> > and 512 bytes sram total. Hmm. There are six different ones >> > with that spec. Three at $1 and three at $2. >> > >> > Any chance? It is just a keyboard, after all. >> >> Look at msp430f550x series. IIRC the cheapest one has >> has TI suggested retail price 1.6$. However, RAM >> is much bigger than 512 bytes: all in the series have >> 2kB RAM for USB controller and 4kB data RAM. > >Oops, msp430f550x is device only...
Thanks for checking on it. I was about to do that, today. Jon
Reply by Waldek Hebisch December 24, 20122012-12-24
Waldek Hebisch <hebisch@math.uni.wroc.pl> wrote:
> Jon Kirwan <jonk@infinitefactors.org> wrote: > > > > Doesn't sound like where I'd like to be. I am thinking, say, > > about hooking up a standard, cheap, PC keyboard to a ... > > well, let's say an MSP430 with ... let's give it 16k flash > > and 512 bytes sram total. Hmm. There are six different ones > > with that spec. Three at $1 and three at $2. > > > > Any chance? It is just a keyboard, after all. > > > > Look at msp430f550x series. IIRC the cheapest one has > has TI suggested retail price 1.6$. However, RAM > is much bigger than 512 bytes: all in the series have > 2kB RAM for USB controller and 4kB data RAM. >
Oops, msp430f550x is device only... -- Waldek Hebisch hebisch@math.uni.wroc.pl
Reply by Waldek Hebisch December 23, 20122012-12-23
Jon Kirwan <jonk@infinitefactors.org> wrote:
> > Doesn't sound like where I'd like to be. I am thinking, say, > about hooking up a standard, cheap, PC keyboard to a ... > well, let's say an MSP430 with ... let's give it 16k flash > and 512 bytes sram total. Hmm. There are six different ones > with that spec. Three at $1 and three at $2. > > Any chance? It is just a keyboard, after all. >
Look at msp430f550x series. IIRC the cheapest one has has TI suggested retail price 1.6$. However, RAM is much bigger than 512 bytes: all in the series have 2kB RAM for USB controller and 4kB data RAM. -- Waldek Hebisch hebisch@math.uni.wroc.pl
Reply by Jon Kirwan December 20, 20122012-12-20
On Thu, 20 Dec 2012 12:01:39 -0800, Rob Gaddi
<rgaddi@technologyhighland.invalid> wrote:

>On Thu, 20 Dec 2012 11:54:19 -0800 >Jon Kirwan <jonk@infinitefactors.org> wrote: > >> On Thu, 20 Dec 2012 10:00:28 -0600, Frnak McKenney >> <frnak@far.from.the.madding.crowd.com> wrote: >> >> >Plus two compiler/IDE suites plus the MSP430 port of gcc. >> >> Yes. I've been having almost nothing but trouble with IAR's >> on my "clean" install of Win7 Ultimate 64-bit, though. I >> don't know what the problem is, but I've tried it with many >> different LaunchPads and different USB connectors (the >> motherboard has a LOT of them) and I also tried doing it with >> the XP 32-bit VM from Microsoft running underneath without >> any better success (I didn't expect that to work, anyway.) On >> the same system, CCS does just fine. Odd thing there, _if_ >> both are using the same DLL (which maybe they are not.) >> >> On a Thinkpad laptop running Win7 Professional, though, IAR >> works great. And on all my other machines, just fine. But >> they aren't 64-bit installs. > >I haven't tried it under Windows, but I just used the Linux version of >mspgcc for a personal project, and was really impressed by how clean >and easy it wound up being. You also need mspdebug if you're going to >work with a LaunchPad, but once I got them installed things just did >what they were supposed to.
Wonderful to hear. That was next on my list to try out, as well. Good news! Thanks, Jon
Reply by Rob Gaddi December 20, 20122012-12-20
On Thu, 20 Dec 2012 11:54:19 -0800
Jon Kirwan <jonk@infinitefactors.org> wrote:

> On Thu, 20 Dec 2012 10:00:28 -0600, Frnak McKenney > <frnak@far.from.the.madding.crowd.com> wrote: > > >Plus two compiler/IDE suites plus the MSP430 port of gcc. > > Yes. I've been having almost nothing but trouble with IAR's > on my "clean" install of Win7 Ultimate 64-bit, though. I > don't know what the problem is, but I've tried it with many > different LaunchPads and different USB connectors (the > motherboard has a LOT of them) and I also tried doing it with > the XP 32-bit VM from Microsoft running underneath without > any better success (I didn't expect that to work, anyway.) On > the same system, CCS does just fine. Odd thing there, _if_ > both are using the same DLL (which maybe they are not.) > > On a Thinkpad laptop running Win7 Professional, though, IAR > works great. And on all my other machines, just fine. But > they aren't 64-bit installs. >
I haven't tried it under Windows, but I just used the Linux version of mspgcc for a personal project, and was really impressed by how clean and easy it wound up being. You also need mspdebug if you're going to work with a LaunchPad, but once I got them installed things just did what they were supposed to. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
Reply by Jon Kirwan December 20, 20122012-12-20
On Thu, 20 Dec 2012 14:13:11 +0000 (UTC), Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

>On 2012-12-19, Jon Kirwan <jonk@infinitefactors.org> wrote: >> On Wed, 19 Dec 2012 18:42:16 -0800, Christopher Head >><chead@is.invalid> wrote: >> >>>On Wed, 19 Dec 2012 10:44:43 -0800 >>>Jon Kirwan <jonk@infinitefactors.org> wrote: >>> >>>> On Wed, 19 Dec 2012 10:39:30 -0800, I wrote: >>>> >>>> >No hardware support is used if I >>>> >understand what I've read (I may not have.) >>>> >>>> I mean... "No peripheral hardware support within the cpu ..." >>>> >>>> Jon >>> >>>I guess you might be able to do something like the V-USB project (the >>>software-only device-side USB stack for AVR). Maybe you would want a >>>bit faster CPU (just because the host-side stuff is probably a bit more >>>complex?though it does have the advantage that a host doesn?t need to >>>always watch the wires for traffic the way a device does), and it would >>>not be USB compliant (because a compliant USB host must support at >>>least low speed *and* full speed, while a device only needs to support >>>one or the other, and you would probably only implement low speed), but >>>in the limited case of plugging in USB keyboards, it might work. At >>>least, you could probably get it to work with *most* keyboards. >>> >>>Chris >> >> Thanks, Chris. That doesn't say I can't do it, or that I >> necessarily can. But maybe. At least the door remains open, >> so far. > >I guess you are going to be reading the full USB spec after all. :-) > >I am not familiar with the physical signalling level as you don't need >that knowledge to write a USB device or host stack which uses a hardware >USB controller so I will comment on some other issues. > >First, are the USB keyboards you can buy today still low-speed devices >or are they now full speed only devices ? > >Given what I currently know, I think you can justify exploring further >the idea of a software only low speed USB host, but I don't see how you >can implement a full speed host in software on the types of MCUs you >are talking about without some hardware support.
I believe they are low speed, HID. I agree completely that a full speed host would be ... difficult. ;)
>I've also been thinking about what steps are _required_ from the device >enumeration sequence after it's attached to a host. I think it may be >possible to drop the reading of the descriptors; there's certainly nothing >in my device stack which _requires_ the descriptors to be read before the >next stage can complete. > >The values in the descriptors (for example, the configuration index) are >required in later steps of the sequence, but if your host stack already >has prior knowledge of the values, I don't see why it would need to read >them from the keyboard's descriptors.
Understood. Point taken.
>However, the other steps are all required. For example, during reset I >configure endpoint 0, setting the address is required before you can >set a configuration and the set configuration stage (at least in my stack) >is where you run down the endpoint descriptors and configure the >application level (ie: HID in your case) endpoints as required.
I'll need to understand more of the spec and think a bit to see what can be done here, I suspect. But I'm keeping all this for later and, as with Chris, I very much appreciate these comments. They will most certainly help focus my attention better. Thanks, Jon
Reply by Jon Kirwan December 20, 20122012-12-20
On Thu, 20 Dec 2012 10:00:28 -0600, Frnak McKenney
<frnak@far.from.the.madding.crowd.com> wrote:

>On Sun, 16 Dec 2012 13:46:10 -0800, Jon Kirwan <jonk@infinitefactors.org> wrote: >> On Sun, 16 Dec 2012 21:00:41 +0700, Ivan Shmakov >><oneingray@gmail.com> wrote: >...several attributions lost... > > [...] > >>> > To OP: For a cheap hobbyist one-off with USB connection I'll probably >>> > just grab an MSP430 LaunchPad off the shelf if the application idea >>> > fits. It's already got connectors for a daughterboard, the cpu is >>> > socketed, comes with two cpus, >>> >>> Somehow, I was unable to find out what exactly comes with this >>> board? But given the price, it indeed looks like a nice thing >>> to have. >> >> You get: >> &bull; Nice box >> &bull; Paperwork >> &bull; &frac12; m USB cable >> &bull; Microcrystal MS3V-T1R tuning fork 32.768kHz crystal >> &bull; MSP430G2231 cpu, DIP >> &bull; MSP430G2211 cpu, DIP > >With the currently-shipping v1.5 LaunchPad boards you get: > > MSP430G2553: 16Kb FLASH, 512b RAM, UART/SPI/I2C, 8ch/10bit ADC, > comparator, touch-sense enabled I/Os. > MSP430G2452: 8Kb FLASH, 256b RAM, UART/SPI/I2C, 8ch/10bit ADC, > comparator, touch-sense enabled I/Os.
Thanks for the correction. I do remember, now that you bring it up, that the CPUs had changed. I just don't have any to remind me about it. Thanks!
>> &bull; LaunchPad board, which includes a USB to host section >> and a developer section with socket for cpu, two pushbuttons >> for user use (as well as reset), two leds, one green, one >> red, jumpers for enabling and disabling features, a special >> interface for using the board to program target boards as >> well (6-pin EZ430 connector), a power connector for your use >> to run the board, and of course a USB connector >> &bull; four headers for daughter card extensions, 2 male-female >> and 2 male-male > >Plus two compiler/IDE suites plus the MSP430 port of gcc.
Yes. I've been having almost nothing but trouble with IAR's on my "clean" install of Win7 Ultimate 64-bit, though. I don't know what the problem is, but I've tried it with many different LaunchPads and different USB connectors (the motherboard has a LOT of them) and I also tried doing it with the XP 32-bit VM from Microsoft running underneath without any better success (I didn't expect that to work, anyway.) On the same system, CCS does just fine. Odd thing there, _if_ both are using the same DLL (which maybe they are not.) On a Thinkpad laptop running Win7 Professional, though, IAR works great. And on all my other machines, just fine. But they aren't 64-bit installs.
>As for USB, I'm aware of one effort in this direction: > > USB v1.1 support on the MSP430 Launchpad > http://www.43oh.com/2012/12/usb-v1-1-support-on-the-msp430-launchpad/ > >Hope this helps...
Oh, yes. Added to my USB favorites folder. I'll look it over. Thanks. Jon
Reply by Frnak McKenney December 20, 20122012-12-20
On Sun, 16 Dec 2012 13:46:10 -0800, Jon Kirwan <jonk@infinitefactors.org> wrote:
> On Sun, 16 Dec 2012 21:00:41 +0700, Ivan Shmakov ><oneingray@gmail.com> wrote:
...several attributions lost... [...]
>> > To OP: For a cheap hobbyist one-off with USB connection I'll probably >> > just grab an MSP430 LaunchPad off the shelf if the application idea >> > fits. It's already got connectors for a daughterboard, the cpu is >> > socketed, comes with two cpus, >> >> Somehow, I was unable to find out what exactly comes with this >> board? But given the price, it indeed looks like a nice thing >> to have. > > You get: > &bull; Nice box > &bull; Paperwork > &bull; &frac12; m USB cable > &bull; Microcrystal MS3V-T1R tuning fork 32.768kHz crystal > &bull; MSP430G2231 cpu, DIP > &bull; MSP430G2211 cpu, DIP
With the currently-shipping v1.5 LaunchPad boards you get: MSP430G2553: 16Kb FLASH, 512b RAM, UART/SPI/I2C, 8ch/10bit ADC, comparator, touch-sense enabled I/Os. MSP430G2452: 8Kb FLASH, 256b RAM, UART/SPI/I2C, 8ch/10bit ADC, comparator, touch-sense enabled I/Os.
> &bull; LaunchPad board, which includes a USB to host section > and a developer section with socket for cpu, two pushbuttons > for user use (as well as reset), two leds, one green, one > red, jumpers for enabling and disabling features, a special > interface for using the board to program target boards as > well (6-pin EZ430 connector), a power connector for your use > to run the board, and of course a USB connector > &bull; four headers for daughter card extensions, 2 male-female > and 2 male-male
Plus two compiler/IDE suites plus the MSP430 port of gcc. As for USB, I'm aware of one effort in this direction: USB v1.1 support on the MSP430 Launchpad http://www.43oh.com/2012/12/usb-v1-1-support-on-the-msp430-launchpad/ Hope this helps... Frank McKenney -- Generations of students in the social sciences have been exposed to entertaining lectures that point out how dumb everyone else is, constantly wandering off the path of logic and getting lost in the fog of intuition. Yet logical norms are blind to content and culture, ignoring evolved capacities and environmental structure. Often what looks like a reasoning error from a purely logical perspective turns out to be a highly intelligent social judgment in the real world. Good intuitions must go beyond the information given, and therefore, beyond logic. -- Gerd Gigerenzer / Gut Feelings: The Intelligence of the Unconscious. -- Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 Munged E-mail: frank uscore mckenney aatt mindspring ddoott com
Reply by Simon Clubley December 20, 20122012-12-20
On 2012-12-19, Jon Kirwan <jonk@infinitefactors.org> wrote:
> On Wed, 19 Dec 2012 18:42:16 -0800, Christopher Head ><chead@is.invalid> wrote: > >>On Wed, 19 Dec 2012 10:44:43 -0800 >>Jon Kirwan <jonk@infinitefactors.org> wrote: >> >>> On Wed, 19 Dec 2012 10:39:30 -0800, I wrote: >>> >>> >No hardware support is used if I >>> >understand what I've read (I may not have.) >>> >>> I mean... "No peripheral hardware support within the cpu ..." >>> >>> Jon >> >>I guess you might be able to do something like the V-USB project (the >>software-only device-side USB stack for AVR). Maybe you would want a >>bit faster CPU (just because the host-side stuff is probably a bit more >>complex?though it does have the advantage that a host doesn?t need to >>always watch the wires for traffic the way a device does), and it would >>not be USB compliant (because a compliant USB host must support at >>least low speed *and* full speed, while a device only needs to support >>one or the other, and you would probably only implement low speed), but >>in the limited case of plugging in USB keyboards, it might work. At >>least, you could probably get it to work with *most* keyboards. >> >>Chris > > Thanks, Chris. That doesn't say I can't do it, or that I > necessarily can. But maybe. At least the door remains open, > so far. >
I guess you are going to be reading the full USB spec after all. :-) I am not familiar with the physical signalling level as you don't need that knowledge to write a USB device or host stack which uses a hardware USB controller so I will comment on some other issues. First, are the USB keyboards you can buy today still low-speed devices or are they now full speed only devices ? Given what I currently know, I think you can justify exploring further the idea of a software only low speed USB host, but I don't see how you can implement a full speed host in software on the types of MCUs you are talking about without some hardware support. I've also been thinking about what steps are _required_ from the device enumeration sequence after it's attached to a host. I think it may be possible to drop the reading of the descriptors; there's certainly nothing in my device stack which _requires_ the descriptors to be read before the next stage can complete. The values in the descriptors (for example, the configuration index) are required in later steps of the sequence, but if your host stack already has prior knowledge of the values, I don't see why it would need to read them from the keyboard's descriptors. However, the other steps are all required. For example, during reset I configure endpoint 0, setting the address is required before you can set a configuration and the set configuration stage (at least in my stack) is where you run down the endpoint descriptors and configure the application level (ie: HID in your case) endpoints as required. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
Reply by Jon Kirwan December 20, 20122012-12-20
On Wed, 19 Dec 2012 18:42:16 -0800, Christopher Head
<chead@is.invalid> wrote:

>On Wed, 19 Dec 2012 10:44:43 -0800 >Jon Kirwan <jonk@infinitefactors.org> wrote: > >> On Wed, 19 Dec 2012 10:39:30 -0800, I wrote: >> >> >No hardware support is used if I >> >understand what I've read (I may not have.) >> >> I mean... "No peripheral hardware support within the cpu ..." >> >> Jon > >I guess you might be able to do something like the V-USB project (the >software-only device-side USB stack for AVR). Maybe you would want a >bit faster CPU (just because the host-side stuff is probably a bit more >complex&mdash;though it does have the advantage that a host doesn&rsquo;t need to >always watch the wires for traffic the way a device does), and it would >not be USB compliant (because a compliant USB host must support at >least low speed *and* full speed, while a device only needs to support >one or the other, and you would probably only implement low speed), but >in the limited case of plugging in USB keyboards, it might work. At >least, you could probably get it to work with *most* keyboards. > >Chris
Thanks, Chris. That doesn't say I can't do it, or that I necessarily can. But maybe. At least the door remains open, so far. I appreciate your thoughts very much, Jon