KermMartian wrote:
AHelper wrote:
*TILem2, I hope. Any plans for including a debugging interface for the emulated calcs?
What kind of interface did you have in mind? If I'm using something like TILEm2, I'm hoping to at least be able to pause the emulation somehow. I'll need to find some special key combination to pause the emulation or at least make some of the keys issue F1-F12 combinations.


You have a touchscreen, you can add a touch area to pause the emulation, bring up a menu of sorts, start a debugger, etc.. You might even be able to get the emulated LCD with a minimal debugger window on display at the same time.

Interface could be minimal with the LCD, expanding to show memory, stack, etc.
Why do you need to make a USB keyboard? Can't the odroid-w read the keys directly from it's GPIO?
I can show you how to wire up the keypad matrix, if you want.
I sadly only have figured out the ones from the 84 Series but the design is very easy and stays basically the same for all models.
Ivoah wrote:
Why do you need to make a USB keyboard? Can't the odroid-w read the keys directly from it's GPIO?

You could do that, but the less wires you have running from one half of the case to the other, the better. You also don't have to write any code to talk to udevm which is a huge plus.
Well i am going to matrix scan my pins from gpio and i write i input driver for it
SpaceCat wrote:
Ivoah wrote:
Why do you need to make a USB keyboard? Can't the odroid-w read the keys directly from it's GPIO?

You could do that, but the less wires you have running from one half of the case to the other, the better. You also don't have to write any code to talk to udevm which is a huge plus.
This is definitely part of it. Using 3-4 wires instead of 16 is a nice plus. In addition, check out Tari's recommendation from the first page of this topic:
Tari wrote:
As far as the keyboard goes, I'd probably just slap a low-power micro onboard to feed keypresses to the main processor. An MSP430 or such would probably have a negligible effect on system power if you took advantage of the power-saving capabilities.
*bump* Well, it's the wrong kind of calculator, but I have gcalculator running on there! I bridged the ODroid-W's USB +5V and power input lines as per their instructions, and now the module doesn't reboot due to low power when the desktop GUI is running. My miniature wireless laptop mouse (yes, that's a miniature mouse) is connected to the board, as I didn't get around to dealing with the touchscreen yet.

that's looking good.

I second the idea of using a MSP430 to do the keyboard. Running an embedded USB connection over to the Main board would be good, and would let you also have an external USB for a real keyboard if you felt like getting fancy.
rfdave wrote:
that's looking good.
Thanks!

Quote:
I second the idea of using a MSP430 to do the keyboard. Running an embedded USB connection over to the Main board would be good, and would let you also have an external USB for a real keyboard if you felt like getting fancy.
To avoid monopolizing the board's single USB port, another idea tossed around yesterday afternoon on IRC was making a microcontroller performing keyboard duties communicate over SPI or I2C, although Tari's investigation didn't reveal SPI keyboard drivers in Linux, I believe. Out of curiosity, why the MSP430 family instead of something like an Atmega, with which I'm more familiar?
KermMartian wrote:
To avoid monopolizing the board's single USB port...

Why worry about that? Four port USB hubs are dirt cheap and pretty small now too. Then you could have wifi and the keyboard and have two ports to spare.
SpaceCat wrote:
KermMartian wrote:
To avoid monopolizing the board's single USB port...

Why worry about that? Four port USB hubs are dirt cheap and pretty small now too. Then you could have wifi and the keyboard and have two ports to spare.
Yep, that's true; the two drawbacks there are the power budget for that and the space to fit it in.
KermMartian wrote:
SpaceCat wrote:
KermMartian wrote:
To avoid monopolizing the board's single USB port...

Why worry about that? Four port USB hubs are dirt cheap and pretty small now too. Then you could have wifi and the keyboard and have two ports to spare.
Yep, that's true; the two drawbacks there are the power budget for that and the space to fit it in.


