Geeks! Post your coding projects! - Page 3

WarmToast · 30th May 2005, 11:54 PM

Quote:

Originally Posted by cynix

OK, I give up, seems you don't understand how things work at a low level so it's pointless me trying to explain it again.

ok, heres my qualifications for getting into this arguement; im in my final year of a microcomputer systems engineering degree at glasgow uni and Ive spent the best part of the year:
A) coding in assembly
B) wrote my own OS for a motorola uC (the HC080) in assembly
C) coding in java and c++ (i hate java btw)

now....

You COULD have constructors and destroctors in assembly if you wanted but it wouldnt be anything like instancieating an object in a OOL, you would need to have your own memory handling system told hold info on the object and have your own code in place to actually perform the instanciation blah blah blah....

so it is doable but its completely pointless as its like a million lines of assembly for no reason what so ever.

So i think that both of you are right and wrong cos although its possible (cyrix's point) its nothing like the funcitonality of a OOL doing it as its completly pointless for ANY assembly application (hd's point).

: : Scott : : · 31st May 2005, 12:13 AM

less talking stupid shit about doing stupidly pointless things in assembly and more coding projects posted plz guyz

Hecate · 31st May 2005, 12:29 AM

Quote:

Originally Posted by : : Scott : :

less talking stupid shit about doing stupidly pointless things in assembly and more coding projects posted plz guyz

