h a l f b a k e r yGo ahead. Stick a fork in it.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
I envision a future where instead of having to use a usb to serial converter chip just to interface with a AVR chip...
You could just get a spare usb cable, and hook the two data lines to the AVR's pin, and start reprogramming away at it.
Considering the popularity of the arduino, I would think
it would make the ardunino even cheaper.
This will also allow for faster programming of chip on the field.
USB hub used for In System Programming
http://hackaday.com...system-programming/
"It uses the data wires from four different USB cables to program AVR chips..." [Spacecoyote, Jan 23 2011]
USB direct to ATTiny45
http://yveslebrac.b...cope-in-galaxy.html
Looks simple enough [bigsleep, Jan 23 2011]
[link]
|
| |
A bootloader that can service the RXD and TXD pins
as if they were USB IO? |
|
| |
So, if I understand correctly: |
|
| |
USB is a serial protocol
RS232 is a serial protocol
Therefore it should be possible for the USB port to act like
an RS232 port (with suitable connectors), using software
rather than hardware to convert the data formats?
|
|
| |
I'm curious because I've just started to dabble in using
serial devices, having discovered that a large number of
gadgets are still produced with RS232 instead of USB ports,
while computers now mostly lack RS232 out. |
|
| |
Would the computational burden of this be too great? EG
would the software have to sit checking for each bit of
data in realtime, instead of just waiting for it to pile up
somewhere and then go and collect it? |
|
| |
There’s the AT90USB1287 — used in a variety of
programmable USB “key” shaped devices. |
|
| |
Hmmm. Could some kind guru explain a bit of this jargon for
the benefit of us nongurus (i.e., your present interlocutor)? |
|
| |
looking at the AT90USB1287, I say that it looks pretty sweet. |
|
| |
If only, they also provide it in DIP socket format. |
|
| |
anyhow for maxBuch. DIP=Dual Inline Package, AVR = Brand of microcontrollers, Arduino=easy to program development board, RS232=super ancient port used for old old dial up modem. Hope that helps |
|
| |
Arduino is certainly not easy to program. It’s
programmed in C — an appallingly designed failure
of a language. It’s pretty near incomprehensible
for all except the most esoteric full-time
computer programmers, and certainly not
approachable by the ordinary people who only set
aside an hour or so on occasional weekends for
this sort of thing. C is simply the wrong language. |
|
| |
If they’d have picked a non Harvard-architecture
CPU, and if they’d have picked Forth as the
language, then they’d have an easy to program
board that the people as a whole could approach. |
|
| |
[IT] The Fez Panda is programmed in C# with step by step debugging on board. Groovy. Nice. |
|
| |
Mono .Net Micro Framework coming soon for Netduinos and Pandas. |
|
| |
And here, I thought you were campaigning on behalf of "the people". |
|
| |
They hate C too, but they won’t tell you. They’ll
just quietly put their Arduinos away and find
something else to do on weekends that actually
works by the end of the day. It’s the wrong language
to use. |
|
| |
//It’s the wrong language to use.// |
|
| |
Now - I'm not sure that is completely true... but at the same time (as we've had discussions around this before), I do know where you're coming from. |
|
| |
I hate C. I've had a very brief look at Forth and it does not seem to be any easier. It might make a bit more sense in some ways but it seems a little more low level. "The People" need a higher level language (and a monumentally clever compiler). Maybe Ruby... {link} |
|
| |
{Btw - I'm teaching assembler & 8051 as part of my microcontrollers class} |
|
| |
Aha — not a Harvard processor then. Incidentally,
have you seen the MSP430? Only got about three and
a half instructions. No way of using it on OS X
though, so I can’t use my little USB stick thingy of it
that I got for free. |
|
| |
Righto - I just searched, then linked, then read, then sighed, then came back. |
|
| |
//non-Harvard//... Erm.. no - 8051 is a Harvard architecture (I'd better check!). |
|
| |
Ah, so it is. Not that closely related to the 8080
then. Then that’d make it hard to put a Forth on,
I’m informed. |
|
| |
There are several Forth compilers for AVR if you wish to go that route. (Incidentally I just received an MSP430 launchpad...haven't gotten it to do anything yet other than blink) |
|
| |
I’ve got amforth up on my breadboard arduino right
now. It's too incomplete to be useful without a lot
of work each time. There's pretty much no way of
getting the forth programs into it except cutting and
pasting line by line, and if you make a mistake it
corrupts it and you have to go through the immense
tedium of reflashing it with avdrude all over again. |
|
| |
//There are several Forth compilers for AVR //
I thought the attraction of FORTH was that it was interpreted not compiled, and therefore immediate, like the old home computer BASIC.
Unless you've got some true interactive simulator to develop on before committing to ROM, I don't see the advantage of FORTH on an AVR (or any other Harvard architecture controller with less than about 16k bytes RAM). |
|
| |
Learn C - it isn't that hard. |
|
| |
The only reason FORTH is reasonably fast is because it is stack-based, so the interpreter doesn't have to decode too many memory references. Beyond that, it is about as user-friendly as APL. |
|
| |
The attraction of Forth is that I understand it a bit. |
|
| |