|
We were finally moving to a SoC with 128 kB of flash and 16 kB of RAM (starting from 64 / 6) and now they want to cut costs moving back to a 64 / 8.
I really really wanted to see what we could do with that ocean of RAM...
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
128k, that doesn't sound like enough space to hold the Google starting page?
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
It is enough to run Wizardy 1 and Zork 1 though.
|
|
|
|
|
den2k88 wrote: I really really wanted to see what we could do with that ocean of RAM...
In the early 1980s, the 8-bit Commodore PET 2001 could play a decent game of chess with 8K of RAM (no flash!) for both code and data.
It was very slow, but it worked!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Slow is cool, but when you have 125 microseconds to perform 3 tridimensional transforms in order to compute the timings of six MOSFETs, keep communication, manage the high level functionalities and the diagnostic services... you can't be slow 
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
You work with microseconds ?! 
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
A fairly common occurrence in embedded products.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Yes, directly in Interrupt Service Routines to keep an electric motor running at defined RPM and torque. Depending on the manifacturer you can have 4k or 8k samples per second in order to apply the Park and the Clarke transformations (and to run the PI observer). Such transformations are quite heavy since they are 3D geometrical tranforms in the Complex numbers.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
This is where assembler kicks in.
I think I would enjoy your job.
|
|
|
|
|
We actually don't need it here, SoCs are well designed and have 1 cpu-cycle RAM access that really helps, and the optimizer is good.
I had to turn to Assembler on an Intel system to perform high speed image manipulations (i.e. rotating an image 90 degrees in any direction with any mirroring in microseconds, normalizing the gray levels...). SIMD instructions are fun, even if SSE are asinine sometimes.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Hmmm. A 6502 running at a few GHz...
One thing is certain - you wouldn't need a heater in the car. 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: Hmmm. A 6502 running at a few GHz...
Don't you mean MHz?
"Time flies like an arrow. Fruit flies like a banana."
|
|
|
|
|
6502 did run up to 3 MHz.
Imagine how it would perform at thousand times the original top speed! Apple II Mark II could turn out to be a hefty machine ...
I don't know enough of hardware to tell if it would be at all possible to make a 3 GHz version. You would probably have to abandon 99% of the implementation technology, but maybe you could retain the instruction set, memory model etc.
One of my dreams is that "someone" had the resources to pick up some of the concepts/architectures abandoned a generation ago because the technology wasn't ready for it. Take the iAPX 432, an object oriented machine taking the object concept to extremes. E.g. you could send an object to another process, but then you lost it yourself. Obviously, you would have to review and update the architecture; e.g. the original 432 could only offer 8 Ki objects per process. I am quite sure that the technology we have today would be capable of implementing a 432 Mark II that would both have sufficient functionality and performance to be useful.
I am not suggesting that you could make the market accept an object oriented processor, though. When anyone mentions the tremendous speed of technological change in the digital age, one of my primary counter arguments is that the 1978 X86 architecture still is dominating, 45 years later (although in revised versions - or cancerous versions, if you prefer).
|
|
|
|
|
I meant what I wrote.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Overlays (in 4K):
Load "read a card"
Read a card
Load "process card"
Process card
Load "write"
Write output
Load "read a card"
...
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
The Commodore PET 2001 only had a single tape recorder for I/O, which was slow as molasses. Using it for any overlay mechanism might have been technically possible, but would have been impractical.
Later models had optional diskette drives (I don't recall if an HDD was available), but they also had much more memory (up to 96K, IIRC).
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Are you sure that cost is the only factor? When I was working with embedded/IoT chips, the main reason for not extending RAM was to save power. In a number of applications, the cost of replacing batteries more often can raise the maintenance costs by several times the extra cost for the chip. Maybe our strongest sales argument was that you could build devices that would run a year or two on a small button cell. (We sold chips, we were not buyers.) The main reason why the old, small chips are still being sold in truckloads is not the low price, but the low power consumption.
Yes, I have seen my share of dirty tricks to cram the necessary functionality into a total 64 kibytes. There was a lot of bitching and swearing. My first assignment was to implement the complete Bluetooth Test Mode in at most 1200 bytes. (I clocked in a 1103 bytes.) The company was awarded a patent for a method to delay turning on the Bluetooth receiver a fraction of a microsecond later, to save power.
Maybe, in your company, chip cost is the only argument, that you have no concern about battery life. It could also be that you have not heard all the arguments your management has collected. Maybe the sales force has reported that customers are complaining about battery life. Maybe management never brought that down to you. Maybe they did, but not in flashing, bold, red letters, so you overlooked it.
If cost really is the only argument for a smaller chip: Your management seems to completely ignore the cost of all those twists and tricks the developers have to do to fit everything in. When we went from an 8-bit (8051) to a 16-bit (ARM M0), developer productivity raised sharply, because we could spend time on programming the solution rather than on tricks to get around hardware limitations.
|
|
|
|
|
Not power consumption, when it needs to go in power saving it goes in deep sleep and only the network transceiver is powered on, with the edge triggering directly the power-on pin.
When in operation it pilots motors that range from 400 to 1500 watts so a milliwatt here and there are not an issue.
I did work on a MCU where power consumption in sleep was measured in microamperes (2 months of work to lower from 520 uA to 499 uA) but this is not the case.
It's costs and it comes down straight from our overlords from Hong Kong.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
now I have a big table in a database, what is the best way to get understanding of this table quickly? it has hundreds of fields and I only know some keys.
I have some basic ideas already, but I would like to learn some new tricks from gurus here. Somehow I am a little addicted to ask questions here.
diligent hands rule....
|
|
|
|
|
Is this a NoSQL table, or a flattened table as is common in high performance environments such as banking?
|
|
|
|
|
it is a high performance table in Teradata...
diligent hands rule....
|
|
|
|
|
What type of database? If it's SQL Server use
exec sp_help '<your table name>' , Oracle:
sp_helptable '<your table name>' , anything else - use Google. Informix or Interbase - you are out of luck...
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
very helpful. Thank you!
diligent hands rule....
|
|
|
|
|
Southmountain wrote: now I have a big table in a database, what is the best way to get understanding of this table quickly?
Documentation. If there's a table, there's a developer and there should be documentation.
Southmountain wrote: it has hundreds of fields and I only know some keys.
Hundreds of fields??
DROP TABLE would be the best start; no normalized table contains that much fields.
I'm serious; no such table should exist. You asking how to understand it implies no documentation either.
Name your company.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: DROP TABLE would be the best start;
lol...
I worked with a table like that. It was batch loaded every night from some other mysterious source that was definitely COBOL and probably DB2. What I did know was that on the COBOL side they had reached the maximum number of columns of the system. It would not allow them to add any more.
I think there was something like 300 or 400 columns.
But 200 or so were just for a single indexed value. So something like column 30 had an int. Then the value in that column pointed to one of another sequential 200 columns with a value. The other 200 columns were null.
Probably could not have dropped it. It held credit card transaction data.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