aww! i`m finding all this very interesting actually

cynix · 31st May 2005, 12:31 AM

Quote:

Originally Posted by WarmToast

A) coding in assembly
B) wrote my own OS for a motorola uC (the HC080) in assembly
C) coding in java and c++ (i hate java btw)

Aha, someone who's likely to understand what I'm on about comes along at last!

I've worked a bit with Fujitsu and Hitachi microcontrollers but never used any Motorola ones, is the instruction set anything like the 68000?

BTW sounds like an interesting course you're on, I wish they'd had something like that when I did my crappy computing HND back in the late 80's. There seems to be very few low level/embedded control type jobs in Scotland, every bloody job is looking for java or C++ etc, which isn't even real programming if you ask me, hahaha!

Quote:

so it is doable but its completely pointless as its like a million lines of assembly for no reason what so ever.

Exactly, that was my point... not that it would actually be useful to do it, or that it wouldn't take a hell of a lot more code, but simply that to say "You just can't do that in a procedural language" was wrong.

WarmToast · 31st May 2005, 12:39 AM

Quote:

Originally Posted by : : Scott : :

less talking stupid shit about doing stupidly pointless things in assembly and more coding projects posted plz guyz

heres my footie playing robots code (i think this was the last version)

its, eh, great

http://www.neon-fx.com/remote_test.txt

Quote:

Originally Posted by cynix

is the instruction set anything like the 68000?

and ye, quite like the 68000 in principles (like memory mapped port interfacing etc) but with extra toys on board.

'MON THE ASSEMBLY!!!!!

Quote:

Originally Posted by cynix

Exactly, that was my point... not that it would actually be useful to do it, or that it wouldn't take a hell of a lot more code, but simply that to say "You just can't do that in a procedural language" was wrong.

C++ used to be completly implemented through C as a set of '#include' modules so in actual fact it did used to be a messed up procedural language!

cynix · 31st May 2005, 01:00 AM

What's that running on, the motorola uC? Looks like a cross between PIC and 6502 assemblers.

You could optimise that "remotemode" routine by storing each subroutine address and speed etc. value in a table and then calculating the required table offset for each remote code by scaling the remote code directly with a left shift.

WarmToast · 31st May 2005, 08:29 AM

Quote:

Originally Posted by cynix

What's that running on, the motorola uC? Looks like a cross between PIC and 6502 assemblers.

You could optimise that "remotemode" routine by storing each subroutine address and speed etc. value in a table and then calculating the required table offset for each remote code by scaling the remote code directly with a left shift.

its motorollas (well freescales now) 6808 assembly.

hahaha, ye, basically it was a bodged case statement at the last minute. only takes (3*number of cases) clock cycles to test the last condition (9 micro seconds) and since the most common condition was for no button to be getting pressed it just a horrbile yet quick poll up the top.

I know that polling is evil BUT it was basically just a state machine when it was in remote control mode.

cynix · 31st May 2005, 12:20 PM

I like how you're sending the remote codes in parallel across 4 ports, makes it so much easier to decode than a serial stream. I wrote some code to handle an input from a standard IR remote control into a single port of a PIC chip and it took about a page and a half of source to decode the transmitted byte, whereas you can basically do it in 1 line there!

But, you'll decode and process possibly invalid remote commands for a few microseconds (due to framing errors) when the transmitted command changes or starts/ends. If you're using a uC in the transmitter then it won't set all the outputs to the correct values simultaneously, or even the varying rise/fall times of the ports/components driving the transmitter hardware could cause framing errors.

Ideally you should transmit a 5th bit to flag "data valid", which is pulled low when no remote button is pressed and only pulled high a few nop's after all the outputs are set when a button is pressed, then low again as soon as the button is released but before the outputs are cleared down. Then if the receiver only processes remote commands when the 5th bit is high you've got some degree of error prevention in the communication system.

In your application I guess it doesn't matter 'cause the valid command will correct any invalid one after a few microsec's so it won't really make any difference, but if I was marking your project I'd give some extra points for including error prevention.

WarmToast · 31st May 2005, 06:30 PM

the whole remote thing was actually a wee last minute hack jsut before the robot was handed in. We built the remote control using a pad with 10 switches on it and sent 7 of them to 7-3 priority encoder and the other 3 went to the encoder and also directly to the transmit module via some diodes. the module encodes 4 bit values to a form suitable for AM transmittion with a keylock protocol on it (kinda like your car remote, all data is encoded for specific reciever/transmitter modules) then then we bodge together AM modules for. So although you might get invalid signals at the uC side from the data module most the error handling was already taken care of. There was an option to stream serial data and the 6808 handles streaming quite well, but i couldnt really be bothered

Only took a day to get the remote built and then other day to get it working with the robot. got major marks for the remote, best feature in our 3rd year team desgin project ever

My favorite bit of the code is digital sampling of the sensors that run from the interrupt down the bottom. worked an absolute treat. gave you an integer value from a digital sensor so you could tell how "on" the sensor was. it was most usefull because the ball would roll about the floor and at certain angles would appear to the sensors that there was nothing there but with this technique you could see that it had only been out of sight for a fraction of a second.

Id love to stick my OS online but its still uni property and they arent cool enough to make anything open source

it was basically a POSIX style process scheduler which allowed you to create and destroy threads on the fly. only worked for assembly code tho.

Anyone else do low level coding here?

cynix · 31st May 2005, 08:29 PM

Quote:

Originally Posted by WarmToast

My favorite bit of the code is digital sampling of the sensors that run from the interrupt down the bottom.

Yeah I saw that, was wondering what it was doing.

Quote:

Anyone else do low level coding here?

Seems there's very few low level type coders around these days, it's only really needed for device driver stuff, embedded control type applications or maybe some optimisation of speed critical game code, whereas it used to be the only way to develop games at all.

Only real coding I've done in the last 5 years was PIC code for DVD player region hacking mod chips and some DVD player firmware mods (hence the Hitachi and Fujitsu microcontroller stuff) and I ain't putting the source for any of that online either 'cause hopefully I'll be able to make a few quid off it again in the future.

WarmToast · 31st May 2005, 09:15 PM

Quote:

Originally Posted by cynix

Seems there's very few low level type coders around these days

I know, Im actually the only person at glasgow uni in 3rd year who specialises in it... kinda worrying.

I can see a future openning up again for this style of coding once again though now that more and more new cars have uC's on board most of which are coded in C or straight assembly.

It was not a deliberate field to get into though, I came to uni doing a CompSci degree but have discovered I actually hate most the baggage that comes with it (ie. databases!!!!!) and found myself drawn towards hardware and coding for it.

humndislocation · 31st May 2005, 09:19 PM

I could be wrong, but I think some PS2 code is still written in assembler, to take advantage of the different processors. I think they might have compilers for that now though.

WarmToast · 31st May 2005, 09:37 PM

They do, via codewarrior (i think) and homebrewed software (that being where the assembly comes it)

Sony did provide a hell of alot of librarys for the mips (i tihnk thats whats in it) but noone ever used them and just wrote their own.

ppl will still use assembly for it for memory management etc as there is no faster way to get a job done.

31st May 2005, 12:13 AM	#32 (permalink)
: : Scott : : Senior Member Join Date: Mar 2003 Location: Dundee Posts: 7,138	less talking stupid shit about doing stupidly pointless things in assembly and more coding projects posted plz guyz

31st May 2005, 01:00 AM	#36 (permalink)
cynix Senior Member Join Date: Sep 2003 Location: Glasgow Posts: 554	What's that running on, the motorola uC? Looks like a cross between PIC and 6502 assemblers. You could optimise that "remotemode" routine by storing each subroutine address and speed etc. value in a table and then calculating the required table offset for each remote code by scaling the remote code directly with a left shift.

31st May 2005, 12:20 PM	#38 (permalink)
cynix Senior Member Join Date: Sep 2003 Location: Glasgow Posts: 554	I like how you're sending the remote codes in parallel across 4 ports, makes it so much easier to decode than a serial stream. I wrote some code to handle an input from a standard IR remote control into a single port of a PIC chip and it took about a page and a half of source to decode the transmitted byte, whereas you can basically do it in 1 line there! But, you'll decode and process possibly invalid remote commands for a few microseconds (due to framing errors) when the transmitted command changes or starts/ends. If you're using a uC in the transmitter then it won't set all the outputs to the correct values simultaneously, or even the varying rise/fall times of the ports/components driving the transmitter hardware could cause framing errors. Ideally you should transmit a 5th bit to flag "data valid", which is pulled low when no remote button is pressed and only pulled high a few nop's after all the outputs are set when a button is pressed, then low again as soon as the button is released but before the outputs are cleared down. Then if the receiver only processes remote commands when the 5th bit is high you've got some degree of error prevention in the communication system. In your application I guess it doesn't matter 'cause the valid command will correct any invalid one after a few microsec's so it won't really make any difference, but if I was marking your project I'd give some extra points for including error prevention.

31st May 2005, 06:30 PM	#39 (permalink)
WarmToast Senior Member Join Date: Jan 2004 Location: St Georges Cross, Glasgow. Posts: 717	the whole remote thing was actually a wee last minute hack jsut before the robot was handed in. We built the remote control using a pad with 10 switches on it and sent 7 of them to 7-3 priority encoder and the other 3 went to the encoder and also directly to the transmit module via some diodes. the module encodes 4 bit values to a form suitable for AM transmittion with a keylock protocol on it (kinda like your car remote, all data is encoded for specific reciever/transmitter modules) then then we bodge together AM modules for. So although you might get invalid signals at the uC side from the data module most the error handling was already taken care of. There was an option to stream serial data and the 6808 handles streaming quite well, but i couldnt really be bothered Only took a day to get the remote built and then other day to get it working with the robot. got major marks for the remote, best feature in our 3rd year team desgin project ever My favorite bit of the code is digital sampling of the sensors that run from the interrupt down the bottom. worked an absolute treat. gave you an integer value from a digital sensor so you could tell how "on" the sensor was. it was most usefull because the ball would roll about the floor and at certain angles would appear to the sensors that there was nothing there but with this technique you could see that it had only been out of sight for a fraction of a second. Id love to stick my OS online but its still uni property and they arent cool enough to make anything open source it was basically a POSIX style process scheduler which allowed you to create and destroy threads on the fly. only worked for assembly code tho. Anyone else do low level coding here?

31st May 2005, 09:19 PM	#42 (permalink)
humndislocation Hardcore is serious guys Join Date: Mar 2003 Location: Dundee Posts: 6,055 Band: Blasphemous Necrorapist	I could be wrong, but I think some PS2 code is still written in assembler, to take advantage of the different processors. I think they might have compilers for that now though.

31st May 2005, 09:37 PM	#43 (permalink)
WarmToast Senior Member Join Date: Jan 2004 Location: St Georges Cross, Glasgow. Posts: 717	They do, via codewarrior (i think) and homebrewed software (that being where the assembly comes it) Sony did provide a hell of alot of librarys for the mips (i tihnk thats whats in it) but noone ever used them and just wrote their own. ppl will still use assembly for it for memory management etc as there is no faster way to get a job done.