Is power really that big of an issue?
I haven't picked out my LiPo battery for this, but I can't imagine I'll be able to fit more than a 1500mAh or 2000mAh in the battery compartment (and at a decent weight). The SoC and LCD already pull down quite a substantial portion of that, so it's just good design to try to minimize the extra draw from peripherals as much as possible. Smile
Quote:
To avoid monopolizing the board's single USB port, another idea tossed around yesterday afternoon on IRC was making a microcontroller performing keyboard duties communicate over SPI or I2C, although Tari's investigation didn't reveal SPI keyboard drivers in Linux, I believe.
More specifically, it doesn't look like Linux has any capability to operate as a SPI nor I2C slave.

Quote:
Out of curiosity, why the MSP430 family instead of something like an Atmega, with which I'm more familiar?
Successful marketing? When I think "low power", I reach for MSP430. You might want to compare power numbers from datasheets, but I think active-mode power for a '430 is appreciably lower than an AVR.
Tari wrote:
Quote:
To avoid monopolizing the board's single USB port, another idea tossed around yesterday afternoon on IRC was making a microcontroller performing keyboard duties communicate over SPI or I2C, although Tari's investigation didn't reveal SPI keyboard drivers in Linux, I believe.
More specifically, it doesn't look like Linux has any capability to operate as a SPI nor I2C slave.

Quote:
Out of curiosity, why the MSP430 family instead of something like an Atmega, with which I'm more familiar?
Successful marketing? When I think "low power", I reach for MSP430. You might want to compare power numbers from datasheets, but I think active-mode power for a '430 is appreciably lower than an AVR.
Makes sense, thanks. In that case, I've ordered some MSP430F5510 samples in the LQFP package, and I'll have to start drawing up a board design. I'll probably need a way to connect the leads from the calculator's original mainboard, interfaces for the dev board's headers, a place to resolder the LCD on, and a spot to put a socket for the LiPo battery.
Quote:
Makes sense, thanks. In that case, I've ordered some MSP430F5510 samples in the LQFP package, and I'll have to start drawing up a board design. I'll probably need a way to connect the leads from the calculator's original mainboard, interfaces for the dev board's headers, a place to resolder the LCD on, and a spot to put a socket for the LiPo battery.

How are you going to do LiPo battery charge management? Are you going to support charging it an external USB port?
rfdave wrote:
How are you going to do LiPo battery charge management? Are you going to support charging it an external USB port?
Actually, part of the reason I chose this particular (ODroid-W) board is that it has LiPo management circuitry on-board. You can directly connect a battery to the board, charge it through the microUSB port, and from software access the current charging state and battery level. If I decide to get really clever, I should modify TILEm to use the LiPo's charging state and charge level when the emulated TI-84+CSE asks for the battery state.
Quote:
Out of curiosity, why the MSP430 family instead of something like an Atmega, with which I'm more familiar?


I think using an Atmel part in a TI Calculator would be like crossing the streams in Ghostbusters. Bad Mojo would happen Wink
KermMartian wrote:
rfdave wrote:
How are you going to do LiPo battery charge management? Are you going to support charging it an external USB port?
Actually, part of the reason I chose this particular board is that it has LiPo management circuitry on-board. You can directly connect a battery to the board, charge it through the microUSB port, and from software access the current charging state and battery level. If I decide to get really clever, I should modify TILEm to use the LiPo's charging state and charge level when the emulated TI-84+CSE asks for the battery state.


I think the odroid-w has support for LiPo battery usage/charging onboard

EDIT: I thought KermM was talking about the MSP430
So TI managed to send my MSP430 samples over the weekend, but I am nowhere close to having a board design done. In fact, before I can design a complete board, I need to decide whether I'll use the tiny 2.4" LCD or a very slightly less-tiny 2.8" LCD. The 2.4" LCD is exactly the height of the TI-83+SE case's LCD aperture, but leaves lots of blank space on each side (like the original 96x64 monochrome LCD, in fact). The 2.8" LCDs are much more expensive, and I'd probably have to cut part of the case out to fit the height, but the width might fit better. This is relevant because each type of LCD has a different edge connector that I'll have to put on the eventual board.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 5
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement