<DocScrutinizer05>
a pity, 8051 is still sort of a basic standard
<whitequark>
too small to have a decent compiler
<DocScrutinizer05>
admittely the CPU arch is crap, but...
<DocScrutinizer05>
tbh for 8051 you don't need a decent compiler. K&R c will do, when you leave out the more sophiisticated stuff and basically use it as macroassembler
<whitequark>
well that's exactly the problem, c makes a bad macroassembler ;p
<DocScrutinizer05>
hehehe
<DocScrutinizer05>
then use a decent macroassembler instead ;-)
<sb0>
oh, excellent
<sb0>
rjo, sounds like this is the way to go. i don't look forward to touching the proprietary opalkelly stuff.
<sb0>
according to Jason, it is buggy, which would not surprise me
* whitequark
. o O ( is there non-buggy hardware? )
<sb0>
I mean, their 8051 firmware and PC drivers
kuldeep has quit [Ping timeout: 240 seconds]
sandeepkr has quit [Ping timeout: 260 seconds]
kuldeep has joined #m-labs
<cr1901_modern>
I wouldn't use C for the 8051. It's ASM is fairly tolerable if you can find a good assembler (unfortunately ASEM-51 is closed source last I checked)
sandeepkr has joined #m-labs
<DocScrutinizer05>
my last at89c2051 project was even pascal iirc (sorry, almost 10 years ago)
<DocScrutinizer05>
or c
<DocScrutinizer05>
anyway there are a plethora of supposedly working USB et al libs for 8051
<whitequark>
thats not just bare 8051
<whitequark>
thats 8051 driving cypress custom USB IP
<DocScrutinizer05>
ouch
<whitequark>
its purpose is more or less to set up DMA, mapping, and sit idle doing nothing
<DocScrutinizer05>
hrhr
<whitequark>
so not much use for any existing libs
<DocScrutinizer05>
yep
<DocScrutinizer05>
obviously
<DocScrutinizer05>
my last experience with a USB core (mentorgraphics musb-hdrc) was a nicghtmare
<whitequark>
cypress is used a lot, so I think it's moderately alright
<whitequark>
never used it myself but talked with people who did
<whitequark>
they didn't swear very much
<DocScrutinizer05>
well, MG musb is used in OMAP3 (and prolly 4 and 5)
<DocScrutinizer05>
so this qualifies for "widely used"
<DocScrutinizer05>
still it's an abomination
<DocScrutinizer05>
has a statemachine you can't control by software
<DocScrutinizer05>
you won't believe it until you see it
<whitequark>
there is basically no depth of depravity in proprietary USB IP that will surprise me
<DocScrutinizer05>
if onyl MG had a single cheesy register to represent the stae of the musbcore statemachine, and you could write to that... but NOOO
<whitequark>
maybe they have it
<whitequark>
hidden somewhere undocumented
<DocScrutinizer05>
not documented *anywhere*
<whitequark>
they gotta debug that shit too
<whitequark>
well that should be easy to RE, no? dump all the register space, poke the FSM, dump again
<DocScrutinizer05>
well, yes, probably
<DocScrutinizer05>
I wasted one year to get stuff working using the documented registers
<sb0>
rjo, hmm, that's not obvious. i'd add a button like in the dashboard...
<rjo>
it needs documentation or some way to make it obvious. but a button and yet another explorer thing popping up is definitely not how i would use it.
<rjo>
the other -- maybe more natural -- thing would be to have activate load the hdf5 into the currently active editor.
<sb0>
the button can be "load arguments from the currently selected hdf5"